Software Development Life Cycles

Software Development Life Cycles

     Life cycle: Entire duration of a project, from inception to termination

Different life cycle models

2.1. Code-and-fix model:

• Earliest software development approach (1950s)
• Iterative, programmers' approach
• Two phases: 1. coding, 2. fixing the code

No provision for:

• Project planning
• Analysis
• Design
• Testing
• Maintenance

Problems with code-and-fix model:

1. After several iterations, code became very poorly structured; subsequent fixes became very expensive
2. Even well-designed software often very poorly matched users’ requirements: were rejected or needed to be redeveloped (expensively!)
3. Changes to code were expensive, because of poor testing and maintenance practices

Solutions:

1. Design before coding
2. Requirements analysis before design
3. Separate testing and maintenance phases after coding

2.2. Waterfall model:

• Also called the classic life cycle
• Introduced in 1956 to overcome limitations of code-and-fix model
• Very structured, organized approach and suitable for planning

• Waterfall model is a linear approach, quite inflexible
• At each phase, feedback to previous phases is possible (but is discouraged in practice)

• Still is the most widespread model today

Main phases:

1. Requirements
2. Analysis
3. Design (overall design & detailed design)
4. Coding
5. Testing (unit test, integration test, acceptance test)
6. Maintenance

Approaches

The standard waterfall model for systems development is an approach that goes through the following steps:

1.     Document System Concept

2.     Identify System Requirements and Analyze them

3.     Break the System into Pieces (Architectural Design)

4.     Design Each Piece (Detailed Design)

5.     Code the System Components and Test Them Individually (Coding, Debugging, and Unit Testing)

6.     Integrate the Pieces and Test the System (System Testing)

7.     Deploy the System and Operate It

Waterfall Model Assumption

§  The requirements are knowable in advance of implementation.

§  The requirements have no unresolved, high-risk implications

        -- e.g., risks due to COTS choices, cost, schedule, performance,           safety, security, user interface, organizational impacts             

§  The nature of the requirements are compatible with all the key system stakeholders’  expectations

        -- e.g., users, customer, developers, maintainers, investors

§  The right architecture for implementing the requirements is well understood.

§  There is enough calendar time to proceed sequentially.

Advantages of Waterfall Model

§  Conversion of existing projects in to new projects.

§  For proven platforms and technologies, it works fine.

§  Suitable for short duration projects.

§  The waterfall model is effective when there is no change in the    requirements, and the             requirements are fully known .

§  If there is no Rework, this model build a high quality product.

§  The stages are clear cut

§  All R&D done before coding starts, implies better quality program design

Disadvantages with Waterfall Model:

§  Testing is postponed to later stage till coding completes.

§  Not suitable for large projects

§  It assumes uniform and orderly sequence of steps.

§  Risk in certain project where technology itself is a risk.

§  Correction at the end of phase need correction to the previous phase, So rework is more.

§  Real projects rarely flow in a sequential process.

§  It is difficult to define all requirements at the beginning of a project.

§  The model has problems adapting to change.

§  A working version of the system is not seen until late in the project's life.

§  Errors are discovering later (repairing problem further along the lifecycle becomes progressively more expensive).

§  Maintenance cost can be as much as 70% of system costs.

• Delivery only at the end (long wait)

2.3. Prototyping model:

• Introduced to overcome shortcomings of waterfall model
• Suitable to overcome problem of requirements definition
• Prototyping builds an operational model of the planned system, which the customer can evaluate

    Main phases:

1. Requirements gathering
2. Quick design
3. Build prototype
4. Customer evaluation of prototype
5. Refine prototype
6. Iterate steps 4. and 5. to "tune" the prototype
7. Engineer product

              Note: Mostly, the prototype is discarded after step 5. and the actual

                         system is built from scratch in step 6. (throw-away prototyping)

Possible problems:

• Customer may object to prototype being thrown away and may demand "a few changes" to make it working (results in poor software quality and maintainability)
• Inferior, temporary design solutions may become permanent after a while, when the developer has forgotten that they were only intended to be temporary (results in poor software quality)

Advantages

§  Helps counter the limitations of waterfall model

§  After prototype is developed, the end user and the client are permitted to use the   application and further modifications are done based on their feedback.

§  User oriented

• What the user sees
• Not enigmatic diagrams
• Quicker error feedback
• Earlier training

• Possibility of developing a system that closely addresses users' needs and expectations

