Software lifecycle

1
Software lifecycle
2
Reading

• Chapters 1 4 of Pressman.
• Chapter 1 covers some background regarding the
  nature of software.
• Chapter 2 covers some generic process methods
• Chapter 3 is the primary focus of this lecture
  discussion.
• Chapter 4 looks at Agile Programming the latest
  approach to software process/development.

3
Nature of Software

• Software is a complex component within a complex
  system.
• Often constraints (cost, performance, hardware,
  time, legacy systems) dictate how the software is
  to be developed.
• As software engineers we are relied upon to
• Analyze a clients needs.
• Design an appropriate solution within cost and
  time constraints.
• Build a safe, reliable, efficient, extensible
  solution.
• Test and fine-tune the software prior to
  delivery.
• Maintain the software after it goes into
  production.
• In many cases the software we develop may need to
  interact with other (third-party) software or
  legacy systems.

4
Software lifecycle
Requirements Analysis
Design Specification
Coding Module Testing
10
10-20
Integration System Testing
10-20
Delivery Maintenance
50-70
5
Software lifecycle student view
Design Specification
Coding
gt90
lt10
Testing (optional)
Hand it in
6
Comments

• The student lifecycle model clearly has many
  limitations
• It doesnt always earn you the grades you want.
• It doesnt scale.
• You have little assurance of quality somewhat
  of an issue for paying customers!
• It isnt consistent.
• We need a better model, a better process to
  follow, to give us a chance of delivering quality
  code in a timely manner.

7
Software production process models

• Adhoc 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 until Client is satisfied
Operations mode
Development
Retirement
Maintenance
8
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

9
Minimal waterfall model
Analysis
Design
Code
Testing
Maintenance
10
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

11
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

12
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

13
Detailed waterfall model
Requirements Verify
Changed Requirements Verify
Specification Verify
Planning Verify
Design Verify
Development
Maintenance
Implementation Test
Integration Test
Operations Mode
Retirement
14
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

15
Waterfall model - reality
Requirements analysis
System design
Maintenance
Program design
Delivery
System testing
Program implementation
Unit testing
Integration testing
16
Rapid prototyping model
Rapid Prototyping Verify
Changed Requirements Verify
Specification Verify
Planning Verify
Design Verify
Development
Maintenance
Implementation Test
Integration Test
Operations Mode
Retirement
17
Evolutionary model
Requirements Verify
Specification Verify
Planning Verify
Architectural design Verify
Development
Maintenance
For each build perform detailed design,
implementation and integration. Test. Deliver to
client
Operations Mode
Retirement
18
Evolutionary model

• Incremental development to
• Deliver partial functionality early
  (non-monolithic)
• 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

19
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

20
Evolutionary model prototyping
Build 1
Build 2
Build 3
. . .
. . .
. . .
Build n
Specification team
Design team
Implementation/integration team
21
Spiral model
Integration
Implementation
Design
Planning
Specification
Risk analysis
Rapid prototype
Risk analysis
R.A.
Verify
Risk analysis
Verify
Risk analysis
Verify
Verify
Risk analysis
Verify
22
Spiral model

• A metamodel 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

23
Spiral model prototyping
24
Agile Development

• Agile software development (i.e., Extreme
  Programming) combines a philosophy and a set of
  development guidelines.
• Encourages customer satisfaction and involvement
  through active and continuous involvement.
• Early incremental delivery of software to solicit
  customer feedback.
• Small, highly motivated project teams using
  informal methods and minimal software engineering
  work products.
• Strive for overall development simplicity. Stress
  delivery over analysis and design
• Agile development has its supporters and its
  detractors.

25
Agile Development

• Agile team members should have the following
  characteristics
• Competence
• Common focus
• Collaboration
• Decision-making ability
• Fuzzy problem-solving ability (ability to deal
  with ambiguity)
• Mutual trust and respect
• Self-organization
• Examples of agile development include
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Scrum
• Crystal
• Feature Driven Development (FDD)
• Agile Modeling (AM)

26
Is it worth it?

• Estimates for a 200,000 line data processing
  product
• CMM Duration Effort Faults detected Faults
  delivered Total cost
• Level (months) (person during to client of
• months) development and installed development
• Level 1 29.8 593.5 1348 61 5,440,000
• Level 2 18.5 143.0 328 12 1,311,000
• Level 3 15.2 79.5 182 7 728,000
• Level 4 12.5 42.8 97 5 392,000
• Level 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
  organizations activities. It is covered in more
  detail in CS451.

27
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
  deferred until CS451, 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.

28
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.

29
Journal

• In this course, we require you to keep 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
  intend 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 month), you should
  read through your journal and look for trends,
  look for errors you regularly make, look for
  things you dont understand.
• Once identified, plan a strategy to deal with
  these issues record the plan in the journal and
  stick to it.

30
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.