Welcome to TechRiz 

Where tech enthusiasts come for the latest tech news, Free downloads, free tutorials, articles and how to's.

Description:  This is the TechRiz Free Tutorials page. Visit every day to stay informed about the latest tech news, from security alerts to Hardware and software updates. Enjoy your stay.

Week 3

SDLC - Implementation and Maintenance in Software Life Cycle 

Maintenance includes all the activity after the installation of software that is performed to keep the system operational. As we have mentioned earlier, software often has design faults. The two major forms of maintenance activities are adaptive maintenance and corrective maintenance.  

It is generally agreed that for large systems, removing all the faults before delivery is extremely difficult and faults will be discovered long after the system is installed. As these faults are detected, they have to be removed. Maintenance activities related to fixing of errors fall under corrective maintenance.

Removing errors is one of the activities of maintenance. Maintenance also needed due to a change in the environment or the requirements of the system. The introduction of a software system affects the work environment. This change in environment often changes what is desired from the system. Furthermore, often after the system is installed and the users have had a chance to work with it for sometime, requirements that are not identified during requirement analysis phase will be uncovered. This occurs, since the experience with the software helps the user to define the needs more precisely. There might also be changes in the input data, the system environment and output formats. All these require modification of the software. The maintenance activities related to such modification fall under adaptive maintenance.

Maintenance work is based on existing software, as compared to development work, which creates new software. Consequently maintenance resolves around understanding the existing software and spares most of their time trying to understand the software that they have to modify. Understanding the software involves not only understanding the code, but also the related documents. During the modification of the software, the effects of the change have to be clearly understood by the maintainer since introducing undesired side effects in the system during modification is easier.

To test whether those aspects in the system that are not supposed to be modified are operating as they were before modification, regression testing is done. Regression testing involves executing old test cases to test that no new errors have been introduced. Thus, maintenance involves understanding the existing software (code and related documents), understanding the effects of change, making the changes - both to the code and documents, testing the new parts (changes), and resetting of the old parts that were not changed.

Since often during development, needs of the maintainers are not kept in mind, little support documents are produced during development to aid the maintainer. The complexity of the maintenance task is coupled with the neglect of maintenance concerns during development which makes maintenance the most cost effective activity in the life of a software product.

Error Distribution with Phases in Software Development Life Cycles 

A typical software product may take months to a few years for development, and is in operation for five to twenty years before it is withdrawn. For software, the cost of development is the incurred during requirement analysis, design, coding and testing. Therefore, the development cost is the total cost incurred before the product delivery. The cost of maintenance is the cost of modifying the software due to residual faults in the software, for enhancing or for updating the software. This cost is spread over the operational years of the software. Software engineers generally agree that the total cost of maintenance is more than the cost of development of software. The ratio of development to maintenance cost has been variously suggested as 40/60, 30/70 or even lower. However, it is generally accepted that the cost of maintenance is likely to be higher than the development cost, and are often not at all concerned with the maintenance.  

Since maintenance depends critically on the software characteristics that are decided during development, maintenance cost can be reduced if maintenance concerns are kept in forefront during development. One of the reasons why this is often not done is that the development cost is done by the developers while maintenance is often done by the users. Hence, the developers do not have much incentive for increasing the development effort in order to reduce the maintenance cost. However, for reduction in overall cost of software, it is imperative that the software be developed so the maintenance is easy.

The development cost, a typical distribution of effort with the different phases is

Requirement - 10%
Design - 20%
Coding - 20%
Testing - 50%

The exact number will differ with organization and the type of the project. There are some observation we can make from the data given above. The first is that the goal of design and coding should reduce the cost of design and coding, but should be to reduce the cost of testing and maintenance, at the expense of increasing design and coding cost. Both testing and maintenance depend heavily in the design and coding of the software. And these costs can be considerably reduced if the software is designed and coded to make testing and maintenance easier. Therefore, during design and implementation, the issues in our minds should be "can the design be easily tested", and "can it be easily modified". These require alternate designs and may increase the cost of the design and coding. But this additional costs pay dividends in the later phases.

Error Distribution

