Software, Linear & Waterfall process model in software development

Zia

1 Follower

Follow

May 17, 2024

-

1 sec read

98

0

0

0

Introduction

The basic difference that makes software different from other products is that it is not a physical entity. Software exists as a logical entity and that starts all the complications.

How does one develop software? How does one manufacture the product designs? We only need to ask a software manager to set up a factory to 'design his products' and watch his reactions to understand the problems he has to face in software product design.

Software Engineering essentially consists of a set of steps that comprise methods, tools, and procedures that assist a software manager in manufacturing software. Depending on the type of software that we plan to develop at our factory, whether it is an office automation product, which is going to be sold in millions, or flight simulation software of which only one copy will be made, one needs to identify the approach that is to be used.

All software development organizations will have to carry out SDLC activities if they have to develop a product. The sequence and detailed level of these activities will depend on the nature of the project and application. Based on product generalizations, various software process models or paradigms are available.

1. Software Process Models

A process is a standardized approach to plan, organize, and execute a software development project. Software process models provide a way in which we can organize our software development into a series of activities to ensure the completion, acceptance, or appreciation of our software product by our customers.

Like any successful product, the development effort will have to start from an insight into the customer requirements. These requirements have to be communicated to the personnel involved in developing the product.

Some amount of 'original thinking' will have to go into designing a solution that will meet the requirements, The design will have to be converted into software that may be bought, and code that may be developed internally. The bits and pieces developed separately will have to be integrated; the final product tested and delivered to the customer. The customer will have to be educated about the product, and if required, the product will have to be modified and maintained.

The process you adopt depends on the software being built. One process might be good for a particular software, while an entirely different process would be used for another software.

The use of process models also makes it easier to predict the budget and to review the progress at the end of each phase.

The process models prevalent in the software industry can be broadly categorized as:

• Linear Process Models
• Evolutionary Process Models
  
  
  
  
  

Linear Process Model

Linear process models also referred to as traditional models, have been used since early times in software development. In this approach, the process of software development is represented by a sequence of activities or phases. Each phase must be completed before you can move to the next phase.

The linear process model is a systematic sequential approach to software development that begins at the system level and progresses through the phases of analysis, design, coding, testing, implementation, and support. The sequential phases make this model linear, simple, and systematic.

The linear models are built on the assumption that the software to be developed can be completely understood and described before a solution is designed. A design that satisfies all aspects of the problem be specified before implementation. All implementation can be done before validation and delivery.

Tight control is maintained over the life of the project with the help of extensive written documentation. formal reviews, and approval/sign-off by the management and customer at the end of every phase.

1. Advantages of the Linear Process Models

The advantages of the linear sequential model are as follows:

• It is easy to understand and implement.
• It allows for a clear demarcation between two phases and a clear hand-off from one phase to the next.
• It ensures a proper forward-looking approach to software development.
• It emphasizes requirements, before designing the solution.
• It has Milestone reviews which encourage scrutiny of phase exit and entry criteria.
• Its sequential progression through phases readily maps to configuration control points and the establishment of baselines.
• The proposed model structure must be clearly understood and communicated to all stakeholders.
  
  
  
  
  

Waterfall Model

The waterfall model, sometimes called the linear sequential model or 'classic life cycle' is illustrated.

This model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and maintenance.

