Unit 2.Software Life Cycle

Unit 2.Software Life Cycle

In this unit, you will cover the different stages of the software life cycle in a bit more detail and you will read about specific life-cycle models for software development.

2.1Overview of the Life Cycle
2.2Life-Cycle Methodologies

Assessments

Exercise 1
Multiple-Choice Quiz 2

2.1Overview of the Life Cycle

In this module, we will review and examine in some detail the different phases of a software product's lifecycle. Further detail about specific methodologies to apply in each phase is contained in later units of the course.

Readings:

Schach (6th Edition), sections 3.1-3.2.

2.1.1 Problem Identification and Scope
2.1.2 Requirements Analysis and Specification
2.1.3 System Design
2.1.4 Implementation
2.1.5 Testing and Delivery
2.1.6 Maintenance

2.1.1 Problem Identification and Scope

Statement of Scope

The decision to develop a new software system, either internally or via external contracting is typically justified when some important requirement of the organization is not currently being met. Perhaps there is no software currently supporting certain crucial activities. Maybe some existing software has become obsolete and is no longer able to perform effectively the tasks it was designed to do. Perhaps the requirements of the task itself have changed. When making a decision to develop (or purchase) new software, it is essential to first understand the problem well, to verify that a software solution is appropriate, and to confirm that there are not other (possibly simpler and cheaper) ways to address the problem.

Consider, for example, the case of a restaurant starting out as a small family-run business. Initially, with only a few tables, limited clientele, and short operating hours, the accounting books are kept on paper manually. As the business expands, the owners realize that they are starting to spend too much time balancing the books and making sure that expenses and income from patrons are logged. At that point, they may find it sufficient to purchase a computer with a small, off-the-shelf accounting package. However, suppose that the business keeps growing, requiring much more floor space and acquiring many more customers. On the one hand, it is becoming a real success—the customers love the food and keep coming back for more. On the other hand, customers begin complaining that it takes too long to process their orders, and too often, they find out, some time later, that the restaurant has run out of what they ordered. The restaurant management decides that they would like a hardware/software product that in addition to balancing the books, allows the waiters to key in the orders and send the order to the kitchen right at the table, so customers will know immediately whether their choice is available. One advantage of this proposed system, the reasoning goes, is that it also keeps track of what customers want, helping the management make better decisions about menu planning, including the quantities of different foodstuffs to have on hand. Another advantage is that as each order is placed, the inventory of basic food ingredients can be automatically updated, making it easier for the management to make daily purchasing decisions.

The solution that the restaurant management chooses may result in a very fancy order and inventory management system, but it is likely to require a significant financial investment, some amount of personnel training, and an increased budget for equipment maintenance. It is possible that the original problem with customer dissatisfaction can be solved much more simply by adding waiters, or giving them radios to communicate customer orders back to the kitchen. The inventory update problem might be solved by connecting the cash register with an inventory management software package, allowing dynamic inventory update based on each new order.

The first part of problem identification, therefore, is to define the problem as precisely as possible and consider a range of solutions and their associated costs. This analysis is essential in determining the viability of a decision to build new software. Another aspect of problem identification is determining the scope of a solution. For example, if an organization decides that they must have custom-built software, does the resulting software product need to be implemented for different hardware platforms, or is the organization's computing base homogeneous, a group, for example, of only PC-compatible machines? Depending on the type of software application desired, developing for one or more hardware platforms may require significantly different levels of investment.

The responsibility for problem identification usually rests with the client, but the software engineer must be sensitive to mismatches between the problem as described by the client and the solution the client believes to be appropriate. While no software developer wants to refuse a contract, it is not a good idea in the end to build and sell a product that will not adequately address the customer's problem.

Statement of Scope

An effective strategy for balancing the perspectives of both customers and engineers is to write a formal statement of scope. A typical scope statement might include:

Preliminary requirements checklist: The preliminary requirements checklist is typically a brief summary of all the primary functionality the customer requires from the software (for example, "The software must support online ordering of products from our Web site"; "The software must generate monthly ordering statistics sorted by product and geographic area"; etc.).

Customer scope constraints: The customer's idea of scope is typically phrased in terms of constraints that identify minimal expectations for the operation of the software (for example, "The software must handle at least 100 transactions per minute"; "The software must run on Windows NT4.0"; etc.).

