Software Development Stages

Software development involves many professionals.  Each specializes in a particular stage of the development process:

•    Analysis     ( analysts )
     
•    Design       ( engineers )
     
•    Implementation    ( programmers )
     
•    Operation         ( users )
     
•    Maintenance      ( technicians )

Formulating a Problem Precisely

A developer must investigate a problem before designing a solution.  The investigation should lead to a precise description of the problem, including:

• data required to be input
    
• outputs needed
    
• processing to be done
    
• outcomes required (goals)

Consequences of a Vague Problem Description

If a programmer (or designer) starts solving a problem before doing a thorough investigation and analysis, it is likely that :

•  important issues will be missed
    
•  the programmer will start and then throw away work and start again
    
•  the users will not be happy with the solution
    
•  the resulting software won't work well with the required hardware
   
•  the entire development process will be unnecessarily expensive

Collecting Data about the Problem

During the Analysis stage, the analyst should collect data from users ,
for example by

•    interviewing users
     
•    constructing questionnaires
     
•    observing current systems
     
•    studying potential user documentation and requests
     

Programmers Should NOT Do Analysis

The Analysis stage is probably not supervised by a programmer because:

•    it requires expert knowledge to understand the real-world requirements  
    
•    programmers are generally not interested in this type of work  
    
•    programmers' skills are expensive and should be used for writing programs  
    

Feasibility Study

A Feasibility Study might be produced during the Analysis phase, including :

•    estimated costs  
     
•    potential technical problems  
     
•    legal responsibilities  
     
•    estimated completion time  
     

Computer Systems

Software doesn't work alone.  A computer or information system consists of :

•  hardware
   
•  software
   
•  users
   
•  organization (documentation)

IPSO (facto?)

The 4 major components of all software systems are:

•  input
   
•  processing  (algorithms)
   
•  storage   (data structures)
   
•  output  

Decomposing Into Modules

Real-world problems are complex and messy.  The problem must be simplified and described clearly and completely before an effective solution can be designed.  One approach to simplifying a problem is to :

•  break it down into pieces (modules)
   
•  distinguish whether each module consists of hardware, software, or users
    
•  draw diagrams showing how modules interact,
    and how data flows between modules ( system flowchart )
   
•  write goals and requirements for each module and for the entire system

Consequences of Computer Systems

Widespread use of computers has social implications (consequences).  The ethical issues and dangerous consequences include:

•   effects on employment
   
•  computer abuse and misuse (hacking, viruses, etc)
   
•  legal problems (copyright issues)
   
•  economic problems ( expenses )
   
•  data protection (security = privacy, safety)  
   
•   crime (software piracy, identity theft)
  

Back to the Beginning

Software development goes through a life-cycle.  After a product is finished and used, it may be necessary to start over again and improve it.  This is because:

•  business and user needs change over time
    
•  bugs may be discovered after the software is already in use
   
•  new hardware developments make better software possible
    
•  partial solutions may be deployed with the intention of finishing them later

Prototyping

Prototyping means making a very simple version of a program before starting the real program.  This is useful because:

•  it helps clarify plans for input and output layouts
    
•  it can be shown to the user to get feedback at an early stage of the design process
    
•  it can be done at very low cost in a short time
   
•  it can help designers clarify their thinking by having something to look at
   
•  it can save time and money by getting "bugs out of the system" at an early stage

 Functional Prototype

A functional prototype is a small program that actually does something.  This is different than a layout prototype that only shows how IO screens will look.  A functional prototype can:

•  be used by the designer to check the feasibility of some processes,
   especially interfaces with hardware and existing systems
   
•  be used by an end-user to detect fundamental problems in the design
   
•  include code libraries that might be retained in the final program
    
•  be thrown away before starting the real program

Efficiency

The efficiency of a solution can be analysed during the design stage, by considering the following:

•  storage requirements (e.g. how much data must be stored, where, and how)
   
•  memory requirements (e.g. RAM)
   
•  speed  ( algorithm efficiency and CPU requirements ) 

 A GOOD designer thinks about these issues during the design process, especially if there are specific limitations imposed by existing systems.

Testing and Debugging

During the implementation stage, software must be tested and debugged, including:

•  Dry runs (reading the program and running tracing it with simple data)
    
•  Running test cases (data designed to test specific parts of the program)
   
•  Diagnosing errors (finding the cause of an error)
   
•  Debugging (handling bad data or correcting errors in the code)

IDE

An Integrated Develpment Environment is used by programmers during the implementation stage.  A good IDE includes :

•  an editor
   
•  a compiler or interpreter
   
•  debugging tools

Documentation Benefits

Documentation is needed at each stage of the system life cycle, because :

•  development usually involves many people who need to communicate clearly
   
•  it makes it possible to check whether one stage follows on sensibly from another
  (e.g. that the programmers are actually working toward the goals in the analysis)
   
•  developers for later versions may need to refer to earlier documentation

Forms of Documentation

Appropriate documentation includes:

•  goals at the end of the analysis stage
    
•  system module chart from the design stage
   
•  comments in the program listing during the implementation stage
   
•  user documentation (instructions) for the operations stage
   
•  maintenance records (problems and solutions) during the maintenance stage