The notion that programming is the central of activity during software development is largely because normally programming has been considered to be difficult task and sometimes an "art". Another consequence of this kind of thinking is the belief that errors largely occur during programming, as it is the oldest activity in software development and offers many opportunities for commiting errors. It is now realized that errors can occur at any stage during development. A typical distribution of error occurrences by is

Requirement Analysis - 20%
Design - 30%
Coding - 50%

As we can see, errors occur throughout the development process. However the cost of correcting different phases is not the same and depends on when the error is detected and correceted. As one old expect, the greater the delay in detecting an error after it occurs, the more expensive it is to correct it. Error that occur during the requirements phase, if corrected after coding is completed, can cost many times more than correcting the error during the requirements phase itself. The reason for this is fairly obvious. If there is an error in the requirements, then the design and the code will get affected.

To correct the error, the coding that is done would require both the design and the code to be changed there by increasing the correction. So we should attempt to detect errors in the previous phase and should not wait until testing to detect errors. This is not often practiced. In reality, sometimes testing is the sole point where errors are detected. Besides the cost factor, reliance on testing as the primary source for error detection, due to the limitations of testing, will also result in unreliable software. Error detection and correction should be a continous proces that is done throughout software development. In terms of the development phases what this means is that we should try to validate each phase before starting with the next.

Different types of Software Development Life Cycle Models (SDLC) 

A Software Development Life Cycle Model is a set of activities together with an ordering relationship between activities which if performed in a manner that satisfies the ordering relationship that will produce desired product. Software Development Life Cycle Model is an abstract representation of a development process.  

In a software development effort the goal is to produce high quality software. The development process is, therefore, the sequence of activities that will produce such software. A software development life cycle model is broken down into distinct activities. A software development life cycle model specifies how these activities are organized in the entire software development effort. We discuss each software development life cycle model in detail.

1.                Waterfall Software Development Life Cycle Model

2.                Prototyping Software Development Life Cycle Model

3.                Iterative Enhacement Model

4.                The Spiral Model

5.                Object Oriented Methodology

6.                Dynamic System Development Method

Waterfall Software Development Life Cycle Model 

The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. A project begins with feasibility analysis. On the successful demonstration of the feasibility analysis, the requirements analysis and project planning begins.  

The design starts after the requirements analysis is done. And coding begins after the design is done. Once the programming is completed, the code is integrated and testing is done. On succeeful completion of testing, the system is installed. After this the regular operation and maintenance of the system takes place. The following figure demonstrates the steps involved in waterfall life cycle model.

The Waterfall Software Life Cycle Model

With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system.

The consequences of the need of certification is that each phase must have some defined output that can be evaluated and certified. Therefore, when the activities of a phase are completed, there should be an output product of that phase and the goal of a phase is to produce this product. The outputs of the earlier phases are often called intermediate products or design document. For the coding phase, the output is the code. From this point of view, the output of a software project is to justify the final program along with the use of documentation with the requirements document, design document, project plan, test plan and test results.

Another implication of the linear ordering of phases is that after each phase is completed and its outputs are certified, these outputs become the inputs to the next phase and should not be changed or modified. However, changing requirements cannot be avoided and must be faced. Since changes performed in the output of one phase affect the later phases, that might have been performed. These changes have to made in a controlled manner after evaluating the effect of each change on the project.This brings us to the need for configuration control or configuration management.

The certified output of a phase that is released for the best phase is called baseline. The configuration management ensures that any changes to a baseline are made after careful review, keeping in mind the interests of all parties that are affected by it. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the waterfall model.

For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway.

Any different ordering of the phases will result in a less successful software product.

Project Output in a Waterfall Model

As we have 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 forms the minimum 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.) 

·        Review reports 

Except for the last one, these are all the outputs of the phases. 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.

Advantages and limitations of the Waterfall Model 

 Advantages of Waterfall Life Cycle Models 

1.                Easy to explain to the user

2.                Stages and activities are well defined

3.                Helps to plan and schedule the project

4.                Verification at each stage ensures early detection of errors / misunderstanding

Limitations of the Waterfall Life Cycle Model

The waterfall model assumes that the requirements of a system can be frozen (i.e. basedline) before the design begins. This is possible for systems designed to automate an existing manual system. But for absolutely new system, determining the requirements is difficult, as the user himself does not know the requirements. Therefore, having unchanging (or changing only a few) requirements is unrealistic for such project.

Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement specification). A large project might take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing, it is quite likely that the final software will employ a hardware technology that is on the verge of becoming obsolete. This is clearly not desirable for such expensive software.

