Showing posts with label Software Engineering. Show all posts
Showing posts with label Software Engineering. Show all posts

Tuesday, June 22, 2010

Software Cost Estimation Part 1

Software cost estimation is the process of predicting the effort required to develop a software system

Accurate software cost estimates are critical to both developers and customers. They can be used for generating request for proposals, contract negotiations, scheduling, monitoring and control.

The importance of accurate cost estimation lies in following functions of management.

  1. Budgeting - the primary but not the only important use. Accuracy of the overall estimate is the most desired capability.
  2. Trade off & Risk Analysis - an important additional capability is to illuminate the cost and schedule sensitivities of software project decisions (scoping, staffing, tools, reuse, etc.).
  3. Project Planning & Control - an important additional capability is to provide cost and schedule breakdowns by component, stage and activity.
  4. Investment Analysis for Enhancements - an important additional capability is to estimate the costs as well as the benefits of such strategies as tools, reuse, and process maturity.
Software cost estimation historically has been a major difficulty in software development.
Several reasons for the difficulty have been identified:
  1. Uncertainty or frequent changes in customer requirements
  2. Rapidly changing technologies and obsolescence of technologies
  3. Lack of a historical database of cost measurement
  4. Many interrelated factors whose relationships are not well w.r.t development efforts and productivity
  5. Lack of trained estimators with the necessary expertise
The widely practiced cost estimation method is expert judgment. For many years, project managers have relied on experience and the prevailing industry norms as a basis to develop cost estimate. However, basing estimates on expert judgment has following pitfalls.
  • This approach is not repeatable
  • The means of deriving an estimate are not explicit.
  • It is difficult to find highly experienced estimators for every new project.
  • The relationship between cost and system size is not linear. Cost tends to increase exponentially with size. The expert judgment method is appropriate only when the sizes of the current project and past projects are similar.
  • Budget manipulations by management aimed at avoiding overrun make experience and data from previous projects questionable.
So far, many quantitative software cost estimation models have been developed. ranging from empirical models such as Boehm’s COCOMO models to analytical models.

An empirical model uses data from previous projects to evaluate the current project and derives the basic formula from analysis of the particular database available.

An analytical model, on the other hand, uses formula based on global assumptions, such as the rate at which developer solves problems and the number of problems available.


Irrespective of the model chosen,
actual cost estimation process involves following seven steps:
  1. Establish cost-estimating objectives
  2. Generate a project plan for required data and resources
  3. Pin down software requirements
  4. Work out as much detail about the software system as feasible
  5. Use several independent cost estimation techniques to capitalize on their combined strengths
  6. Compare different estimates and iterate the estimation process
  7. After the project has started, monitor its actual cost and progress, and feedback results to project management
No matter which estimation model is selected, users must pay attention to the following to get best results:
  1. coverage of the estimate (some models generate effort for the full life-cycle, while others do not include effort for the requirement stage)
  2. calibration and assumptions of the model
  3. sensitivity of the estimates to the different model parameters
  4. deviation of the estimate with respect to the actual cost
Till now the entire discussion was finding cost and then price. But there exists ways to find the cost in reverse way i.e. find the price first and cost. I know this will make every software professional little surprised but believe me this is true.

Won't keep you in wonder for long and will soon write on it. Till then, you can wonder on what is called Economic Value Estimation (EVE). This is more of a marketing subject and very new to software profession as jargon. But believe me we do this things for long.

References:
Software Cost Estimation
Herding Cats: Software Estimating
Software Development Cost Estimation Approaches

Read more...

Thursday, June 3, 2010

The Software Team Structure

In India, Software organizations are mushrooming everywhere. With diversity in resources, skill sets and quick obsolescence of technology, structure team has become a crucial issue.

Mantei suggested three generic team structure.

1. Democratic Decentralized (DD)

This team structure is driven by group cohesiveness in making group decisions and solving problems with consensus. There is no group leader as such. A task coordinator is chosen for short duration based on skill or experience level. On completion of task, the coordinator may replaced by other.

2. Controlled Decentralized (CD)

Unlike DD, here team has a specific leader whose primary task is to divide the project into tasks and assign groups to accomplish them. He may choose a task coordinator for each group. The communication in group will be horizontal and between groups, communication will be vertical. Here groups and individuals are involved for decision making and problem solving.

3. Controlled Centralized (CC)

The structure is almost similar to CD, but communication and involvement differs. Communication is always vertical. Decision are made by top level management people. There is very little or no involvement of groups in decision making.


In the image, direction of arrow shows low to high transition. CC encourages less innovation compared to DD. Similarly decision speed is higher in CC compared CD.

Mantei suggested following factors for considerations before structuring a team

  • Difficulty of the problem
  • Size of the resultant program(s) in lines of code or function points
  • Team lifetime
  • Degree of Modularization
  • Required Quality and System Reliability
  • Rigidity of the delivery date
  • Degree of communication required for the project
Because a centralized structure completes tasks faster, it is the most adept at handling simple problems.

Decentralized teams generate more and better solutions than individuals. Therefore such teams have a greater probability of success when working on difficult problems.

Since the CD team is centralized for problem solving, either a CD or CC team structure can be successfully applied to simple problems. A DD structure is best for difficult problems.


Read more...

Umbrella Activities

The software engineering work can be carried out in three phases.

Definition Phase

It focuses on
What. In this phase, key requirements of the system are identified. A software engineer talks about Information to be processed, Constraints, Users, functions, performance etc. Broadly, it involves three activities

  • Information Engineering
  • Software Project Planning
  • Requirement Analysis
Development Phase

It focuses on How. This phase is all about implementation. It involves designing the system, deciding programming languages and architecture, writing code, designing database models etc. Broadly this phase is performed by following three activities.
  • System Design
  • Coding
  • Testing
Support Phase

It focuses on Change. It reapplies preceding phases on existing software. The change can be of following types.
  • Corrective Maintenance - changes to resolve defects.
  • Adaptive Maintenance - changes to accommodate new external environment.
  • Perfective Maintenance - extends the functional requirements
  • Preventive Maintenance - changes the software to reduce the deteriorate due to other type of changes
All these phases are complemented by a number activities like reviews, tracking, risk management, document preparation etc. These activities are called Umbrella activities.

Read more...

Followers

  © Blogger templates Psi by Ourblogtemplates.com 2008

Back to TOP