Development processes

To try to reduce the number of unsuccessful projects, we must thoroughly understand all aspects of the software development process.

In this course, we will focus on the early stages of the software development process: planning, analysis, and the early stages of design. Other courses will focus more heavily on the design and implementation areas.

The reason for many projects' failure can be traced to mistakes in the early project stages - misunderstandings of the specific project requirements, scope, timeline, budget, reliability requirements, etc etc can all lead to situations which force the cancellation or downsizing of projects. Remember that virtually every project undertaken must effectively improve the business situation of the client - the client is the driving factor in major projects - not the programmer. If a product doesn't do what the client needs from it, then regardless of how technically clever it is, the project is a failure.

A central figure throughout the software development process is the systems analyst: this person (or team of people) analyzes the business situation, identifies opportunities for improvement, and designs and information system to implement the selected changes.

Development phases: there are many different approaches adopted to develop new software systems, but almost all of them include a handful of key phases:

• planning - here we identify why a system should be built, what the associated risks are, and what the scope of the project will be
  - we also identify how the project team will accomplish the desired tasks, identifying the time, staff, training, and resource requirements, required tasks and timetables, etc

• analysis - in this phase we identify exactly what the system must do from a user perspective - this includes identifying ALL visible system behaviour from the point of view of everyone who will come in contact with the system
  - this involves extensive information gathering, modeling, and review with all the people who are connected with the system operation

• design - in this phase we decide and plan how the system will carry out all the requirements and objectives identified in analysis, and in the end we produce a detailed set of specifications outlining how the system is to be built

• implementation - in this stage we finally actually build the system, test and debug it, and carry out any installation required to get the system running successfully for the user

Typically there are a series of iterations through these various steps, explicitly or implicitly, and each step has associated with it a number of deliverables. These deliverables are files, documents, or presentations necessary to the product and/or the project.

Common models: there are many different development styles, here we briefly consider 3 of them. (A fourth will be introduced as an example below.)

• The waterfall model - this is perhaps the simplest model, and is the easiest to develope a project plan around, but it does not handle revision well.

  This model involves taking each phase described above and completing it thoroughly before moving on to the next phase:

   
  planning 
  	| 
  	analysis 
  		| 
  		design 
  			| 
  			implementation    
  

• The spiral model: this uses the same four phases, but performs each multiple times - i.e. we carry the project out in 2-5 stages, and in each stage we revise and expand our plan, revise and expand our analysis, revise and expand our design, and revise and expand our implementation

  This model is more time consuming because of the increased administrative overhead, but tends to result in more reliable products - particularly for very complex systems

• Iterative prototyping - this process is very difficult to plan around, but can be a reasonable approach for very experimental systems, or systems where the user has very little idea initially about exactly what is required

  The process is simply to repeat the following until the user is satisfied with the product:

  • revise any implementation carried out so far, trying to create what you think the user might want
  • get user feedback on the newest version
  • go back to step 1

  Project team roles and skills

  To ensure that no aspect of the project is overlooked, it is common to assign team members roles or responsibilities within the project.

  One possible breakdown of roles is shown below, and another is discussed in the example later on.

  • Business analyst - responsible for the business issues surrounding the project (including the system value, processes, and policies)

  • Systems analyst - responsible for identifying how existing technology can best be applied to improve or develope the current system, and for designing the new business information system

  • Infrastructure analyst - responsible for handling the technical issues in terms of how the new system interacts with the rest of the organization (networks, databases, interfaces with hardware and software, platforms, etc)

  • Change manager - responsible for planning the changeover to the new system, training and user education, fallback/recovery procedures, etc

  • Project manager - responsible for organizing and planning the overall development project, managing the team and resources, and acting as the primary contact between the team and the rest of the organization(s)

  Obviously the specific skills an analyst will need depends heavily on the role(s) the analyst is supporting, and on the specific project. However, many of the most commonly needed skills include:

  • communication skills (presentation development and delivery, writing skills, verbal skills, etc)
  • management, leadership, and organizational skills
  • programming abilities (platforms, languages, network skills, database expertise, familiarity with previous or similar systems, etc)
  • modeling and analysis skills
  • application domain (familiarity with the application area of the product)
  • ability to adapt quickly to changing requirements, resources, and goals
  • ability to handle both high-pressure and low-pressure situations

  Example: a Microsoft-based model

  The MSF model is similar to the spiral model: we develop a project in versions: each version comes closer to the ultimately-desired full set of features.

  For each version, we carry out four stages:

  • envisioning - in which we identify the vision (large scale view) and scope (immediate practical view) of the project, covering much of the analysis phase discussed
  • planning - in which project planning for the current version is carried out
  • development - covering most of the design and implementation stages
  • stabilizing - in which we identify and correct any immediate issues identified in the early stages of "real use" of the product

  There are six key roles to be supported throughout the entire process:

  • development - someone must represent the design and implementation teams and interests at each stage
  • user education - someone must represent the people who will actually be using the system
  • product management - someone must represent the client (remember this is not usually the same as the person who winds up using the product, particularly in a large organizational environment)
  • logistics - someone must be responsible for migration and installation plans, hotlines, trouble shooting, recovery plans etc
  • testing - someone must be responsible for ensuring all issues have been identified and (hopefully) a work-around or fix established prior to release
  • program management - someone must be responsible for controlling specifications, technical decisions and communication

  The usability engineering life cycle

  This life cycle model is another iterative one, with three primary phases (analysis, development, and installation), each with their own subphases.

  The phase breakdown is roughly as follows:

  • Requirements analysis
    The requirements analysis phase is much like that in the waterfall model, but here is explicitly preceded by the establishment of usability goals and a style guide.

    • Update the usability goals:
      • Develop/refine the user profiles
      • Carry out task analysis, refine use cases and scenarios
      • Identify platform capabilities/constraints
      • Refine the general design principles

    • Based on the usability goals, update the style guide

    • Refine the process and data models
      (adhering to the revised goals and style guide)

  • Design, Test, and Development
    The design, test, and development cycle is carried out at three levels of detail:

    • Level 1
      This is a cyclic process, and is repeated until all the major flaws have been eliminated:
      • Revise the work processes
      • Revise the conceptual model of the system
      • Produce mockups of the revised model
      • Evaluate the mockups

    • Level 2
      This is also a cyclic process, and is repeated until all the usability goals have been met:
      • Revise the screen design standards
      • Produce prototypes of the screens
      • Evaluate the screen prototypes

    • Level 3
      This cycle also iterates until all usability goals have been met, but is carried out at a deeper level of detail:
      • Revise the detailed user interface design
      • Implement the detailed user interface design
      • Evaluate the detailed deisgn

  • Unless all functionality has been met, return to requirements analysis for refinement...

  Following the completion of the product itself, the installation or rollout phase is also a phased process:

  • Install the product or enhancement
  • Obtain user feedback
  • Identify necessary enhancements
  • If enhancements are needed, return to the analysis/development cycle...