The waterfall model stipulates that the requirements should be completely specified before the rest of the development can proceed. In some situations it might be desirable to first develop a part of the system completely, an then later enhance the system in phase. This is often done for software products that are developed not necessarily for a client (where the client plays an important role in requirement specification), but for general marketing, in which the requirements are likely to be determined largely by developers.

Prototyping Software Life Cycle Model 

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.  

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. The process model of the prototyping approach is shown in the figure below.

Prototyping Model

The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. However, some argue that prototyping need not be very costly and can actually reduce the overall development cost. The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality. In addition, the cost of testing and writing detailed documents are reduced. These factors helps to reduce the cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing the final system. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system.

Advantages of Prototyping

1.                Users are actively involved in the development

2.                It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

3.                Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

4.                Errors can be detected much earlier as the system is mode side by side.

5.                Quicker user feedback is available leading to better solutions.

Disadvantages

1.  Leads to implementing and then repairing way of building systems.

2. Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

Iterative Enhancement Life Cycle Model 

The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine the benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented. At each step extensions and design modifications can be made. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.  

In the first step of iterative enhancement model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how far the project is at any given step from the final system.

Each step consists of removing the next step from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project control list is empty, at the time the final implementation of the system will be available. The process involved in iterative enhancement model is shown in the figure below.

The Iterative Enhancement Model

The project control list guides the iteration steps and keeps track of all tasks that must be done. The tasks in the list can be include redesign of defective components found during analysis. Each entry in that list is a task that should be performed in one step of the iterative enhancement process, and should be simple enough to be completely understood. Selecting tasks in this manner will minimize the chances of errors and reduce the redesign work.

The Spiral Life Cycle Model 

This is a recent model that has been proposed by Boehm. As the name suggests, the activities in this model can be organized like a spiral. The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. The structure of the spiral model is shown in the figure given below. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints.  

The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and constraints. This will also involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities such as benchmarkibg, simulation and prototyping. Next, the software is developed by keeping in mind the risks. Finally the next stage is planned.

The next step is determined by remaining risks. For example, its performance or user-interface risks are considered more important than the program development risks. The next step may be evolutionary development that involves developing a more detailed prototype for resolving the risks. On the other hand, if the program development risks dominate and previous prototypes have resolved all the user-interface and performance risks; the next step will follow the basic waterfall approach.

The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented, prototype-oriented, simulation-oriented or some other approach. An important feature of the model is that each cycle of the spiral is completed by a review, which covers all the products developed during that cycle, including plans for the next cycle. The spiral model works for developed as well as enhancement projects.

Spiral Model Description

The development spiral consists of four quadrants as shown in the figure above

Quadrant 1: Determine objectives, alternatives, and constraints.

Quadrant 2: Evaluate alternatives, identify, resolve risks.

Quadrant 3: Develop, verify, next-level product.

Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, let’s briefly address each one.

Quadrant 1: Determine Objectives, Alternatives, and Constraints  

Activities performed in this quadrant include:

1.                Establish an understanding of the system or product objectives—namely performance, functionality, and ability to accommodate change.

2.                Investigate implementation alternatives—namely design, reuse, procure, and procure/ modify

3.                Investigate constraints imposed on the alternatives—namely technology, cost, schedule, support, and risk. Once the system or product’s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks 

Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Boehm describes these activities as follows:

. . . This may involve prototyping, simulation, benchmarking, reference checking, administering user
questionnaires, analytic modeling, or combinations of these and other risk resolution techniques.

The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is “operationally useful and robust enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) . . . the option of writing specifications would be addressed but not exercised.” This brings us to Quadrant 3.

Quadrant 3: Develop, Verify, Next-Level Product 

If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to develop, verify, next-level product are performed. As a result, the basic “waterfall” approach may be employed—meaning concept of operations, design, development, integration, and test of the next system or product iteration. If appropriate, incremental development approaches may also be applicable.

Quadrant 4: Plan Next Phases 

The spiral development model has one characteristic that is common to all models—the need for advanced technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral.

Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations.