Linear Sequential Model

Keywords: linear sequential model advantages and disadvantages

Introduction

Software process (Jean, Badara & David 1999) defines the way in which software development is organized, managed, measured, supported and improved. Although they may show different levels of sophistication in mastering their processes, all organizations involved in software-development follow a process of some kind, implicit or explicit, reproducible, instrumented, adaptable or otherwise. Software Development Organization in general has come to realize that the key to successful delivery (on time, on budget, with the expected quality) lies in the effective management of their software process.

Generic phase

Pressman (2001) mentions that software engineering can be categorized into three phases, regardless of application area, project size or complexity.

The definition phase focuses on what. That is during definition, the software engineer attempts to identify what information or data is to processed, what function and performance are required, what system behavior can be expected, what interfaces are to be established, what design constraints exist and what validation criteria are required to define a successful and working system.

The development phase focuses on how. That is, during development a software engineer attempts to define how data are to be structured, how function is to be implemented within a software architecture, how procedural details are to be implemented, how interfaces are to be characterized, how the design will be translated into a programming language, and how testing will be performed. The methods applied during the development phase will different, but three specific technical tasks should always occur: software design, code generation, and software testing.

The support phase focuses on change associated with error correction, adaptations required as the software’s environment evolves, and changes due to enhancements brought about by changing customer requirements. The support phase reapplies the steps of the definition and development phases but does so in the context of existing software. Four types of change are encountered during the support phase:

Correction: Even with the best quality assurance activities, it is likely that the customer will uncover defects or bugs in the software. Corrective maintenance changes the software to correct defects.

Adaptation: Over time, the original environment (e.g., CPU, operating system, business rules, external product characteristics) for which the software was developed is likely to change. Adaptive maintenance results in modification to the software to accommodate changes to its external environment.

Enhancement: As software is used, the customer/user will recognize additional functions that will provide benefit. Perfective maintenance extends the software beyond its original functional requirements.

Prevention: Computer software deteriorates due to change, and because of this, preventive maintenance, often called software reengineering, and must be conducted to enable the software to serve the needs of its end users. In essence, preventive maintenance makes changes to computer programs so that they can be more easily corrected, adapted, and enhanced.

Linear Sequential Model / Waterfall Model

Linear sequential model or be known as waterfall model is one of the approaches in Software Development Process Models that software engineer used to defined and design which are used during the development process of software. Parekh (n.d.) clearly stated that all these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off.

Phases of Linear Sequential Model (Startvbdotnet Contributor, n.d.)

Feasibility – The feasibility study is used to determine if the project should get the go ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.

Requirement Analysis and Design – Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design, interface design and data design. During these phases, the software’s overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any mistakes in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Implementation – In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters and Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal and Java are used for coding. With respect to the type of application, the right programming language is chosen.

Testing – In this phase the system is tested. Normally programs are written as a series of individual modules, these subjects to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work, the system works on the intended platform and with the expected volume of data and that the system does what the user requires.

Maintenance – It is cannot be avoided fact that a system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to keep or save detail of changes that could happen during the post implementation period.

Project Output in a Waterfall Model

As Freetutes.com Contributors (n.d.) has seen, the output of a project employing the waterfall model is not just the final program along with documentation to use it. There are a number of intermediate outputs, which must be produced in order to produce a successful product.

The set of documents that should be produced in each project are:

• Requirement document
• Project plan
• System design document
• Detailed design document
• Test plan and test report
• Final code
• Software manuals (user manual, installation manual etc.)

In order to certify an output product of a phase before the next phase begins, reviews are often held. Reviews are necessary especially for the requirements and design phases, since other certification means are frequently not available. Reviews are formal meeting to uncover deficiencies in a product. The review reports are the outcome of these reviews.

Based on the information given by The Software Tester Contributor (n.d.), below are the advantages and disadvantages for Linear Sequential Model.

Advantages of Linear Sequential Model

• Emphasizes requirements before design.
• Single system design phase emphasizes planning and design of the system architecture and technology before coding begins.
• Milestone reviews encourage close scrutiny of phase exit and entry criteria.
• Sequential progression through phases readily maps to configuration control points and the establishment of baselines.
• Model structure is readily understood and communicable to all stakeholders.

Disadvantages of Linear Sequential Model

• Testing does not receive focus until after the system has been specified, designed and coded.
• Many different units and sub-systems could be developed within the one project and the Waterfall Model implies that these are all specified and designed in one clump which does not reflect the reality
• Customer involvement is not throughout so issues with requirements are not always realized until later in the lifecycle.
• Linear progression through the phases can result in issue identification being pushed downstream resulting in many cycles of rework causing delays.
• The customer does not get to see the software until the very end.
• Project managers cannot always get a true picture of project health and progress, especially in the earlier phases.

