Coupon Accepted Successfully!


Planning And Managing The Project



Initiating the project

The SRO, or identifier of the potential project should:

  1. Define and justify the need for the project
  2. Specify, quantify and agree desired outcome and benefits
  3. Appoint a Project Manager and if appropriate set up a Project Board

The project management team should:

  1. Plan how to deliver the required outcomes and benefits
  2. Decide how to manage relationships with key stakeholders
  3. Decide how to project manage the delivery process
  4. Determine resource requirements and ensure they can be made available when required
  5. Develop Business Case to enable the SRO/Project Board to decide whether project is cost and risk justified.

The SRO should ensure:

  • Post project reviews are carried out to measure the degree to which benefits have been achieved
  • The Business Case is updated to reflect operational reality
  • Potential improvements/changes/opportunities identified in the reviews fed into the strategic planning process for consideration

Planning checklist

  1. Confirm scope and purpose of the plan:
  2. Define the deliverables:
  3. Identify and estimate activities
  4. Schedule the work and resources
  5. Identify risks and design controls
  6. Document and gain approval for the plan

Software Estimation


Estimation techniques

Organizations need to make software effort and cost estimates. There are two types of technique that can be used to do this: Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers:

  Effort = A ‘SizeB’ M

A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.

The most commonly used product attribute for cost estimation is code size.Most models are similar but they use different values for A, B and M.

The COCOMO 2 model

Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2.COCOMO 2 takes into account different approaches to software development, reuse, etc.

COCOMO estimation models

Project Formula Description complexity

  • Simple PM = 2.4 (KDSI)1.05 × M Well-understood applications
  • developed by small teams.
  • Moderate PM = 3.0 (KDSI)1.12 × M More complex projects where
  • team members may have limited
  • experience of related systems.
  • Embedded PM = 3.6 (KDSI)1.20 × M Complex projects where the
  • software is part of a strongly
  • coupled complex of hardware,
  • software, regulations and
  • operational procedures.

Application composition model

Based on standard estimates of developer productivity in application (object) points/month.

Formula is

  • PM = ( NAP × (1 - %reuse/100 ) ) / PROD
  • PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

Application-point productivity

Based on a standard formula for algorithmic models

  • PM = A × SizeB × M where
  • A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity.

Reuse model estimates

  1. For generated code:
  • PM = (ASLOC * AT/100)/ATPROD
  • ASLOC is the number of lines of generated code
  • AT is the percentage of code automatically generated.
  • ATPROD is the productivity of engineers in integrating this code.
  1. When code has to be understood and integrated:
  • ESLOC = ASLOC * (1-AT/100) * AAM.
  • ASLOC and AT as before.
  • AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of reuse decision making.

Post-architecture level

The code size is estimated as:

  • Number of lines of new code to be developed;

Scale factors used in the exponent computation in the post-architecture model

Scale factor : Explanation

Precedentedness Reflects the previous experience of the organisation with this type of project. Very low means no previous experience. Extra high means that the organisation is completely familiar with this application domain.

Development Reflects the degree of flexibility in the development process. Very low means a prescribed process is used;

flexibility Extra high means that the client only sets general goals.

Architecture/risk Reflects the extent of risk analysis carried out. Very low means little analysis, Extra high means a complete a
resolution through risk analysis.

Team cohesion Reflects how well the development team know each other and work together. Very low means very difficult interactions. Extra high means an integrated and effective team with no communication problems.

Process maturity Reflects the process maturity of the organisation. The computation of this value depends on the CMM maturity Questionnaire but an estimate can be achieved by subtracting the CMM process maturity level from 5.

Project duration and staffing

Calendar time can be estimated using a COCOMO 2 formula

  • TDEV = 3, (PM)(0.33 + 0.2* (B-1.01))

PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project.The time required is independent of the number of people working on the project.

Test Your Skills Now!
Take a Quiz now
Reviewer Name