11

Planning aPlanning aSoftware ProjectSoftware Project

22

Defining the ProblemDefining the ProblemDefining the problem

1. Develop a definitive statement of the problem to be solved. Include a description of the present situation, problem constraints and a statement of the goals to be achieved.

2. Justify a computerized solution strategy for the problem

3. Identify the functions to be provided by, and the constraints on, the hardware subsystem, the software subsystem and the people subsystem.

4. Determine system-level goals and requirements for the development process and the work products

5. Establish high-level acceptance criteria for the system

33

Developing a solution strategy 6. Outline several solution strategies, without regard

for constraints.7. Conduct a feasibility study for each strategy.8. Recommend a solution strategy, indicating why

other strategies were rejected.9. Develop a list of priorities for product characteristics

Planning the development process10.Define a life-cycle model and an organizational

structure for the project11.Plan, the configuration management, quality

assurance and validation activities12.Determine phase-dependent tools, techniques and

notations to be used

44

13.Establish preliminary cost estimates for system

development

14.Establish a preliminary development schedule

15.Establish preliminary staffing estimates.

16.Develop preliminary estimates of the computing

resources required to operate and maintain the

system

17.Prepare a glossary of terms

18.Identify sources of information and refer to them

throughout the project plan

55

Developing a solution strategyDeveloping a solution strategy

A solution strategy is not a detailed solution, but rather a general statement concerning the nature possible solutions. Strategy factors include considerations such as batch or time-sharing; database or file system; graphics or text; real time or off-line processing, etc

Several strategies should be considered before one is adopted.

Strategies should be generalized without regard for feasibility because it is not possible for humans to be both creative and critical at the same time.

66

The feasibility of each proposed solution strategy can be established by examining solution constraints.

It is extremely important to document the reasons for rejecting other strategies. A solution strategy should include a priority list of product features.

Planning the development process

The first consideration is to define a product life-cycle model. The software life cycle encompasses all activities required to define, develop, test, deliver, operate and maintain a software product

77

The phased life cycle model

The phased model segments the software life

cycle into a series of successive activities. Each phase

requires well-defined input information, utilized well-

defined processes, and results in well-defined

products. Resources are required to complete the

process in each phase, and each phase is

accomplished through the application of explicit

methods, tools and techniques.

88The phased life cycle model

99

The feasibility of each proposed solution strategy can be established by examining solution constraints.

It is extremely important to document the reasons for rejecting other strategies. A solution strategy should include a priority list of product features.

Planning the development process

The first consideration is to define a product life-cycle model. The software life cycle encompasses all activities required to define, develop, test, deliver, operate and maintain a software product

1010

Milestones, Documents and Reviews

Another view of the software life cycle that

emphasizes the milestones, documents and review

throughout the product development. As a software

product evolves through the development cycle, it is

often difficult, if not impossible for project managers

and project team members to asses the progress, to

determine resources expended, to protect schedule

delays or to anticipate problem areas. Establishing

milestones, review points, standardized documents

and management sign offs can improve product

visibility

1111

1212

The Cost Model

Another view of the software life cycle can be

obtained by considering the cost of performing the

various activities in a software project. The cost of

conducting a software project is the sum of costs

incurred in conducting each phase of the project.

Costs incurred within each phase include the cost of

performing the processes and preparing the products

for the phase, plus the cost of verifying that the

products of the present phase are complete and

consistent with respect to all previous phases

1313

The Cost Model of the Software Life Cycle

1414

The Prototype Life Cycle Model

Another view of the software development and maintenance, emphasizes the sources of product requests, the major go/no-go decision points and the issues of prototypes. A prototype is a mock-up or model of components of the actual product. A prototype exhibits limited functional capabilities, low reliability and/or inefficient performance.

Reasons for developing prototype

1. Illustrate input data formats, messages, reports and

interactive dialogues for the customer.

2. To explore technical issues in the proposed product

3. Where a phased model is not appropriate.

1515

Successive Versions

Product development by the method of successive versions is an extension of prototype in which an initial product skeleton is refined into increasing levels of capability