Rapid Application Development (RAD)

Pressman (2001) describes rapid application development (RAD) as an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a “fully functional system” within very short time periods. Normally it takes about 60 to 90 days.

RAD Model’s Phases

Stages of Rapid Application Model (RAD) Pressman (2001)

Business modeling: The information flow among business functions is modeled in a way that answers the following questions: What information drives the business process? What information is generated? Who generates it? Where does the information go? Who processes it?

Data modeling: The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics or can be called as attributes. Each object is identified and the relationships between these are objects defined.

Process modeling: The data objects defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.

Application generation: Rather than creating software using conventional third generation programming languages, the RAD process works to reuse existing program components when possible or create reusable components when necessary. In all cases, automated tools are used to facilitate construction of the software.

Testing and turnover: Since the RAD process emphasizes reuse, many of the program components have already been tested. This reduces overall testing time. However, new components must be tested and all interfaces must be fully exercised.

Advantages of Rapid Application Development (RAD) My Project Management Expert Contributor (n.d.)

• The time required to develop the software is drastically reduced due to a reduced requirement analysis business requirements documentation and software requirement specification and planning stage.
• All the software prototypes produced can be kept in a repository for future use. The reusability of the components also fastens the phase of the process of software development.
• It is much easier for a project manager to be accurate in estimating project costs which of course means that project cost controls are easier to implement and manage as well.
• It is a big cost saver in terms of project budget as well as project time and cost due to reusability of the prototypes.
• If a component is being picked for the repository, it is already tested and hence need not be tested again. This helps in saving time required for testing.
• The project management requirements are collected in a dynamic manner. Every time there is a prototype ready, requirements are studied and matched. If there are any additional requirements, these are then included in the next prototype built.

Disadvantages of Rapid Application Development (RAD) My Project Management Expert Contributor (n.d.)

• This method may not be useful for large, unique or highly complex projects
• This method cannot be a success if the team is not sufficiently motivated and nor is unable to work cohesively together.
• Success depends on the extremely high technical skills of the developers.
• There are times when the team ignores necessary quality parameters such as consistency, reliability and standardization. Hence this can make project quality management hard to implement during the project management life cycle

Comparison between Linear Sequential Model and Rapid Application Model

Below are the comparison for linear sequential model and rapid application model that are clearly stated by e2x limited Contributor (2005)

Linear Sequential Model Development

Linear Sequential Model development demands that all the requirements are identified and detailed at the start of the project. The system architecture is then defined, and detailed design of the system carried out before programming starts. The system is usually delivered in modules that, once finished are then integrated and tested. The big problem with linear sequential model development is that it assumes all the requirements, the architecture and the design can be identified, fixed and signed off up front. If this is done correctly, development and delivery of the system should be little more than the correct translation of the design into code. Experience has shown that it is incredibly difficult to produce requirements of such detail and completeness that the system delivered is exactly what the customer wanted. We have also seen that the transition from design to programming, from programming to integration, and from integration to testing can be fraught with problems; usually caused by misunderstandings, incorrect assumptions and discrepancies not identified during the requirements, architecture and design phases. Linear sequential model development can, and does work, but doing it right is typically very expensive. However, even when waterfall is practiced well, it is not very good at dealing with change. Every change in the requirements requires a ‘change request’, often submitted to a ‘change control board’. Linear Sequential Model works best when change is restricted.

RAD (Rapid Application Development)

In a RAD project, the customer is involved early on in working with technologists to quickly produce prototypes that embody the requirements. This gives the customer and users a chance to ‘play’ with the technology early on to firm up their requirements and identify any gaps or incorrect assumptions.

RAD projects then typically head in one of two directions. Some will become linear sequential model development projects, with the prototypes being formalized as requirements. Others will seek to develop the prototypes into ‘proper’ implementations. The later approach often leads to a number of poorly engineered and poorly integrated solutions as ‘fleshing out’ a prototype is not the same as developing a ‘proper’ solution from the ground up. As with linear sequential model development, RAD can and does work. However, successful RAD projects tend to be those where the final solution is actually relatively close to the prototype in terms of implementation. Front-office solutions for exotic financial markets built around spreadsheets, and one-off, limited scope, database-and-forms applications are good examples.

Conclusion

As a conclusion, if I am a project manager for a specific software project, I would choose rapid application development (RAD) as one of my method to develop software. By using RAD, I can roughly know what end-user want with their software, I can get clear view what the software can do, how the software behave and what type of performance that I can predict out. On top of that, RAD also enabled the team to work quicker and we can produce high quality software that can meet end-users need.