Software Project Planning Size Estimation Metrics Planning Project

Software Project Planning & Size Estimation Metrics

Planning Project management activities can be viewed as having three major phases: 1. project planning 2. project monitoring and control 3. Project termination Because estimation lays a foundation for all other project planning activities and project planning provides the road map for successful software engineering. Estimation of resources, cost, and schedule for a software engineering effort requires experience, access to good historical information,

Factors Affecting the Estimation Process Project Complexity: The complexity of the software is more when first version of the software is developed. Complexity, however, is a relative measure that is affected by familiarity with past effort. Project size: As size increases, the interdependency among various elements of the software grows rapidly. The availability of historical information has a strong influence on estimation risk. Risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule

Project Planning Objectives: The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. The planning objective is achieved through a process of information discovery that leads to reasonable estimates. SOFTWARE SCOPE: describes the data and control to be processed, function, performance, constraints, interfaces, and reliability. Ø Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Ø Performance considerations encompass processing and response time requirements. Ø Constraints identify limits placed on the software by external hardware, available memory, or other existing systems.

1. Getting Necessary Information for Scope The very basic way to get the inforamtion is the interaction between the customer and the Developer. E. g. some basic questions may be: Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution? The next set of questions may be; How would you (the customer) characterize "good" output that would be generated by a successful solution? What problem will this solution address? Can you show me the environment in which the solution will be used? Will any special performance issues or constraints affect the way the solution is approached?

1. Getting Necessary Information for Scope contd. . The next level of the questions may be: • Are you the right person to answer these questions? Are answers "official"? • Are my questions relevant to the problem that you have? • Am I asking too many questions? • Can anyone else provide additional information? • Should I be asking you anything else? This kind of Q&A activity is to be done only to break the ice, then be replaced by a meeting format that combines elements of problem solving, negotiation, and specification. Normally there is problem of cooperation between the customer and the developer. To overcome these kind of problems, team oriented approach can be used called, facilitated application specification techniques (FAST).

2. Feasibility The next important question is: Can we build software to meet this scope? Is the project feasible? Once scope is understood, the software team and others must work to determine if it can be done within the dimensions just noted. This is a crucial, although often overlooked, part of the estimation process.

RESOURCES The second software planning task is estimation of the resources required to accomplish the software development effort. The development environment—hardware and software tools—sits at the foundation of the resources pyramid and provides the infrastructure to support the development effort. Next, we encounter reusable software components— software building blocks that can dramatically reduce development costs and accelerate delivery. At the top of the pyramid is the primary resource—people.

RESOURCES Each Resource is specified with four characteristics: Description of the resource. A statement of availability. Time when the resource will be required. Duration of time that resource will be applied.

RESOURCES 1. Human Resources: The planner will start planning by selecting the people with different skills, But for relatively small projects a single individual may performall software engineering tasks, consulting with specialists as required. 2. Reusable Software Resources: Component-based software engineering emphasizes reusability—that is, the creation and reuse of software building blocks. Off-the-shelf components: Existing software that can be acquired from a third party or that has been developed internally for a past project Full-experience components: developed for past projects that are similar to the software to be built for the current project. Partial-experience components: developed for past projects that are related to the software to be built for the current project but will require substantial modification. New components; Software components that must be built by the software team specifically for the needs of the current project

RESOURCES 3. Environmental Resources: The environment that supports the software project, often called the software engineering environment (SEE), incorporates hardware and software. a project planner must prescribe the time window required for hardware and software and verify that these resources will be available.

Size Estimation Metrics

Software Metrics “Software metrics are quantifiable measures that could be used to measure different characteristics of a software or the software development process. ”

Why? � Software size is critical factor for determining ¡ Cost ¡ Schedule ¡ Effort

Software Estimation � It is a part of Software project planning process. � Used to determine how much software to build. � Generally we estimate size too low. ¡ Results: ÷ Insufficient funding. ÷ Less time for development Key to software sizing. . • To use a variety of software sizing techniques • Not to rely on a single source or method for the estimate. • Because it affects program cost and may lead to risks.

Common types of size inaccuracies The earlier the estimate is made — the less is known about the software to be developed —and the greater the estimating errors. � Base your estimates on the smallest possible unit of each component Given our shortcomings in size estimation, it is absolutely critical that you measure, track, and control software size throughout development. � Analysis is necessary to determine trends in software size and functionality progress

Software Measurements can be categorized in two ways Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other "–abilities"

Software Measurement(Con. ) Easy (Direct) The cost and effort required to build software, The number of LOC(lines of code) produced etc. Difficult (Indirect) The quality and functionality of software Efficiency or maintainability

Size Oriented Metrics

In order to develop metrics that can be assimilated with similar metrics from other projects, we choose lines of code as our normalization value. a set of simple size-oriented metrics can be developed by considering Errors per KLOC (thousand lines of code). Defects per KLOC. 4 $ per LOC. Page of documentation per KLOC.

Other metrics Errors person-month. LOC person-month. $ per page of documentation.