Software Estimation The COCOMO Model COCOMO for COnstructive

Software Estimation

The COCOMO Model • COCOMO, for COnstructive COst Model • The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. • Application composition model • Early design stage model • Post-architecture-stage model

Cont. . Object type COMPLEXITY WEIGHT Simple Medium Difficult Screen 1 2 3 Report 2 5 8 3 GL component 10 (1) screens (at the user interface), (2)reports, (3) components likely to be required to build the application is classified into one of three complexity levels (i. e. , simple, medium, or difficult)

• component-based development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated and the object point count is adjusted: NOP = (object points) x [(100 %reuse)/100] where NOP is defined as new object points.

• To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be derived. PROD = NOP/person-month Developer's Very experience/capabi low lity Low Nominal High Very High Environment maturity/capabilit y Very low Low Nominal High Very High PROD 4 7 13 25 50 ESTIMATED EFFORT = NOP/PROD

SCHEDULING • Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. • Program evaluation and review technique (PERT) and critical path method (CPM) are two project scheduling methods that can be applied to software development.

• Estimates of effort. • A decomposition of the product function. • The selection of the appropriate process model and task set. • Decomposition of tasks. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions.

(1) determine the critical path—the chain of tasks that determines the duration of the project; (2) establish “most likely” time estimates for individual tasks by applying statistical models; (3) calculate “boundary times” that define a time "window" for a part icular task.

describes important boundary times that may be discerned from a PERT or CPM network: (1) the earliest time that a task can begin when all preceding tasks are completed in the shortest possible time. (2) the latest time for task initiation before the minimum project completion time is delayed (3) the earliest finish—the sum of the earliest start and the task duration, (4) the latest finish— the latest start time added to task duration (5) the total float—the amount of surplus time or leeway allowed in scheduling tasks so that the network critical path is maintained on schedule.

Timeline Charts • creating a software project schedule, the planner begins with a set of tasks. • Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals. • a timeline chart, also called a Gantt chart

THE PROJECT PLAN • The Software Project Plan is produced at the culmination of the planning tasks. • The Software Project Plan is a relatively brief document that is addressed to a diverse audience. (1)communicate scope and resources to software management, technical staff, and the customer. (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software development for all people associated with the project; (5) outline how quality will be ensured and change will be managed.

The Software Team • There almost as many human organizational structures for software development as there are organizations that develop software. • the organization of the people directly involved in a new software project is within the project manager's purview

The following options are available for applying human resources to a project that will require n people working for k years: • n individuals are assigned to m different functional tasks, relatively little combined work occurs; – coordination is the responsibility of a software manager who may have six other projects to be concerned with. • n individuals are assigned to m different functional tasks ( m < n ) so that informal "teams" are established; – an ad hoc team leader may be appointed; coordination among teams is the responsibility of a software manager.

• n individuals are organized into t teams; each team is assigned one or more functional tasks; • each team has a specific structure that is defined for all teams working on a project; • coordination is controlled by both the team and a software project manager.

Three generic team organizations • Democratic decentralized (DD)- "task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks. “ • Controlled decentralized (CD)- This software engineering team has a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks.

• Controlled Centralized (CC)-- Top-level problem solving and internal team coordination are managed by a team leader. • Communication between the leader and team members is vertical.

• SOFTWARE QUALITY

• Seven project factors that should be considered when planning the structure of software engineering teams. – The difficulty of the problem to be solved. – The size of the resultant program(s) in lines of code or function points – The time that the team will stay together (team lifetime). – The degree to which the problem can be modularized. – The required quality and reliability of the system to be built. – The rigidity of the delivery date. – The degree of sociability (communication) required for the project