Software development processes

The life cycle of a software product - from inception of an idea for a product through

• domain analysis
• requirements gathering
• architecture design and specification
• coding and testing
• delivery and deployment
• maintenance and evolution
• retirement

Issues with software quality

• The quality and cost of software has been a growing concern
• Delivered long behind schedule
• At much higher cost than anticipated
• Without giving the desired benefits and user satisfaction

Reasons

• It is hard to understand the purpose of a system well enough to plan its functionality in advance so that it will really satisfy the user needs.
• The complexity of systems and their dynamic behavior is too high.
• The visibility nature of the product makes the development and maintenance process itself difficult to understand and control.
• There is a lack of proven components to use as high level building blocks. Too much is developed from scratch.

Problems with black-box approach:

• The assumption is that requirements can be fully understood prior to development
• Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
• There is usually a communication problem

Advantages of white-box approach:

• Reduce risks by improving visibility
• Allow project changes as the project progresses, based on feedback from the customer
• There are different software development process based on the white-box approach: Waterfall, Iterative, Agile processes

Waterfall process

• Invented in the late 1950s for large air defense systems, popularized in the 1970s
• They organize activities in a sequential flow
• Standardize the outputs of the various activities (deliverables)
• Exist in many variants, all sharing sequential flow style

Example of activities:

Strength of waterfall process:

• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Simplifies the process management

Weakness of waterfall process:

• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be too late)

Waterfall to be used when . . .

• Requirements are very well known
• Product definition is stable
• Technology is very well understood
• New version of an existing product (maybe!)
• Porting an existing product to a new platform
• In general:
  • High risk for new systems because of specification and design problems.
  • Low risk for well-understood developments using familiar technology.

Iterative process

Also referred to as incremental development process. Develop system through repeated cycle (iterations)

• Each cycle is responsible for the development of a small portion of the solution (slice of functionality)
• Contrast with waterfall: Water fall is a special iterative process with only one cycle

Agile methods

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods:

• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly to meet changing requirements

The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

MANIFESTO: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value (that is, while there is value in the items on the right, we value more the items on the left):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Problems with agile methods:

• It can be difficult to keep the interest of customers who are involved in the process
• Team members may be unsuited to the intense involvement that characterizes agile methods
• Prioritizing changes can be difficult where there are multiple stakeholders
• Minimizing documentation: almost nothing is captured, the code is the only authority

Future outlook

More and more activities of the software development process can be automated by using appropriate CASE tools. This course provides some introduction to some of such tools:

• State machines or Activity diagrams may be used as prototypes that model the functional requirements of the system to be built – or that represent the functional design of the system.
• Many CASE tools provide executable models that can be used for interactive simulation and other V&V activities
• So-called Model Checking tools can be used to prove that such models have certain desirable properties (in all circumstances). An example of such a property is the absense of deadlocks which is particularly difficult to determine in the case of several interacting system components. In this course, we will use a very simple tool, called LTSA, for this purpose.
• After validation, correct implementation code can be generated automatically. Most UML CASE tools provide such facilities. We will use the Umple tool for this purpose.
• In the context of compiler construction and language analysis, CASE tools exist for dealing with lexical and syntax analysis of language input. We will use tools supporting regular expressions for lexical analysis, and understand how the generation of syntax parsers can be automated.

The following figures were presented by David Harel (the author of Hierachical State Charts) to show how he sees software development within the coming decades: