1. 1 Planning a Software Project

2. 2 Defining the Problem Defining 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

3. 3 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 process 10.Define a life-cycle model and an organizational structure for the project 11.Plan, the configuration management, quality assurance and validation activities 12.Determine phase-dependent tools, techniques and notations to be used

4. 4 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

5. 5 Developing 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.

6. 6 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

7. 7 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.

8. 8 The phased life cycle model

9. 9 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

10. 10 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

11. 11

12. 12 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

13. 13 The Cost Model of the Software Life Cycle

14. 14 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.

15. 15 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

16. 16 Planning an organizational structure The tasks include planning Product Development Services Publications Quality Assurance Support 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.

17. 17 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

18. 18 Other planning activities Planning for configuration management and quality assurance Planning for independent Verification and validation Planning Phase-Dependent Tools and Techniques Other Activities

19. 19 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 Judgment  Delphi Cost Estimation  Work Breakdown Structure  Algorithmic Cost Models

20. 20 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: Empirical Disadvantages: Subjective

21. 21 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.

22. 22 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.

23. 23 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.

24. 24 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)

25. 25 The 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.

26. 26 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.

27. 27 Project 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)

28. 28 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