All of the technical and managerial activities required to deliver a software product to a client are collectively referred to as a software project. A software project has a specific duration, consumes resources, and produces deliverables. From the perspective of a developer, a software project consists of project functions, activities and tasks. Figure4.1 depicts a project model, as described by Bernd Bruegge (Bruegge2004). A project function is an activity, or set of activities, that spans the entire duration of the project. Examples of project functions include configuration management, documentation, quality control, training, and testing.
Each of these activities begins in the early stages of the development process, and continues through the development life of the software product. An activity is described as a smaller unit of work. Activities are often small enough for adequate planning and tracking but also large enough to quickly complicate micro man-agement. Finally, a task is the smallest unit of management accountability. Tasks are the building blocks of the development process, and larger units of work are composed of multiple, complimentary tasks. Tasks, by nature, have a predeter-mined, finite duration, require specific resources, and produce tangible results, such as code, documentation, etc.
The decomposition of a software engineering project into units of work allows for a development team to both focus effort on specific jobs, and to easily classify and organize the entire project in a useful and understandable way. Such practices have led developers to define tasks in such a way that all of their characteristics may be specified in a meaningful way. Bruegge lists the following attributes of a task that should be specified during planning and development:
• Name and description of work to be done.
• Preconditions for starting, required resources, and task duration.
• Task completion criteria: tangibles to be produced and acceptance criteria for those tangibles.
• Risk involved.
R. Y. Lee, Software Engineering: A Hands-On Approach,
DOI: 10.2991/978-94-6239-006-5_4, Atlantis Press and the author 2013
61
(Bruegge2004)
Proper project planning deals with the identification of activities, milestones, and deliverables that are to be produced as the result of a project. A plan is drawn up in order to guide the development process toward the established project goals.
Cost estimation is a closely related activity, concerned with estimating the resources needed for the successful completion of a project (Sommerville2004).
This activity will be explained in detail later in this chapter.
4.1.1 Identifying the Purpose of the Project
Project planning begins with a simple goal: determination of software scope and purpose. This may seem like an obvious first step, but for that very reason it is often overlooked. If an effective and well-defined purpose is not laid out at the onset, developers and clients will not be able to understand the connection between the development process and the final product. This will result in the project quickly getting off track due to a loss of focus. For this reason, the basic objectives of the project should be considered and determined at the project’s onset. The required function and performance of the software being developed should be assessed in order to establish a project scope that is unambiguous and under-standable at both the managerial and technical levels. Of course, many aspects of a project are somewhat hazy at the beginning of the development process. Often, a final product will get defined and the basic goals and objectives will be enunciated.
However, the information necessary to define the scope (a prerequisite for esti-mation) is commonly not yet generated from the relationship between real the world phenomena to be represented and the abstractions that will make up the final software product. For this reason, it is of paramount importance to permit the use of adequate time and resources in order to develop an effective project plan.
Project
Function
Function
Activity Activity Activity
Activity Activity Activity
Task Task Task Task
Fig. 4.1 Model of a software project and the constituent activities (Bruegge2004)
62 4 Starting the Project
The scope of a software project is used to describe the function, performance, constraints, interfaces, and reliability of, as well as the data to be processed by, the software system. Functions are initially described in the statement of a system’s scope, are later evaluated and, if needed, refined in order to provide the proper level of detail required for accurate and successful estimation phases. Because both cost and schedule estimates are function oriented, a degree of decomposition is often useful in providing a meaningful picture of the development process. A scope’s statement of performance encompasses both processing and response time requirements for the software system. The statement of a system’s constraints is used to identify the limits within which the software system will exist, as imposed by factors such as external hardware, available memory, or other preexisting systems.
4.1.2 Identifying the Deliverables of the Project
Following the identification of a project’s purpose and scope, the software engi-neering team must now create a set of goals to be met throughout the process. This is accomplished through the establishment of a series of milestones, or recog-nizable endpoints for specific development activities. This practice allows a pro-ject to be broken down into distinct, logical sections. Closely related to this concept is that of producing deliverables. Deliverables make up the tangible results of the development process such as code, documentation, cost estimates, or reports from engineers. As a milestone is reached, the deliverables produced by the included development activities are completed. The relationship between a mile-stone and the related deliverables allows both, for the sequential production of the various portions of the software project, as well as the assessment of the devel-opment team’s progress.
4.1.3 Cost Estimation
Finally, the third activity involved in project planning is cost estimation. Cost estimation is the practice of calculating the amount of resources required to suc-cessfully complete the software project. These resources come in two basic cat-egories: money and time. Certainly, there are other types of resources, such as personnel or work space, however, resources of this type can usually be reduced back to money; in this case salary and rent. Both estimate types are of critical importance to the relationship between the client and developer. They are also at the core of establishing the cost the client will pay.
Schach defines two types of money cost estimates, as characterized by the party for which they are intended. The internal cost is the cost for the development team, while the external cost is the price tag that will be given to the client (Schach 2008). The internal cost is the composition of the various costs the
development team must pay out. These include employee salaries, hardware and software costs, and overhead costs such as rent and utilities. In other words, the internal cost is the actual cost required to develop the software. The external cost, then, includes both the internal cost, as well as any additional profit that the development team intends to generate from the client. The difference between the internal and external costs varies from project to project and from organization to organization. The amount of profit added by a development firm in order to cal-culate the external cost is based on many factors. This is a key component in a client’s decision to accept one firm’s bid over that of another. For this reason, cost estimation and the determination of an appropriate profit margin are the deter-mining factors of whether or not the project in question will even exist.
The proper estimation of a project’s timeline is equally as important as financial projections. The development team is responsible for establishing a development schedule, which provides the client with both a final delivery date, as well as a timeline by which it can judge the development team’s progress. Failure to stick to this schedule on the part of the developer can lead to a number of negative consequences. These can include the loss of future business or in some cases, may even lead to the application of financial or legal penalties.
Before a specific software engineering firm is selected and a project is begun, the organizations bidding for the project develop initial time, or duration, and financial estimates, and then submit these to the client. From these estimates, the client can determine the feasibility and potential profit of the product in question.
If the client chooses to undertake the project, they will then select an organization based on the list of projections. From this point on, it is the responsibility of the chosen development firm to uphold the contract constituted by those estimates.
Right away, the selected firm begins to develop more detailed estimates, which will be used to plan the upcoming development process. Throughout the devel-opment cycle, additional estimates are created to continually guide the project. As we can clearly see, software engineering cost estimates are not just a tool for initial conjecture, but rather, they are also a continually updated progress report, and an adaptable, multipurpose planning tool.