1characteristics of a good process
TRANSCRIPT
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