§   

Disadvantages

• Development costs are high.
• User expectations
• Bypass analysis
• Documentation
• Never ending
• Managing the prototyping process is difficult because of its rapid, iterative nature
• Requires feedback on the prototype
• Incomplete prototypes may be regarded as complete systems

2.4 Incremental:

During the first one-month phase, the development team worked from static visual designs to code a prototype.  In focus group meetings, the team discussed users’ needs and the potential features of the product and then showed a demonstration of its prototype. The excellent feedback from these focus groups had a large impact on the quality of the product.

Main phases:

1. Define outline Requirements                                   4.    Develop
2. Assign requirements to increments                                      5.    Integrate
3. Design system architecture                                     6.    Validate

After the second group of focus groups, the feature set was frozen and the product definition complete. Implementation consisted of four-to-six-week cycles, with software delivered for beta use at the end of each cycle. The entire release took 10 months from definition to manufacturing release. Implementation lasted 4.5 months. The result was a world-class product that has won many awards and has been easy to support.

2.5 V-Model:

Verification à (Static System – Doing Right Job) To test the system correctness as to whether the system is being functioning as per specifications.

§  Typically involves in Reviews and Meetings to evaluate documents, plans, code, requirements and specifications.

§  This can be done with checklists, issue lists, walkthroughs and inspection meetings.

Validation   à  (Dynamic System - Job Right) Testing the system in a real environment i.e, whether software is catering the customers requirements.

§  Typically involves in actual testing and take place after verifications are completed

V A L I D ATI O N

V E R I F I C A T I O N

                   

Advantages

• Reduces the cost of defect repair (·.· Every document is verified by tester )
• No Ideal time for Testers
• Efficiency of V-model is more when compare to Waterfall Model
• Change management can be effected in V-model

Disadvantages

• Risk management is not possible
• Applicable of medium sized projects

2.6 Spiral model:

• Objective: overcome problems of other models, while combining their advantages
• Key component: risk management (because traditional models often fail when risk is neglected)
• Development is done incrementally, in several cycles _ Cycle as often as necessary to finish

  Main phases:

1. Determine objectives, alternatives for development, and constraints for the portion of the whole system to be developed in the current cycle
2. Evaluate alternatives, considering objectives and constraints; identify and resolve risks
3. Develop the current cycle's part of the system, using evolutionary or conventional development methods (depending on remaining risks); perform validation at the end
4. Prepare plans for subsequent phases

Spiral Model

This model is very appropriate for large software projects. The model consists of four main parts, or blocks, and the process is shown by a continuous loop going from the outside towards the inside. This shows the progress of the project.

§  Planning

This phase is where the objectives, alternatives, and constraints are determined.

§  Risk Analysis

What happens here is that alternative solutions and constraints are defined, and          risks are identified and analyzed. If risk analysis indicates uncertainty in the requirements, the prototyping model might be used to assist the situation.

§  Engineering

Here the customer decides when the next phase of planning and risk analysis occur.   If it is determined that the risks are to high, the project can be terminated.

§  Customer Evaluation

In this phase, the customer will assess the engineering results and make changes if   necessary.

Spiral model flexibility

• Well-understood systems (low technical risk) - Waterfall model. Risk analysis phase is relatively cheap
• Stable requirements and formal specification. Safety criticality - Formal transformation  model
• High UI risk, incomplete specification - prototyping model
• Hybrid models accommodated for different parts of the project

Advantages of spiral model:

• Good for large and complex projects
• Customer Evaluation allows for any changes deemed necessary, or would allow for new technological advances to be used
• Allows customer and developer to determine and to react to risks at each evolutionary level
• Direct consideration of risks at all levels greatly reduces problems

Problems with spiral model:

• Difficult to convince customer that this approach is controllable
• Requires significant risk assessment expertise to succeed
• Not yet widely used efficacy not yet proven
• If a risk is not discovered, problems will surely occur

2.7 RAD Model

• RAD refers to a development life cycle designed to give much faster development and higher quality systems than the traditional life cycle.
• It is designed to take advantage  of powerful development software like CASE tools, prototyping tools and code generators.
• The key objectives of RAD are: High Speed, High Quality and Low Cost.
• RAD is a people-centered and incremental development approach.
• Active user involvement, as well as collaboration and co-operation between all stakeholders are imperative.
• Testing is integrated throughout the development life cycle so that the system is tested and reviewed by both developers and users incrementally.