1616

Planning an organizational structure

The tasks include planningProduct DevelopmentServicesPublications Quality AssuranceSupport and Maintenance

The planning task identifies external customers and internal product needs, conducts feasibility studies and monitors progress from beginning to end of the product life cycle.

1717

The development task specifies designs, implements, debugs, tests and integrates the product.

The service task provides automated tools and computer resources for all other tasks, and perform configuration management, product distribution and miscellaneous administrative support.

The publication task develops user’s manuals, installation instructions, principles or operation and other supporting documents

The support task promotes the product, trains users, installs the product. The maintenance task provides error correction and minor enhancements throughout the productive life cycle of the software product

1818

Other planning activities

Planning for configuration management and quality assurance

Planning for independent Verification and validation

Planning Phase-Dependent Tools and Techniques

Other Activities

1919

Software Cost Estimation Software Cost Estimation

Estimating the cost of a software product is one of the most difficult and error-prone tasks in SE. It is difficult to make an accurate cost estimate during the planning phase of software development, since so many unknown factors will be there.

Expert JudgmentDelphi Cost EstimationWork Breakdown StructureAlgorithmic Cost Models

2020

Expert Judgment

The most widely used cost estimation technique is expert judgment, which is an inherently top-down estimation technique. Expert judgment relies on the experience, background and business sense of one or more key people in the organization.

The judgment will be based on a previous project, which is almost similar.

Advantages: EmpiricalDisadvantages: Subjective

2121

Delphi Cost Estimation

The Delphi technique can be adapted to software cost estimation in the following manner.

A coordinator provides each estimator with the System Definition document and form for recording a cost estimate.

Estimators study the definition and complete their estimates anonymously. They may ask questions to the coordinator, but they do not discuss their estimates with one another.

The coordinator prepares and distributes a summary of the estimators’ responses, and includes any unusual rationales noted by the estimators.

2222

Delphi Cost Estimation

Estimators complete another estimate again anonymously using the results from the previous estimate. Estimators whose estimates differ sharply from the group may be asked, to provide justification for their estimates.

The process is iterated for as many rounds as required. No group discussion is allowed during the entire process.

2323

Work Breakdown Structure The work breakdown structure is a bottom-up

estimation tool. A work breakdown structure is a hierarchical chart that accounts for the individual parts of a system. A WBS chart can indicate the product hierarchy or process hierarchy.

We can use either a process WBS or a product WBS for cost estimation. The primary advantages of the WBS technique are in identifying and accounting for various process and product factors, and in making explicit exactly which costs are included in the estimates.

2424

Algorithmic Cost Models Algorithmic cost estimators compute the

estimated cost of a software system as the sum of the costs of the modules and subsystems that comprise the system. Algorithmic cost models are bottom-up estimators. The algorithmic method is designed to provide some mathematical equations to perform software estimation

The most widely used algorithmic model is the Constructive Cost Model (COCOMO)

2525

The COCOMO ModelThe COCOMO Model Model to estimate the development cost and

schedule of a software project. Introduced by Barry Boehm in 1981. First two letters of the words Constructive Cost Model Primarily based on the software development

practices prior to 1980s, i.e. based on the Waterfall model.

The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of Person-Months required to develop a project..

2626

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms.

Basic COCOMO - is a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.

Intermediate COCOMO - computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes.

Detailed COCOMO - incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.

2727

Project ClassesProject Classes

Organic mode: small teams, familiar environment, well-understood applications, no difficult non-functional requirements (EASY)

Semi-detached mode: Project team may have experience mixture, system may have more significant non-functional constraints, organization may have less familiarity with application (HARDER)

Embedded: Hardware/software systems, tight constraints, unusual for team to have deep application experience (HARD)

2828

Organic mode: PM = 2.4 (KDSI)1.05

Semi-detached mode: PM = 3 (KDSI)1.12

Embedded mode: PM = 3.6 (KDSI)1.2

KDSI = Kilo Delivered Source Instructions PM is the nominal effort in person months

Basic COCOMO Formula