Developer scope constraints: There may be a wide range of software solutions that satisfy the preliminary functional requirements and customer scope constraints. It is in the developer's best interest to propose the simplest solution with these characteristics, because it will typically be the most cost-effective system for the customer. On the other hand, it is important for the developer to delimit the functionality of the proposed system. By defining what will and will not be included, one can keep the customer from feeling cheated if software requirements become more demanding after the project is started or after the software is delivered. Additional scope constraints are placed on the software in order to identify the maximal expectations placed on the final product (for example, "The software will be designed to handle a maximum of 100 transactions per minute"; "The software will only be guaranteed to run under Windows NT4.0"; etc.).

A well-written scope statement is the most precise way to specify the problem to be solved, along with the characteristics of the possible software solution(s) to the problem.

2.1.2 Requirements Analysis and Specification

Requirements Analysis Phase
Specification Phase
Software Project Management Plan (SPMP)

Readings:

Schach (4th Edition), sections 2.2, 2.3, and 9.1. Remark: As an optional reading, chapter 9, discusses prototyping more fully.
Schach (5th Edition), sections 2.2, 2.3, and 10.1. Remark: As an optional reading, chapter 10, discusses prototyping more fully.
Schach (6th Edition), sections 3.3-3.4, 10.1-10.4. Remark: As an optional reading, chapter 10, discusses prototyping more fully.

After the client and the developer have agreed on the general goals of the software development effort, the next step is to determine more precisely the requirements that the software product must satisfy, and to specify the expected input and output of the system in detail. The requirements and specification phases must be completed before detailed design can begin, and certainly, before any coding is attempted. In the case of object-oriented design, an analysis of the characteristics of the required software objects may begin as early as the specifications phase, even though "objects" are also considered part of the design and implementation phases. The differences between these two kinds of analysis will be discussed more fully in 4.1.1 Object-Oriented vs. Structured Analysis.

Requirements Analysis Phase

The requirements phase is of great importance to the success of a software project. Unfortunately, requirements phase is often carried out incompletely or else neglected altogether. During the requirements phase, the client and developer must determine exactly what functionality the software must have in order to meet the customer's requirements. They must also negotiate important constraints, constraints like limitations on development cost, major deadlines that the project must respect, the performance and reliability expected of the system, and any other constraints imposed by the hardware and operating system.

A precise definition of software requirements (that is, the desired functionality) may be one of the most difficult aspects of the requirements phase. The client may not be able to articulate in a clear and precise manner what the software needs are. The developer may need a variety of techniques to use to elicit the client's real requirements. Traditional methods for eliciting requirements include structured and unstructured interviews, questionnaires, and examination of the process that the client is trying to automate.

In structured interviews, the developer asks preplanned, close-ended questions—questions for which a particular form of answer is desired. For example, the developer might ask how many people will be using the system at the same time or what kinds of data input the system will need to process. To gain a better understanding of how the client will use the software product, the developer may also engage the end users of the product in interviews that are more informal. In an unstructured interview, the developer asks open-ended questions. For example, the developer might ask users to describe the tasks they will perform and the way they normally process information.

Less direct but potentially very informative ways of learning about the process that the software product will support include examining forms used to process information, spending time observing the users as they perform their normal activities in order to understand the nature of the task, and recording those activities with a video camera. Observation and recording can be perceived as intrusions, so this method should be discussed with the client and the users. Note that it is quite common for the "client" and the "user" to be different individuals belonging to the same organization. In discussions with the developer, the "client" is often represented by technical management personnel, but the real day-in-day-out "users" of the software are likely to be other members of the staff. It is important to talk to the users in order to understand their tasks in detail, and to discern whether the proposed functional requirements will result in a software product that meets their needs.

An alternative (and complementary) method for requirements definition is to perform rapid prototyping. A rapid prototype is a piece of software that is developed quickly to demonstrate the visible aspects of the desired functionality. Robustness and error handling are typically not present in a rapid prototype and much of the internal computation may be simulated or left out. For example, if the major aspect of a software product is the interface it will present to the users, it may be sufficient to "mock-up" an interface using a graphical user interface (GUI) toolkit, without actually writing any application code. Rapid prototyping is a particularly good approach to take when the client is not able to give the developer a clear idea of how the software should operate. By building a rapid prototype, the developer provides the client with a concrete proposal based on the information the client can offer. The prototype can then serve as a focus for discussing, modifying, and refining ideas further. Under the rapid prototyping approach, several prototype systems may be built before the client is satisfied that the prototype reflects his or her needs; when agreement is reached, the requirements for the actual software product can be derived from the final prototype.

