Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view”...

Software lifecycle

CS351 - Software Engineering (AY2004) 2

Software lifecycle “student view”

Design &Specification

Coding

Testing(optional)

Hand it in

>90%

<10%


Comments• The “student lifecycle model” clearly has many

limitations:– It doesn’t always earn you the grades you want.– It doesn’t scale.– You have little assurance of quality – somewhat of an

issue for paying customers!– It isn’t consistent.

• We need a better model, a better process to follow, to give us a chance of delivering quality code in a timely manner.


Software production process models• Ad–hoc approach: “Code and Fix”

– intuitive “model”– undesirable even for small tasks– impossible for large tasks

• Many formal process models exist– Waterfall Model– Spiral Model– Prototyping/Evolutionary Model

Build first version

Modify untilClient is satisfied

Operations mode

Retirement

Development

Maintenance


Waterfall model – overview• A process model addresses these questions:

– What shall we do next?– How long shall we continue to do it?

• A framework for software development methodology• Clearly identifies

– Deliverables– Standards

• Waterfall model provides a sequential, linear flow between phases


Minimal waterfall model

Analysis

Design

Code

Testing

Maintenance


Waterfall model – requirements stages

• Feasibility study– Cost/benefit analysis– Needs understanding of problem– Deliverable - a feasibility study document

• Costs alternative solutions• Requirements

– Analysis• Functionality etc of software

– Specification document• “Contract” between customer and software

engineers• Complete, precise, modifiable• Specifies

– Functional requirements– Non-functional requirements– Development and maintenance procedures


Waterfall model – final stages• Design and specification

– Modules• Preliminary and detailed design

– Deliverable - design specification document– Standards

• Coding and module testing– Deliverable - tested modules– Standards for coding and testing, quality control

• Integration and system testing– Delivers running application - alpha tested within

organization


Waterfall model – final stages• Delivery and maintenance

– Beta testing then product delivery– Maintenance

• Problems– Time between requirements and maintenance

phases– Integrating changes into correct phases


Detailed waterfall model

RequirementsVerify

SpecificationVerify

PlanningVerify

DesignVerify

ImplementationTest

IntegrationTest

Operations Mode

Retirement

ChangedRequirements

Verify

Development

Maintenance


Waterfall model – example/analysis• Documentation, verification and management

– “Document driven"– Quality control: reviews, walk-throughs and

inspections– Management: methodology, configuration and

personnel• Analysis

– Linear, rigid, monolithic– Disciplined– Disadvantages

• Commitments too early• Rigidity and linearity make feedback difficult• Change often achieved as a "fix": distorts

maintenance phase• Somewhat bureaucratic


Waterfall model - realityRequirementsanalysis

Systemdesign

Programdesign

Programimplementation

Unittesting

Integrationtesting

System testing

Delivery

Maintenance


Rapid prototyping model

Rapid PrototypingVerify

SpecificationVerify

PlanningVerify

DesignVerify

ImplementationTest

IntegrationTest

Operations Mode

Retirement

ChangedRequirements

Verify

Development

Maintenance


Evolutionary model

RequirementsVerify

SpecificationVerify

PlanningVerify

ArchitecturaldesignVerify

For each build: perform detailed design, implementation and integration. Test. Deliver to client

Operations Mode

Retirement

Development

Maintenance


Evolutionary model• Incremental development to

– Deliver partial functionality early (non-monolothic)– Provide feedback on requirements

• May be associated with incremental delivery– Delivered increment is a product– User provides feedback for design of next increment

• Approach may be combined with waterfall model– During implementation phases

• Requirements document identifies subsets• Allowance for later change

– At all stages• Finer grained application of waterfall model to

each increment


Evolutionary model – prototyping• Prototyping

– “Throw-away”• Build system once - as basis for understanding

requirements• Discard and rebuild

– Build-upon• Iterative process

– Decide objectives of prototype– Plan, build and document prototype– Evaluate prototype

• Eventually refine into a completed system• Provides feedback on requirements and functionality • Facilitates understanding of requirements and interfaces• Flexible• Inherently less disciplined - needs careful management


Evolutionary model – prototyping

Specification DesignImplementation & Integration

Deliver to client


Deliver to client


Deliver to client

Build 1

Build n

Build 3

Build 2

Specification teamDesign team

Implementation/integration team


Deliver to client

......

...


Spiral model

Verify

Verify

VerifyVerify

VerifyRiskanalysis

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis

R.A.

Rapidprototype

Specification

Implementation

Design

Planning

Integration


Spiral model• A Meta–model really

– Any of the other process models can be used with it• Cyclic, not linear• Attempts to identify risks• Usually coupled with prototyping• Each “turn” around the spiral resolves more risks and

(possibly) yields a prototype


Spiral model – prototyping


Is it worth it?• Estimates for a 200,000 line data processing product:

CMM Duration Effort Faults detected Faults delivered Total costLevel (months) (person during to client of

months) development and installed developmentLevel 1 29.8 593.5 1348 61 $5,440,000Level 2 18.5 143.0 328 12 $1,311,000Level 3 15.2 79.5 182 7 $728,000Level 4 12.5 42.8 97 5 $392,000Level 5 9.0 16.0 37 1 $146,000

• CMM = Capability Maturity Model• CMM is a measure of an organizations ability to follow a

process and refine it to suit that organization’s activities. It is covered in more detail in CS460.


Observations• We need to understand the software development

lifecycle and have a process in place to help us deliver software on-time and within budget.

• Error rates and cost of development decrease the more we understand the software process.

• While discussion on requirements gathering etc is defered until CS460, we can certainly do a great deal to improve our own software by understanding what we do when we build software systems.

• As individuals, we most likely follow one of the lifecycle models described earlier – or a hybrid of one or more of the models.

• We may skip some steps, we may not pay sufficient attention to some aspects.


Our behavior• A better understanding of our personal behavior will

help us fit into a team environment better, and will help us deliver higher quality code.

• To understand what we do, we must objectively assess what we do.– This is difficult as we first have to overcome our

belief that we are doing everything correctly.– We have to examine what we do and constantly ask

“how can I improve?”– We have to measure what we do in order to know if

the changes we make are working, and to identify those aspects of our behavior that require change.


Personal software process• We have already seen the personal software process as

a means to identify several of the common errors we make.

• You should apply the PSP to all code you write – not just for this subject.

• Over time you will gather the information on yourself that you need to see what needs improving.– It will then, of course, be up to you to address those

deficiencies and improve.– You should continue to use the PSP to measure the

success of your changes and to identify further areas for improvement.


Journal• If addition to the use of the PSP, we also recommend you

need a journal.• A journal is where you record all of your thoughts, design

your algorithms, plan the testing strategy for these algorithms, make notes on the performance of your code, make notes on the kinds of errors you make, record how you ntend to rectify these deficiencies, …

• You record everything related to software development. • You should throw nothing away. Ideally, the journal is a

bound book with numbered pages.• At regular intervals (every few months), you should read

through your journal and look for trends, look for errors you regularly make, look for things you don’t understand.

• Once identified, plan a strategy to deal with these issues – record the plan in the journal and stick to it.


Summary• This course focuses on your personal ability to produce

high quality software.• You should make observations in your journal of errors

you make including:– Not fully understanding the requirements– Poor testing– Typical coding errors– Poorly designed interfaces– Integration issues

• These are all aspects of the software lifecycle• If we can get things right as an individual, we have a

better chance of getting things right in a team.

Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view”...

Documents

Transcript of Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view”...