Problem Addressed By RAD

• With conventional methods, there is a long delay before the customer gets to see any results.
• With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use.
• With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered

 Bad Reasons For Using RAD

• To prevent cost overruns

                      (RAD needs a team already disciplined in cost management)

• To prevent runaway schedules

                      (RAD needs a team already disciplined in time management)

Good Reasons for using RAD

• To converge early toward a design acceptable to the customer and feasible for the developers
• To limit a project's exposure to the forces of change
• To save development time, possibly at the expense of economy or product quality

RAD in SDLC

• Mapping between System Development Life Cycle (SDLC) of ITSD and RAD stages is depicted as follows.

                        SDLC                                                                 RAD 

Essential Ingredients of RAD

• RAD has four essential ingredients:

¨      Tools

¨      Methodology

¨      People

¨      Management.

The following benefits can be realized in using RAD:

• High quality system will be delivered because of methodology, tools and user
• involvement;
• Business benefits can be realized earlier;
• Capacity will be utilized to meet a specific and urgent business need;
• Standards and consistency can be enforced through the use of CASE tools.

In the long run, we will also achieve that:

• Time required to get system developed will be reduced;
• Productivity of developers will be increased.

Advantages of  RAD

• Buying may save money compared to building
• Deliverables sometimes easier to port
• Early visibility
• Greater flexibility (because developers can redesign almost at will)
• Greatly reduced manual coding (because of wizards, code generators, code reuse)
• Increased user involvement (because they are represented on the team at all times)
• Possibly reduced cost (because time is money, also because of reuse)

Disadvantages of RAD

• Buying may not save money compared to building
• Cost of integrated toolset and hardware to run it
• Harder to gauge progress (because there are no classic milestones)
• Less efficient (because code isn't hand crafted)
• More defects
• Reduced features
• Requirements may not converge
• Standardized look and feel (undistinguished, lackluster appearance)
• Successful efforts difficult to repeat
• Unwanted features

3. Testing Life Cycle

A systemic approach for Testing

                                                                                               

3.1 System Study

1. Domain Knowledge :- Used to know about the client business           

Banking / Finance / Insurance / Real-estates / ERP / CRM /   Others

2. Software : -

-       Front End            (GUI) VB / JAVA/ FORMS / Browser

-       Process                Language witch we want to write programmes

-       Back End             Database like Oracle, SQL Server etc.

3.     Hardware: -  Internet/ Intranet/ Servers which you want to install.

4.     Functional Points: -            Ten Lines Of Code (LOC) = 1 Functional Point.

5.     Number of Pages: - The document which you want to prepare.

6.     Number of Resources : -Like Programmers, Designers, and Managers.

7.     Number of Days: -  For actual completion of the Project.

8.     Numbers of Modules

9.     Priority:-  High/ Medium/ Low  importance for Modules   

3.2 Scope/ Approach/ Estimation:

   Scope

• What to test
• What not to test

  Approach

• Methods, tools and techniques used to accomplish test objectives.

   Estimation

• Equivalence Class Estimation should be done based on LOC/ FP/Resources

-       1000 LOC = 100 FP (by considering 10 LOC = 1 FP)

-       100 x 3 = 300 (FP x 3 Tech. = Test Cases)

The 3 Tech are

1.      

2.     Boundary Value Analysis

3.     Error Guessing.

-       30 TC Par Day => 300/30 = 10 Days to Design Test Cases

-       Test Case Review => ½ of Test Case Design  (5 Days)

-       Test Case Execution = 1 ½ of  Test Case Design(15 Days)

-       Defect Headlining = Test Case Design (5 Days)

-       Test Plan = 5 days ( 1 week )

-       Buffer Time = 25% of Estimation

3.3 Test Plan Design:

• A test plan prescribes the scope, approach, resources, and schedule of testing activities.
• The Test Plan Design document helps in test execution it contain

1.     About the client and company

2.     Reference document (BRS, FRS and UI etc.)

3.     Scope (What to be tested and what not to be )

4.     Overview of Application

5.     Testing approach (Testing strategy)

6.     For each testing

¨     Definition

¨     Technique

¨     Start criteria

¨     Stop criteria

7.     Resources and there Roles and Responsibilities

8.     Defect definition

9.     Risk / Contingency / Mitigation Plan

10. Training Required

11. Schedules

 Deliverables