• System/Information Engineering and Modeling: Software being a part of a larger system (or business), the development process has to first establish the requirements for the entire proposed system, and then identify a part of it to be delivered by the software component. This system view is essential when software must interface with other elements such as hardware, people, and databases. System engineering and analysis encompasses requirements gathering at the system level, with a small amount of top-level analysis and design. The feasibility of the proposed system would have to take place at this stage.
  
  
• Software Requirements Analysis: The requirements-gathering process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the software engineer ('analyst') must understand the information domain for the software, as well as the required function, behavior, performance, and interface. Requirements for both the system and the software are documented and reviewed with the customer.
  
  
• Software Design: It is a multi-step process, focusing on four distinct attributes of a program: data structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins. Like requirements, the design is documented and becomes part of the software configuration.
  
  
• Detailed Design: During detailed design, the internal logic of each module specified in the system design is decided. During this phase, further details of data structures and algorithmic design of each of the modules are specified. The logic of a module is usually specified in a high-level design description language, which is independent of the target language in which the software will eventually be implemented.
  
  
• Program Design Language: PDL is one way in which the design can be communicated precisely and completely to whatever degree of detail desired by the designer. It can be used to specify the system design and to include the logic design.
  
  
• Coding: The coding phase translates the design of the system, produced during the design phase, into code in a given programming language. This can be executed by a computer that performs the computation specified by the design. The coding phase affects both the testing and maintenance phases and aims to implement the design in the best possible manner.
  
  During the implementation of this phase, it is essential to keep in mind that the code being written is not only easy to write but also easy to read and maintain.
  
  All design considerations contain hierarchies. This is a natural way to manage complexity. Coding can either be top-down or bottom-up. In a top-down approach, the main module is implemented first, then their subordinates, and so on. In this, implementation starts from the top of the hierarchy and proceeds to the lower level. In a bottom-up implementation, the modules at the bottom of the hierarchy are implemented first, and then the implementation proceeds through the higher levels until it reaches the top.
  
  The advantage of this type of implementation is that the problem is tackled in steps rather than building the whole system in one go. It helps because it is not feasible or desirable to build the whole system in one attempt and then test it. It is better to build parts of the system and test them before putting them together to form the system.
  
  
• Testing: Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals, that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with the required results. The testing activity is carried out in two phases, the components before integration, and then the integrated product.
  
  
• Integration: Developing a strategy for integrating the components into a functioning whole requires careful planning so that the modules are available for integration when needed. The integrated product can then be tested to demonstrate that the implemented software meets the requirements stated in the requirements document.
  
  
• Operations and Maintenance: Software will undoubtedly change after it is delivered to the customer (a possible exception is embedded software). Change will occur because errors have been encountered; the software must be adapted to accommodate changes in its external environment (for example, a change required because of a new operating system or peripheral device) or because the customer requires functional or performance enhancements. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one.
  
  Each phase in this model ends in a verification and validation activity, the objective of which is to eliminate as many problems as possible in the products of that phase. The linear sequential moue is the oldest and the most widely used paradigm for software engineering. For some the Waterfall model provided personnel in the software field with a sequence of common anchor points, a set of milestones around which people can plan, organize, monitor, and control their projects. Many companies, government organizations, and standard groups established interlocking regulations, specifications, and standards based on the model.
  
  
  
  

1. Application of the Waterfall Model

Every software developed is different and requires a suitable SDLC approach based on internal and external factors. Some situations where the use of the waterfall model is most appropriate are as follows:

• The project requirements are clear, fixed, and very well documented.
• The problem definition is stable.
• There are sufficient resources available with the required experience to support the project development.
  
  
  

2. Waterfall Model Benefits and Drawbacks

The main advantage of the waterfall development approach is that the management can set the timelines for each development phase. Also, development is completed phase by phase.

Some of the advantages are as follows:

• Simple and easy to understand.
• Easy to arrange tasks and clearly defined stages.
• The requirement should be clear before going to the next phases.
• Each phase of development has well-defined milestones.
• Works well for smaller projects.
  
  

Some of the disadvantages of waterfall development are as follows:

• Users can judge the quality of the ready product only at the end of the development life cycle.
• Changes required at any phase may end the project development.
• Involves a high level of risk and uncertainty in a project as each phase is closely linked with the earlier phase.
• It follows the 'Big-bang' approach where the entire software product is integrated at the end of the system. This may sometimes lead to challenges that may not be identified at the beginning of the project development.
  
  
  
  
  

V-Model

