[1]Capers Jones Estimating Rules of Thumb Rule 1: SLOC function 80 valance one function point equal to
125 SLOC for C programs. The SLOC measure is intuitive And helps in developing a good understanding &
The size of a project SLOC is also used in several popular techniques for estimating sever
project parameters.Rule 2: Project duration estimation function points raised to the power 0.4 predicts
the approximate development time in calendar months. To illustrate the applicability of this tole.
consider that the size of a project is estimated to be 150 function points the development time would be
about eight months by rule 2 rules.Rule 3: Rate of requirements creep user requirements creep in at 10
every rate of 29, per month from the design through coding faces. The features required by the
customer keep on increasing due to a variety of reasons of course, requirement creeps are normally not
expected during project testing and installation stages. It is necessary to remember that the
requirement creeps occur from the end of the requirements phase till the testing phase. Therefore, only
an appropriate fraction of the project completion period needs to be considered to exclude the
durations of the requirements and testing facesRule 4: Defect removal efficiency each software review,
inspection, test will find and remove 30% of the bugs that are present. This rule briefly captures the
reason why software development organizations use a series of different removal steps viz
Requirements review, design review, old inspection and code walk-through, followed by unit,
integration and system testing. In fact, a series of about 10 consecutive defect removal operations must
be utilized to achieve good product Reliability.Rule 5: Project manpower estimation: The size of
thesoftware divided by 150 predicts the approximate number of the personnel required for developing
the application.Rule 6: Software development effort estimation: The approximate number of staff
months of effort required to develop a software is given by the software development time multiplied
by the number of personnel required.Rule 7: Function winds are divided by 500 critics the approximate
number of personnel required for regular maintenance activities. According to this rule 1500 function
points is equivalent to about 62,500 SLOC for C programs. Thus we can say that approximately for every
60,000 SLOC, one maintenance personnel would be required to carry out minor bug fixes and
thefunctionality adaptations during the operation phase of the
[2]COCOMO II: A Parametric Productivity Model
. COCOMO construct to cost estimation model was proposed by Boehm.
book
1. Acording to him, any is base on che nevel opriet can be chssifed into one of the following three
Calegories based on the development complexity: organic, semidetache
and embedded.
,. The classification is done considering the characteristics of the product as well as those of he
development team and development environment.Usually these three product classes go to spawn to
application, utility and system programmes respectively.1Data processing programs are normally
considered to be application programs. Compilers, linkers etc. Our utility programs.2 Operating system is
and real-time systems programmes our system programs.3The definition of organic, semidetached and
embedded systems are Elaborated below:(I)Organic: A development project can be considered of
organic type, if the project this with developing a wel understood application program, the size of the
development team is reasonably small, and the team members are experienced in developing similar
trpes of projects.(ii)Semidetached: A development project can be considered or semidetached type, is
the development consist of a mixture of experience and experience staff. Team members may have
limited experience on related systems but maybe unfamiliar with some aspects of the system being
developed.(iii)Embedded: Development project is considered to be embedded type, if the software
being developed is strongly coupled to complex hardware, or the stringent regulations on the
operational procedures exist.1. The different stages are:(a) Application composition: Here the external
features of the system that the users will experience are designed. Prototyping will typically be
employed to do this.
(5) Early design: Here the fundamental structure is a design:
(c) Post architecture: Here the software structures undergo final construction, modification and evening
to create a system that will perform as required.
The following model can then be used to calculate an estimate of person-months:
Pm = A (size)(sh x (em) x (em) × (ems).... Where pm = person months, A is 2.94, size is number of
thousands of lines of code, sf is the scale factor, and emiis an effort multiplier
The Scale factor is derived this:
sf = B + 0.01 × & scale factor values
i.e. sf = 0.91 + 0.01 × (1.24 + 5.07 + 2.83 + 2.19 + 6.24)
= 1.0857
If system contained 10 kloc then estimate would be 2.94 × 101.0857 = 35.8 person months
Using exponentiation ('to the power of*) adds disproportionately more to the estimates for larger
applications
Where B Is a constant currently set at 0.91. The effect of the exponent scale factor is to increase the
effort predicted for larger projects that is to take account of diseconomies of scale to make larger
projects less productive.
Cost Estimation Project cost can be opened by multiplying the effort estimated with the manpower cost
per month.1)In addition to manpower cost, a project would incur several other types of cost which are
referred to as no overhead cost.2)No overhead costs would include the cost of hardware and software
required for the project and the company overhead is for administration, office space, etc.3)Depending
on the expected values of the overhead of course, the project m suitably scale of the cost estimated by
using the COCOMO formula.
1]Boehm's top 10 Risks and Counter Measures
sochm has identified the top 10 risks that a typical project suffers from and has recommended a
ofcounter measure for each. We briefly review these in the following.
Personnel shortfall: This risk concerns shortfall of project personnel. The shortfall may show up as either
project personnel may lack some specific competence required for the project tasks or personnel leaving
the project (called manpower turnover) before proiect completion. The solution suggested include
staffing with top talent, job matching, team building, and cross-training of personnel.
Unrealistic schedules and budgets: The suggested solution include the project manager working out the
detailed milestones and making cost and schedule estimations based on it.
Other solution are incremental development, software reuse, and requirements scrubbing. It may be
mentioned that requirements scrubbing involves removing the overly complex and unimportant
requirements, in consultation with the customers.
Developing the wrong functions: The suggested solution include user surveys and user participation,
developing prototypes and eliciting user feedback, and early production user's manuals and getting user
feedback on it.
Developing the wrong user interface: The solution suggested for this risk include prototyping, scenarios,
and task analysis, and user participation.
Gold-plating: Gold-plating as is concerned with development of features that the team members
consider nice to have and, therefore, decide to develop those even though the customer has not
expressed any necessity for those. The solution suggested for this risk includes requirements scrubbing,
prototyping and cost-benefit analysis.
Continuing stream of requirements changes: The solution suggested for this risk include incremental
development, high change threshold and information hiding.
Shortfalls in externally-furnished components: This concerns the risk that the components developed by
third party are not up to the mark. The solution suggested for this risk include bench-marking,
inspections, and reference checking and compatibility analysis.
Shortfalls in externally performed tasks: This concerns the risk that the work performed by the
contractors may not be up to the mark. The solution suggested for this risk include reference checking,
pre-award audits, award-fee contracts, competitive design or prototyping and team building.
Real-time performance shortfalls: The solution suggested for this risk include simulation, benchmarking,
modeling, prototyping, instrumentation and tuning.
Straining computer science capabilities: The solution suggested for this risk include technical analysis,
cost-benefit analysis and prototyping.
[1]The Basis for Software Estimating
The need for Historical Data1. Most of the estimating methods need information about past projects.2.
But while applying past performance there is a possibility that differences in factors such as
programming languages and the experience of staff may take place.
Parameters to be Estimated
1. Two project parameters that is effort and Duration needs to estimate for carrying out Project
N Duration is usually measured in months and work-month (WM) is a popular unit for effor estimation.
The term person-month (PM) is also frequently used to mean the same as work. month. The person-
month estimate implicitly takes into account the productivity losses that's normally occur due to time
lost in holidays, the weekly-offs, coffee breaks etc
w Person-month is considered to be an appropriate unit for measuring effort compare to person-days or
person-years because developers are typically assigned to a project for a
certain number of months.
Measure of Work
Measure of work in walled in completing a project is also called the size of the project.Work itself can be
characterized by cost in accomplishing the project and the time over which it is to be completed.At early
stages of planning calculation of cost on time is difficult. Implementation time may also vary depending
on the extent to which Case (Computer aided software engineering)
Tools are used during development. It is therefore a standard practice to Is estimate the project size;
and were using it, the effort and time taken to develop the software can be computed.
The size of the project can be calculated using to metrics (1) Sources lines of code SLOC
(2) function Points. The SLOC measure suffers from various types of disadvantages, which are to Great
extent corrected in the FP measure.
[2] Categories of Risk
Proiect risks are those that could prevent the achievement of the objectives given to the
project manager and the project team.
Business risks. There could be risks that an application after successful implementation is a business
failure. For example if an e-commerce site is established to sell a product, the site might be correctly
implemented but customer fail to use the site because of the uncompetitive prices demanded. Dealing
with these business risks is likely to be outside the direct responsibilities of the application
implementation team. However, the failure to meet any project objectives could have a negative impact
on the business case for the project. For example, an increase in development cost might mean that the
income or savings generated by the delivered application no longer represents a good return on the
increased investment Risk can be categorized as sociotechnical model of risk
1]Applying the PERT Technique
Sat sumates for each activity empe
Asses to take into account the fact p
Using PERT to evaluate the effects of uncertainty
PERT (program evaluation and review technique) was developed to take account of the
Advantage of PERT
We have seen that by reque
Uncertainty surrounding estimates of lask durations. It was developed in an environment of expensive.
High-risk and state-of-the-art projects – not that dissimilar to many of today’s large software projects
Aspected dates, PERT focuses attem
The method is very similar to the CPM technique indeed many practitioners use the terms PERt
Stuate the standard deviation for
And CP interchangeably bu, instead of using a single estimate for the duration of each task, PERT
Fie use the expected times
Requires three estimates.
1. Most likely time: the time we would expect the task to take under normal circumstances,
Can, for any event or activity c
We shall identify this by the letter m.
Puticular, by setting target dates
2. Optimistic time: The shortest time, in which we could expect to complete the activity,
Greatest risk to the project’s sched
Barring outright miracles. We shall use the letter a for this.
3. Pessimistic fime: the worst possible time, allowing for all reasonable eventualities bu
713 Monte Carlo S
Excluding act of God and warfare (as they say in most insurance exclusion clauses). We
As an alternative to the pi
Shall call this b.
PERT then combines these three estimates to form a single expected duration, te, using the
Carlo simulation are a class of
Formula :- te =a+4m+b upon 6
8.9 Cost Schedules
The next important task is to produce a detailed cost schedule showing weekly or monthly costs over
the life of the project. This will provide a more detailed and accurate estimate of costs and will serve as
a plan against which project progress can be monitored.
Calculating cost is straightforward where the organization has standard cost figures for staff and other
resources. Where this is not the case, then the project manager will have to calculate the costs.
Following are the general aspect on which costs are categorized:
Staff costs: It include staff salaries as well as the other direct costs of employment such as the
employer’s contribution to social security funds, pension scheme contributions, holiday pay and sickness
benefit. These are commonly charged to projects at hourly rates based on weekly work records
completed by staff. The contract staff are usually charged by the week or month even when they are
idle.
Overheads: Overheads represent expenditure that an organization incurs, which cannot be directly
related to individual projects or jobs, including space rental, interest charges and the costs of service
departments (such as human resources). Overhead costs can be recovered by making a fixed charge on
development departments (in which case they usually appear as a weekly or monthly charge for a
project). Or by an additional percentage charge on direct staff employment costs. These additional
charges or on-costs can easily equal or exceed the direct employment costs.Usage charges: In some
organization, projects are charges directly for use of resources such as computer time (rather than their
cost being recovered as an overhead). This will normally be on an “as used” basis [2]Red/Amber/Green
(RAG) Reporting
One popular way of overcoming the objections to partial completion reporting is to avoid asking for
estimated completion dates, but to ask instead for the team members estimates of the likelihood of
meeting the planned target date.
One way of doing this is the traffic-light method. This consists of the following steps:
Identify the key (first level) elements for assessment in a piece of work
Break these key elements into constituent elements (second level)
Assess each of the second level elements on the scale green for on target’, amber for ‘not on target but
recoverable’, and red for ‘not on target and recoverable only with difficulty’;
4. Review all the second level assessments to arrive at first level assessments;
Review first and second level assessments to produce an overall assessment.
Traffic-light assessment highlights only risk of non-achievement; it is not an attempt to estimate work
done or to quantify expected delays. The project manager uses these as a basis for evaluating the overall
status of the project. Any critical activity classified as amber or red will require further consideration and
often leads to a revision of the project schedule. Non-critical activities are likely to be considered as a
problem if they are classified as red, especially if their entire float is likely to be consumed.
Earned Value-EVA
Famed Value Analysis is also known as Budgeted Cost of Work Performed. Earned Value Anioring
discussed in the previous section. Earned Value Analysis is based on assigning a value st nauthen has
gained in epilsions acton. Earned value Analysis is based on ascerent of al st gariant or work package las
identered cost for ise iced and it kneal as pend tate forecasts. He budgeted cost of work scheduled
(BCWS). A task that has not started is assigned the value zero and east net valle is the original buds ws
Cost task that has and started wass the baseline budget of when it has been completed, it, and hence
the project, is credited with the value of the task. The total value credited to a project at any point is
known as the earned value or budgeted cost of work performed (BCWP) and this can be represented as
a value or as a percentage of the BCWS.
Where tasks have been started but are not yet complete, some consistent method of assigning an
earned value must be applied. Common methods in software projects are:
The 0/100 technique: Where a task is assigned a value of zero until such time that it is completed when
it is given a value of 100% of the budgeted value;
The 50/50 technique: Where a task is assigned a value of 50% of its value as soon as it is started and
then given a value of 100% once it is complete;
The milestone technique: Where a task is given a value based on the achievement of milestones that
have been assigned values as part of the original budget plan.
The percentage complete: In some cases there may be a way of objectively measuring the amount of
work completed- for example as part of the implementation of an information system a number of data
records have to be manually typed into a database and the actual number so far completed can be
objectively counted.
Of these, we prefer the 0/100 technique. The 50/50 technique can give a false sense of security by over-
valuing the reporting of activity starts. The milestone technique might be appropriate for activities with
a long duration estimate but, in such cases, it is better to break that activity into a number of smaller
ones.
The Baseline Budget
The first stage in setting up an earned value analysis is to create the baseline budget. The baseline
budget is based on the project plan and shows the forecast growth in earned value through time.
Earned value may be measured in monetary values but, in the case of staff-intensive projects such as
software development, it is common to measure earned value in person-hours or workdays.
Monitoring Earned Value
Having created the baseline budget, the next task is to monitor earned value as the project progresses.
This is done by monitoring the completion of tasks (or activity starts and milestone achievements in the
case of the other crediting techniques).
Rapid Application Development
Rapid Application Development (RAD) also sometimes referred to as rapid prototyn
This model has the features of both the prototyping and the incremental delivery models
Aims are as follows:
To decrease the time taken and the cost incurred to develop software systems:
To limit the costs of accommodating change requests.
The RAD model tries to overcome this problem by inviting and incorporating custome teedback on
successively developed prototypes.
In the RAD model, development takes place in a series of short cycles called iterations.
Plans are made for one iteration at a time only
The time planned for each iteration is called a time-box.
The customer evaluates the prototype and gives feedback, based on which the prototype refined
The prototype is used as an instrument for gathering customer feedback only and is r released to the
customer for regular use
RAD also advocates the use of specialized tools for faster creation of working prototypes
4.14 Agile Methods
4.15 Agile methods are designed to overcome the disadvantages we have noted on the heavyweich
implementation methodologies.
One of the main advantages of traditional methodologies is the difficulty
Of eflicienti.
Accommodating change request from customers during exsiccation of the project.
There are various agile approaches:
1. Crystal technologies
Ater (DSDM)
Feature-driven development
Scrum
Extreme programming (XP)
In the agile model, the future requirements are decomposed into several small parts that ca be
incremental it developed.
It adopts an iterative approach.
Each incremental part is developed over and iteration.
Each iteration is intended to be small and easily manageable, and last for a couple of week only.
At the time only one increment is planned. Develop and then deploved at the customer site
No long-term plans are made.
The time taken to complete and iteration is called a time box
The development team can.
However decided to reduce the delivered Functionality during a
Time box.
Agile model emphasises face-to-face communication
Over written documents.
Team size is kept small that is 5-9 people to help the team members
Effectivelv
Communicate with each other and collaborate.
To a large project, it is likely that the collaborating teams might work at different locations And agile
Project usually includes a customer representative in the team
As the end of each iteration, the customer representative along with the stakeholders review the
progress made, re-evaluate the requirements and give suitable 4
Reechacktorathe
Development team.
Agile development projects usually deploy their programming. In this approach, to
Programmers work together at one work stati
One types the code while the other reviews the code as it is typed.
Several studies indicate that programmers working in pairs produce compact well-written programs and
there are fewer errors as compared to programmers working alone
Extreme Programming (XP)
This approach is so called because it takes common sense principles to extreme levels.
Four core values are presented as the foundations of xp.
Communication and feedback: it is argued that the best method of communication is face. to-face
communication and formal documentation is awaited.
Simplicity: the simplest design that implements the users requirements should also be adopted.
Responsibility: the developers are the ones who are ultimately responsible for the quality of the
software.
Courage: this is the courage to throw away work in which you have already invested a lot of effort, and
to start with a fresh design it that is what is called for it is also the courage to try out new ideas after all
everything won't work out.
Few more core practices of XP are as follows.
Planning Exercise
1. XP refer store components o the system as releases.
2. These releases code is developed in iterations, periods of 1 to 4 weeks duration during which specific
features of the software are created.
The planning game is the process Whereby the features to be incorporated in the next release are
negotiated.
Each of the features is documented in a short text description called a story that is Written
on ine care
[1]Project Portfolio Management
It provides an overview of all the projects that any organization is considering. As per the priority of the
project the allocation of resources is done.
Portfolio Management includes:
Identifying which project proposals are worth implementation
Analysis of risk
Prioritizing the share of resources and limiting its use.
Keeping track of project dependencies.
Avoiding redundancies.
Ensuring that necessary developments are not missed.
The three key aspects of project portfolio management are
Project Portfolio definition: An organization should store details of all the current projects and decision
should be made about whether projects of all types are to be included. Projects can be divided into two
types (a) new product development (ND) (b) renewal projects.
NPD is a new product to be delivered for example a game and renewal projects are which improve the
way an organization operates. 1Project Portfolio Management: Once the portfolio has been established,
detailed costings. Cab be recorded. Project performance can also be tracked.2 Project Portfolio
Optimization: Performance can be tracked by high level managers on regular basis and a better balance
may be achieved.3 Some projects may provide huge benefits while other may obtain modest benefits
but in both cases balance has to be achieved.
[2]Evaluation of Individual Projects
Individual projects can be evaluated by:
1. Technical Assessment: It consists of evaluating whether the required functionality can be achieved
with current affordable technologies. Same hardware/software infrastructure can limits the up
gradations. The cost involved in the technology adopted should also be considered.
2.
Cost-benefit analysis: It is always necessary to decide if the proposed project is the best irrespective of
the fact that benefits exceeds costs. This analysis comprises two steps:
Identifying all of the costs and benefits of carrying out the project and operating the delivered
application.
Expressing these costs and benefits in common units.
2. Cash flow forecasting: This indicates when expenditure and income will take place. Money has
to be spent in staff wages and many such resources during project development. Such
expenditure has to be done before receiving income. Prior calculations has to be done on
income and expenditure. But accurate calculations cannot be expected. Factors of inflation
should also be considered in the cost calculations.
[1]Identify and describe Project Products/activity (or deliverables)
1. There are no activities that do not produce a tangible product.
2.Some of the products will be handed over to the client at the end of the project-these are deliverables.
3. Other products will include a large number of technical products, such as training materials and
operating instruction.
4. Some products can be related to management and quality.
5.The products will be in the form of hierarchy.
6. The main products will have sets of component products which in turn may have sub-component
products and so on. These relationships can be modelled in Product Breakdown Structure (BPS). 8. A
third ‘group’ which has only one product is called management product and consists of project reports.
9.The asterisk in the progress reports indicates that there will be new instances of the entity, created
repeatedly throughout the project.10The products which are not further subdivided represents tangible
products.11.A product can even be a person such as ‘trained user’.12A common error is to identify as
products things that are really activities such as
‘training’, design’ and ‘testing’.
[2]Identify Project Scope and objectives
This includes set of activities required to identity the objectives and scope orthe proposed project
And whether it leads to project success.
Sup It: dentify objectives and practical measures of the effectiveness in meeting these
It is the need for agreed objectives for a project and the ways of measuring the success in achieving
those objectives.
For example:
For a project objectives can be:
Maintenance details to be recorded.
Analysis of cost to be carried out.
Recording of job requests and notification.
Step 1.2: Establish a project authority
Overall project authority needs to be established so that the purpose to similar to all.
Step 1.3: Stakeholder analysis: identify all stakeholders in the project and their interests
Everybody who is interested in the project need to be identified.
Step 1.4: Modify objectives in the light of stakeholder analysis
To gain full cooperation of everyone there might be a need of change in objectives. But this may be
dangerous because adding up new features may increase the system size. Hence to avoid such problems
this process should be handled in a controlled manner.
Step 1.5: Establish methods of communication with all parties
The project leader should find a point of contact to communicate with all the parties.
[3]identify Project Infrastructure
Profects are always. Carried out in existing infrastructure. If a project Manager is new to the
organization he should find a precise nature for this infrastructure.
Step 2.1: Identify relationship between the project and strategic planningApart from identifying projects
an organization needs to decide the order in which these projects should be carried out. It also needs to
establish a framework within which the proposed new systems are to fit. Technical strategic decisions
should be documented as part of the process.
Step 2.2: Identify installation standards and procedures
The one who develops software should also define its objectives.
Change control and configuration management standards should be in place to ensure that changes are
implemented successfully.
Quality check should be done and noted in quality standards and procedures manual.
Measurement programme should be maintained to record statistics collected.
Project manager should be aware of project planning and control standards.
[1]Programme Management
A programme is defined as “ group of projects that are managed in a coordinated way to gain benefits
that would not be possible were the projects to be managed independently”
Different forms of programmes are as follows:
1. Business cycle Programmes: Many organizations have fixed budget, decisions have to be made about
which projects to implement within that budget and within the accounting year.
2. Strategic Programmes: A single programme may have several projects and several projects can
implement a single strategy.
3. Infrastructure programmes: An organization can have various departments performing different
activities like accounts, HR etc. using different ICT functions. Accordingly infrastructure has to be
maintained with networks, servers, workstations etc.
4. Research and development Programmes: Some development products may be successful but not so
different than existing products whereas some products might be risky but final result may be
successful. Such type of programmes are also a form.
5. Innovative partnerships: companies sometimes come together to work tighter on new technologies,
separate projects in different organizations need to be coordinated and this might be done as a
programme.
