1characteristics of a good process

Characteristics of a good process

• Process should be precisely defined.• The step must be predictable.• Predictable process should be under statistical

control.• Process should support testing and

maintainability.

SDLC(Software development life cycle)

• Problem definition• Feasibility study• Analysis• System Design• Detailed design• Implementation• Maintenance

Problem Definition

This phase establish problem and define problem

To answer:• What is the problem• Who faced the problem• Where in the organization

Idea:• Meet user and management and obtain a

solution to their problem• If problem exist it need to be solved and

becomes a project• After this funds and resources are applied

Problem definition Document

• Project Title• Problem statement• Objective of project• Possible solutions• Project Scope• Indicate time and cost for feasibility step

Feasibility study

Types of feasibility:-1. Economical2. Technical3. Operational

Feasibility study report

1. Introduction-state problem-user environment-kind of solution you are preparing-kinds of constraints on the

project( cost, time, etc…)2. Recommendations3. Alternatives—for final approach

4. System description5. Cost benefit analysis6. Evaluation of technical risk7. Legal Ramification

Waterfall Model

• Produces many intermediate deliverable usually documents- which acts as a baseline

• Important for quality assurance and project management

• Widely used when requirement are well understood

System Engineering

Coding

Design

Analysis and Gathering

Testing

Deployment

Maintenance

System engineering

• Understand overall context of problem• Identify the responsibilities to be make

Analysis

• Problem domain is analyzed in more detail.Understand:-1. What kind of information is involved2. What kind of data is involved3. What functions need to be performed4. What are the performance and interfacing

requirements5. Purpose is to clearly defined the requirement

which are to be met

6. Also carry out project planning as part of same step

Purpose is to identify:1. What are the different steps2. What are different deliverables3. What would be the timeframe4. What would be the resources allocated

Design

Requirements are translated to1. software architecture2. Prepare database design

Design is divided into two parts:

1. High level design2. Low level design or detailed design

Coding

Testing

1. Unit testing2. Integration testing3. System testing

Deployment of software

• Implemented and Released• User will take control and start using software

Ongoing Maintenance

• If errors encountered necessary changes need to be made

• Performance requirement need to review.

Deliverables in waterfall model

1. Project Plan and feasibility report2. SRS(Software requirement specification) or

requirement document3. Design document:

- System design document- Detailed design document

4. Test Plans and Test Reports

5. Source code6.Software manuals (user manual, Installation

Manual)7. Review Reports (catalog how development

went through)

When to use the Waterfall Model

• Requirements are very well known• Product definition is stable• Technology is understood• New version of an existing product

Waterfall Strengths

• Easy to understand, easy to use• Provides structure to inexperienced staff• Milestones are well understood• Sets requirements stability• Good for management control (plan, staff, track)• Works well when quality is more important than cost

or schedule

Shortcomings in waterfall model

1. Requirement may not be completely known2. Requirement changes with time3. Heavy Documentation

V-Shaped SDLC Model• A variant of the Waterfall

that emphasizes the verification and validation of the product.

• Testing of the product is planned in parallel with a corresponding phase of development

V-Shaped Steps• Project and Requirements Planning –

allocate resources

• Product Requirements and Specification Analysis – complete specification of the software system

• Architecture or High-Level Design – defines how software functions fulfill the design

• Detailed Design – develop algorithms for each architectural component

• Production, operation and maintenance – provide for enhancement and corrections

• System and acceptance testing – check the entire software system in its environment

• Integration and Testing – check that modules interconnect correctly

• Unit testing – check that each module acts as expected

• Coding – transform algorithms into software

V-Shaped Strengths

• Emphasize planning for verification and validation of the product in early stages of product development

• Each deliverable must be testable• Project management can track progress by

milestones• Easy to use

V-Shaped Weaknesses

• Does not easily handle concurrent events• Does not handle iterations or phases• Does not easily handle dynamic changes in

requirements• Does not contain risk analysis activities

When to use the V-Shaped Model

• Excellent choice for systems requiring high reliability – hospital patient control applications

• All requirements are known up-front• When it can be modified to handle changing

requirements beyond analysis phase • Solution and technology are known

Structured Evolutionary Prototyping Model

• Developers build a prototype during the requirements phase

• Prototype is evaluated by end users• Users give corrective feedback • Developers further refine the prototype• When the user is satisfied, the prototype code

is brought up to the standards needed for a final product.

Evolutionary Delivery

Rapid Development, Taming Wild Software Schedules, by Steven McConnell, Press 1996

Structured Evolutionary Prototyping Steps

• A preliminary project plan is developed• An partial high-level paper model is created• The model is source for a partial requirements specification• A prototype is built with basic and critical attributes• The designer builds

– the database – user interface – algorithmic functions

• The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.

• This loop continues until the user is satisfied

When to useStructured Evolutionary Prototyping

• Requirements are unstable or have to be clarified • As the requirements clarification stage of a waterfall

model• Develop user interfaces• Short-lived demonstrations • New, original development

Limitations

1. Customer may want prototype itself (not maintainable, bad performance) 2. Developers may continue with

implementation choices(bad quality performance)

3. Good tools are required for quick development

4. May increase project cost

Incremental SDLC Model• Construct a partial

implementation of a total system • Then slowly add increased

functionality• The incremental model prioritizes

requirements of the system and then implements them in groups.

• Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

Incremental Model Strengths

• Develop high-risk or major functions first• Each release delivers an operational product • Customer can respond to each build• Uses “divide and conquer” breakdown of tasks• Lowers initial delivery cost • Initial product delivery is faster• Customers get important functionality early• Risk of changing requirements is reduced

Incremental Model Weaknesses

• Requires good planning and design• Requires early definition of a complete and

fully functional system to allow for the definition of increments

• Well-defined module interfaces are required (some will be developed long before others)

• Total cost of the complete system is not lower

When to use the Incremental Model • Risk, funding, schedule, program complexity, or need

for early realization of benefits.• Most of the requirements are known up-front but are

expected to evolve over time• A need to get basic functionality to the market early• On projects which have lengthy development

schedules• On a project with new technology