Once the requirements have been made explicit, through elicitation and/or rapid prototyping, the developer can assess the technical feasibility of the proposed software and provide cost estimates. It may turn out that it is technically impossible to achieve the stated objectives, or that it is practically impossible within the time and financial constraints imposed by the client. Any perceived gaps between the required functionality and the feasibility assessment are cause for further discussion and refinement or even for a decision not to proceed at all, if the requirements and constraints cannot be changed.

The requirements for a software product, whether embodied in a rapid prototype or a requirements document, should undergo thorough testing before the requirements phase is left behind. The development organization's software quality assurance (SQA) group should verify that the prototype and/or the requirements document are completely satisfactory to both client and user, before these documents become the basis for a more detailed specification. Unfortunately, the existence of an approved requirements document will not prevent the client from trying to change the requirements later, but such a document does provide a precise statement regarding the software that the developer is under contract to develop.

We will be taking a closer look at rapid prototyping in 2.2.3 Rapid Prototyping Model.

Specification Phase

The ultimate goal of the specification phase, which is sometimes also called the system analysis phase, is to model the desired software product. We build models of the data the system must process (data dictionariesand entity relationship models), models of the transmission of data among different components (data flow analysis), and models of the flow of control from component to component based on the state of the system (control flow analysis). Different techniques, many of them graphical (data flow diagrams, for example), are used for specifying the various aspects of the product. It is important to note that these models and techniques, which will be discussed in Unit 3, specify what the system must do and not how it does it. The how is the purview of the design phase, which will be described next in 2.1.3 System Design.

The goal of the specification phase is to transform the general requirements for a software product into a concrete document describing what the system will and will not do: this document to be produced is called the specification document, or simply the specifications. The specification document describes the functionality of the system, makes explicit the constraints the system must satisfy (speed or maximum error rate, for example), and specifies the expected input and corresponding output. The input-output specifications should include a description of how the system should respond to unexpected and erroneous input. In addition, the specifications document may include acceptance criteria. These may just be a restatement of the constraints and input-output behavior, or a set of tests that a system must pass. For example, in the case of a system designed to translate between English and other languages, the acceptance criteria could stipulate that the system will be accepted if it translates correctly 90% of the sentences contained in texts that have not been used previously during development and testing.

The specification document functions as a legal contract. The developer will consider the contract completed when it delivers a software product that satisfies the acceptance criteria set out in the specifications. To avoid complications and disagreements about whether or not a delivered product meets specifications, the specification document should be carefully checked for the following problems:

Vagueness of the language: The document should not use terms that are not or cannot be defined precisely. These include such obviously vague terms as "ample memory" or "sufficient speed," as well as terms that sound precise but are not, like "optimal speed" or "98% complete."
Ambiguity of the language: The document should be checked for statements that can be interpreted in more than one way. Consider the following: "The interface module will call the arithmetic module. If the module receives erroneous input, it will signal an error to the error handler." The phrase "the module" in the second sentence can refer to either the interface module or the arithmetic module.
Incompleteness of the specifications: Common types of omissions include failure to consider all legal values of an input, failure to specify system behavior under unexpected or incorrect input, and failure to consider all possible combinations of input when a system makes decisions based on multiple inputs.
Inconsistency of the specifications: In the specification document for a large system, it is possible that the same situation arises in more than one context, and it is easy to specify different behaviors for that situation in different places of the document. For example, the specification document for a database interface system might say that when the data in an entry form is committed, errors in any of the data areas of the form will prevent the commit process from completing successfully. Elsewhere in the document, it might say that each field in the data entry form is individually checked for incorrect values when the cursor leaves the field, and that no further action is permitted until the error is rectified. In a subtle way, these statements are inconsistent or contradictory, because if the second statement is true and the user enters an incorrect value, then the interface should not even allow the user to request a commit action.

Like the requirements document, the specifications document must be carefully examined by the developer's SQA group, as well as the specification team and the client, before it is approved and used as the basis for further work. In addition to checking for problems such as vagueness, ambiguity, incompleteness, and inconsistency, the SQA group should determine the feasibility of the specifications based on information provided by the client. A very desirable characteristic of the specification document is traceability, that is, the ability to trace every one of its statements to something the client said during the requirements phase. Ideally, it should be possible to link each statement in the specification document either to a statement in the requirements document or to the rapid prototype from which requirements were derived. A formal review process, in which developer and client teams go through the entire document systematically, is a good way of formally testing the specifications. We will describe different ways of performing formal document reviews in Unit 6.