12.1 Program development life cycle

Purpose of a development life cycle

Need for different development life cycles depending on the program being developed

• Waterfall
  • Logical progression of steps to be taken in sequence
  • Benefits
    • Clear pathway
    • Suitable for large scale projects with large teams
    • Every stage can be monitored
  • Drawbacks
    • Lack of adaptability across stages
    • Difficult to adjust to late user feedback

• Rapid application development
  • Developing different parts of the requirements in parallel
  • Using prototyping to provide early user involvement in testing
  • Program development cycles are run in parallel for each part of the
    requirement, using a number of different teams
    
  • Benefits
    • Progress is more measurable
    • Code is generated quickly
    • Code can be quickly changed when user gives feedback
  • Drawbacks
    • Difficult to use with large scale projects because part of the system may be quickly → changes will have to conveyed to several developers when the changes impact on their work
    • Demands frequent user contact and involvement

• Iterative
  • Cyclic process, multiple waterfalls
  • Produces an initial, simplified implementation
  • Each iteration produces enhancements
  • Benefits
    • Each iteration should be a quick process and result in a shorter development time
    • When problem arises, it is a quick process to roll back to use the previous iterated solution
  • Drawbacks
    • Generates pressure for continual user involvement
    • Because each new iteration will require testing and feedback from users
    • Users will tend to continually suggest new features to the next iteration that were not in the original requirements specification

Principles, benefits and drawbacks

Program development life cycle

• Analysis
  • Finding out what exactly is needed
  • Requirements are written down in a document called the requirements specification

• Design
  • What is considered?
  • E.g., tools used, the inputs, data storage, processing, outputs…
  • Flowcharts, state transition diagrams, structure charts

• Coding
  • Done by programmers

• Testing
  • Run with different sets of test data to test that it does everything it is supposed to do

• Maintenance
  • Maintained throughout its life to make sure it works effectively

12.2 Program design

Structure chart to decompose a problem into sub-tasks

State-transition diagrams

12.3 Program testing and maintenance

Different types of errors

• Syntax errors
  • Can be a simple spelling error or a statement that does not have the correct format

• Logic errors
  • Error in the programmer’s logic

• Run-time errors
  • Error only becomes apparent when an attempt is made to run the program

Methods of testing available

• Dry run
  • Code is read through and checked by hand by calculating in advance the expected results from the test data values used

• Walkthrough
  • A formal runthrough of dry run using pre-defined test cases

• White-box
  • The code inside the procedure is examined and test cases are devised that exercise every possible route through the code

• Black-box
  • Checks that a module is functioning correctly by supplying the required inputs to the procedure and monitoring the outputs
  • Only concerned in what goes in and what comes out of the procedure

• Integration
  • Checks that the modules run effectively together

• Alpha
  • Tested in house
  • Fix bugs and crashes of the software

• Beta
  • Made available to a selected number of potential customers for their feedback

• Acceptance
  • Final testing will be done in the workplace
  • Customer will formally “sign-off” the software as being acceptable

• Stub testing
  • Modules are replaced with dummy modules
  • Which contains an output statement to show they have been called
  • Allows testing to be started before all the code is written

Appropriate test data for a test plan

• Normal
  • Values within range is a normal value

• Abnormal
  • Values outside range is abnormal

• Extreme/boundary
  • Just at the boundary

Continuing maintenance of a system

• Perfective
  • Changes are made to improve the performance of the system

• Adaptive
  • Changes needed due to the changing needs of the system

• Corrective
  • Fix bugs that has not been found at the formal testing stage