V-Model is an extension of the waterfall model. This model associates each phase with a corresponding testing phase. This is also a highly disciplined model and each phase starts only after completion of the previous phase. The V-Model is also known as the Verification and Validation model.

• Validation - The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.
  
  
• Verification - The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.

It is said that validation can be expressed by the query "Are you building the right thing?" and verification by "Are you building it right?".

The left side of the 'V' represents the decomposition of requirements and the creation of system specifications. The right side of the 'V' represents the integration of parts and their validation. Testing is emphasized more than in the waterfall model. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just similar to the waterfall model. A system test plan is created before any development is started and targets to meet the functionality specified in requirement gathering.

The main focus of the high-level design phase is system architecture and design. In this phase, an integration test plan is created to test the pieces of the software system's ability to work together. However, the actual software components are designed in the low-level design phase. Unit tests are also created in this phase.

The implementation phase is where all the coding takes place. Once the coding is complete, the path of execution continues to progress up the right side of the V where the test plans developed earlier are put to use.

1. Verification and Validation Phases

Verification and validation consist of four phases that represent the system design with the corresponding validations performed on the designed system.

• Requirements Analysis: The requirements of the proposed system are collected by analyzing the requirements of the users. The user requirements document typically describes the system's functionality, interface, performance, data, security, and other requirements as expected by the user. It is used by business analysts to communicate their understanding of the system to the Users. The users carefully review this document as it would serve as the guideline for the system designers in the system design phase. The user acceptance tests are also designed in this phase. In this phase, the customers decide if they want to accept the system or not.
  
  
• System and Architecture Design: These phases are also referred to as high-level design phases. They provide the entire design of the system including hardware, services, software, and so on. A system test plan is created which validates the system design. System testing compares the system specifications against the actual system. Similarly, an integration plan is created for software integrity within the system. Black box testing is usually done in this stage as the code is not directly checked for errors.
  
  
• Module Design: This phase is also referred to as the low-level design phase. The designed system is broken up into smaller units or modules and each of them is described so that the programmer can start coding directly.
  
  The low-level design document or program specifications contain a detailed functional logic of the module. The unit test design is developed in this stage to test component functionality. The purpose of unit testing is to verify the internal logic of the code by testing every possible branch within the function. This is also known as test coverage.
  
  
• Coding Phase: The actual coding of the system modules designed in the design phase is taken up in the coding phase. The programming language suitable for the project is decided based on architectural requirements. The developed code goes through numerous code reviews and is optimized for best performance before the final build is added to the repository.
  
  
  

2. Advantages and Disadvantages of V-Model

The advantages and disadvantages of the V-model are depicted.

Advantages:-

• Simple and easy to understand.
• Each phase has specific deliverables.
• Higher chance of success over the waterfall model due to the early development of test plans during the life cycle.
• Suitable for those projects which have clear requirements.
  
  

Disadvantages:-

• Very rigid similar to the waterfall model.
• Little flexibility and adjusting scope are difficult and expensive.
• Software is developed during the implementation phase, so no early prototypes of the software are produced.
• This Model does not provide a clear path for problems found during the testing phases
  
  
  

Shortfalls of Linear Models

For a short period in the mid-1970s, it appeared that the software field had found a sequence of common anchor points: a set of milestones around which people could plan, organize, monitor, and control their projects. These were the milestones in the waterfall model, typically including the completion of system requirements, software requirements, preliminary design, detailed design, code, unit test, software acceptance test, and system acceptance test. Unfortunately, an initial design will likely be flawed concerning its key requirements. Late discovery of design defects results in costly overruns and in some cases even project cancellation.

The idea of a software acceptance test keyed to demonstrating compliance to a set of documented requirements specifications encountered problems as well. Foremost among these was that static tests of input-output transformations provided little insight into whether the software would acceptably support common user tasks. The acceptance test also failed to cover many off-nominal problem situations subsequently encountered in beta-testing, field-testing, hardware-software integration, or actual mission operations.