Project Estimations during proposal phase

Estimations during proposal phase.

Impact analysis is done, the application scope is determined to understand what all applications are within and out of scope depending on which upstream and downstream applications are identified. These have significant bearing on integration and end to end testing.

1. Correct estimations are pre requisite to successful project management
2. Accurate project estimates for a proposal ensure that -

• Project estimates are not too high, a proposal is not rejected.
• Effort and schedule estimates are not too low, thereby avoiding cost overruns and schedule delays in the proejct

When is estimation done:

• On receipt of a RFP from client
• Immediately on project initiation
• Beginning of each phase of the project (this varies for the type of project - Development, Maintenance, Conversion)
• Upon receiving CRs or Requests for Enhancements

Estimation @ RFP stage:

• Based on data given in the RFP
• Less data / knowledge available
• Low level details are not available
• May cover the following:-Estimate for each business function of the total requirements-Add overheads for quality assurance, project management-Estimate efforts for new technology, new tools, etc-Contingency

What to Estimate?

Estimate the Size, which then leads to estimation of schedule and effort.

In what units is Size estimated?

Size of work product is estimated in:

• KLOC
• FP
• Feature Points
• Number of Requirements
• Number of Components
• Estimation based on Use Cases for Object Oriented Projects

How is Effort derived from Size?

Productivity figures are taken into consideration. Also, COCOMO is used. Overheads for other activities are added (for example, User documentation, project management, quality assurance, user training, etc.). Note that in all these cases, complexity of the system to be designed and technology used must also be taken into account.

How is Schedule derived from Size?

T(in months) = y * 2 sqrt Effort in Person Years

• y is typically 2.5 to 3.0 for projects of effort <=180 person months
• y is typically 2. to 2.5 for projects of effort > 180 person months

While deriving Schedule take into account the leaves, trainings, and contingency.

What other things have to be estimated for?

• Team Size, Critical Computer Resources, Quality Assurance
• What factors affect estimations?
• Programmer experience
• Project documentation
• Standards
• Training Effort
• Contingencies
• Assumptions and Dependencies
• Management time
• Attrition, etc.

Other things to be factored in

• Knowledge and experience of the estimator (skill level of the estimator)
• Level of details available for estimates
• Time spent on understanding requirements and estimating
• Method used for estimation

Finally, what steps are involved in Estimation?

1. Identify the complexity level of each work item, obtain the figures for effort ratio for various phases and get the productivity figures for various phases
2. Use an appropriate estimation model, finalize the estimate for each phase of the project.
3. Document methods and calculations used for estimation, assumptions made, constraints taken into account, and loading plan
4. Consider experience of the team in the application area, exp of the team with the programming language, use of tools and s/w engg practices, and required schedule
5. Monitor these estimates continuously to track any change in the assumptions, constraints and loading plan

Elicit and Analyse Requirements

Understand and communicate requirements that align yout IT priorities with your business needs.

No process is more fundamental than the process of defining and managing business and technical requirements. It's no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.

The Requirements-engineering process consists of two major domains: definition and management.

Best practices:

Elicit Requiremements:

Define the vision and project scope.
Identify the appropriate stakeholders.
Select champions (Voice of the customer).
Choose elicitation techniques (workshops, questionnaires, surveys, individual interviews).
Explore user scenarios.

Analyse Requirements: verify they are complete and achievable

Create analysis models.
Build and evaluate prototypes.
Prioritize requirements.

Specify Requirements:

Look for ambiguities.
Store requirements in a database.
Trace requirements into design, code, and tests.

Validate Requirements:

Review the requirements through a formal peer review.
Create test cases from requirements.

Manage Requirements:

Manage versions.
Adopt a change control process.
Perform requirements change impact analysis.
Store requirements attributes.
Track the status of each requirement.
Applying requirements best practices lead to higher satisfaction for your customers.

Courtesy:http://software-quality.blogspot.com/Achieve Useful Requirements: Matt Klassens @ Processes.http://www.ftponline.com/special/alm/mklassen/default.aspx

Implementing Configuration Management for Software Testing Projects

To analyze test process performance, testers typically review and analyze the test process artifacts produced and used during a project cycle. However, these testing artifacts, along with their related use cases, evolve during a project cycle and can frequently have multiple versions by project end. Hence, analysis of the process performance from different perspectives requires that testers know exactly which versions of artifacts they used for different tasks. For example, to analyze why the test effort estimates were not sufficiently accurate, testers need the initial versions of use cases, test analysis, and test design specifications they used as a basis for the effort estimation. In contrast, a causal analysis of software defects missed in testing requires testers to have the latest versions of use cases, test analysis, and test design specifications used in test execution.

Read rest of the article here: http://www.stsc.hill.af.mil/crosstalk/2005/07/0507Boycan.html
Courtesy: STSC (Software Technology Support Center)

S/w program vs. industrial product

One advantage a software progam has over an industrial product is it can be reworked / reverted to a previous state if defects are found later, which is not the case with an industrial product; once a defect is injected, it stays and makes the product of no or lesser value.

Lehman's laws of software evolution

In 1980 Lehman and Belady came out with two laws explaining why software evolution could be the longest of the life cycle processes. These can be summarized as below:

1. Law of continuing change: To continue being useful, a system must undergo changes.
2. Law of increased complexity: The program structure detiorates as changes are introduced into it over time. Eventually, the complexity rises to an extent where it is cost effective to write a new program than to try to maintain it.