UNIVERSITY OF MAURITIUS

FACULTY OF ENGINEERING

SECOND SEMESTER EXAMINATIONS

MAY 2010

PROGRAMME MSc Software Engineering Projects and Management

MODULE NAME Software Project Management

DATE Saturday MODULE CODE CSE 6209

08 May 2010

TIME 09.30 – 12.40 Hrs DURATION 3 hours +

(including 10 mins (10 mins
reading time) reading time)

NO. OF 4 NO. OF QUESTIONS 4

QUESTIONS SET TO BE ATTEMPTED

INSTRUCTIONS TO CANDIDATES

Answer ALL questions.

 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Question 1 [30 marks]

Read the following case study and answer the questions that follow.

When it comes to developing software, accurate projections are 80% of the challenge.
In an effort to improve its internal budgeting and to further reduce surprises to
clients, TechnoPark Corp. went on a quest to find the most successful method of
estimating project cost and duration at the start of each project. In March 2007, a
modified COCOMO II model went into operation at TechnoPark Corp.

Pre-sales estimation of project costs and durations has been a software dilemma that
started with the profession itself. Despite all good intentions, Murphy’s Law seems
to leave everyone room to be unhappy about something. Customers expect accuracy
and often are disappointed even by what software companies consider minor post-
sales adjustments. IT project managers dread giving pre-sales estimates because they
know that just about every project has hidden work.

The burning question has been, “Is it possible to make an accurate estimation before
the project architecture is built?”

The dream answer of “YES” is all the more desirable for outsourcing software firms,
such as TechnoPark Corp., because accuracy is also related to trust and reputation,
the cornerstone qualities of any outsourcing company.

Since the 1970s, there have been many attempts to attain this dream of accurate pre-
sales estimations of projects. None however have stood up to the rigors of real world
challenges and client expectations.

Today, TechnoPark Corp. shares its successful experience in the fine art of pre-sales
estimation. First, let’s review the basis of the estimation process. There are some
common mistakes and some important issues ignored by many estimators.

A common initial mistake by software development companies is that they estimate

the project as if everything will go “just right.” However, it shall not. It is best to
estimate the reality of the process, and not some Pollyannaish scenario. Risks ought
to be the first things analyzed. Any estimation not based on analysis of all probable
risks, in conjunction with a company’s true capabilities, inevitably will result in an
estimation of one’s hopes and wishes and not probability.

According to the new model by TechnoPark Corp. a requirements-based model is

the most suitable for pre-sales estimation. The source lines of code (SLOC) model,
popular in the 1980s-90s, proves to not be effective any longer as coding is
significantly more complex and interactive than the number of lines of a program.
The SLOC model admittedly still helps with measuring the efforts of a completed
project, but that doesn’t help much with estimating before the coding begins.

Page 1 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Requirements-based estimation, on the other hand, accounts in advance for a

project’s features, risks and complexity. Analysis of the requirements provides an
estimator with a more abstract but accurate vision, as the estimator views the whole
project.

Requirements-based estimation however is not the solution either according to the

new model by TechnoPark Corp. Pre-sales estimation needs a general understanding
of the project but also needs to account for the details, an area where requirements-
based modelling comes up short.

Another golden rule of estimating reads: Estimate the diapason or range, not the
precise figure. It usually is impossible to count the precise size of efforts and get a
correct estimation at the pre-sales phase. It is better to estimate the spectrum of
possibilities and set aside more precise estimation for detailed examination of the
project.

In order to get the diapason, three figures for each task are needed: Worst Case (WC)
is the maximum amount of person-hours needed to implement the feature and
depicts the situation when everything is going wrong; Best Case (BC) is an optimistic
estimation providing minimum amount of person-hours; and Most Likely (ML)
depicts the situation which is the most probable in an estimators’ assessment, which
may be close to either the worst or best case.

“At TechnoPark Corp., we involve three developers each time estimation is

facilitated. Two of them provide their versions of WC, BC and ML estimations, and
the third one estimates complexity and function points. When counting the diapason
of person-hours, we use a number of additional coefficients such as maturity of
process, required software reliability, programming language experience, etc... After
all necessary data are entered, automated counting is implemented by the system
based on COCOMO II”, explains Victoria Malinovskaya, the estimation facilitator at
TechnoPark Corp.

COCOMO II, or the Constructive Cost Model, is growing in popularity as an

estimation model. Its first version, COCOMO 81, was introduced in 1981 by Barry
Boehm. The model is used for estimating the number of person-hours and person-
months it will take to develop a software product. The first version was based on
SLOC counting. COCOMO II appeared in the 1990s.

The power behind COCOMO II is that it is based on function points instead of

SLOC. A function point is a rough estimate of a unit of delivered functionality of a
software project. To calculate the number of function points for a software project,
one counts all of the user inputs, user outputs, user inquiries, number of files and
number of external interfaces, dividing them all into simple, average and complex
categories.

Page 2 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

COCOMO II coefficients and formulas are clear and useful for software
development companies, both big and small. The model offered by TechnoPark
Corp. is based on COCOMO II with only small fluctuations making it more suitable
for outsourcing software development companies.

TechnoPark Corp. has adapted the COCOMO II approach to client costing with
great success.

“With COCOMO II, we have helped the company reduce losses caused by
understated estimations by almost 70%,” Malinovskaya said.

Source: TechnoPark Corporation

a) Identify and explain the common mistakes/issues that are ignored by many
estimators. [5 marks]

b) Explain the estimation process that is adopted in TechnoPark Corporation.

[3 marks]

c) Outline the main differences between COCOMO 81 and COCOMO II.

[3 marks]

d) If you were the project manager at TechnoPark Corp., what are the factors
that you would consider for the accuracy of the software project estimation?
[4 marks]

e) “No attempts to attain accurate pre-sales estimations of projects were initially

reliable.”
Discuss five main difficulties that are usually encountered by software project
managers when they perform estimations. [5 marks]

f) “Any estimation not based on analysis of all probable risks, in conjunction with a
company’s true capabilities, inevitably will result in an estimation of one’s hopes and
wishes and not probability.”
Describe 5 typical risks that can occur in a software project, and for each,
identify two risk mitigation steps. [5 marks]

g) The trend nowadays in software estimation is to use views of experts to

validate estimates obtained through algorithmic models or other methods.
Briefly describe the main steps involved in the Wideband Delphi estimation
method. [5 marks]

Page 3 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Question 2 [25 marks]

Company ABC makes use of use cases for specifying the set of requirements for its
software project, TRS. The following tables define the weightings on Actors and Use
Cases to assess scope of the TRS project and provide an assessment of the
Environmental and Technology factors to assess risks for the TRS project.

Use Case No. Of Units Factor Actor Weight Number

Type Type of Actors
Simple 8 5 Simple 1 8
Medium 12 10 Average 2 12
Complex 4 15 Complex 3 4

Technical Description Weight Complexity

Factor Factor
TCF01 Distributed System 2 5
TCF02 Response or throughput performance 1 4
objectives
TCF03 End user efficiency (online) 1 2
TCF04 Complex internal processing 1 4
TCF05 Code must be re-usable 1 2
TCF06 Easy to install 0.5 5
TCF07 Easy to use 0.5 3
TCF08 Portable 2 3
TCF09 Easy to change 1 3
TCF010 Concurrent 1 2
TCF011 Include special security features 1 2
TCF012 Provide direct access for third parties 1 5
TCF013 Special user training facilities are required 1 3

Environmental Description Weight Complexity

Factor Factor
ECF01 Familiarity with UML 1.5 4
ECF02 Application Experience 0.5 2
ECF03 Object Oriented Experience 1 5
ECF04 Lead analyst capability 0.5 2
ECF05 Motivation 1 1
ECF06 Stable Requirements 2 5
ECF07 Part-time workers -1 0
ECF08 Difficult Programming language 2 1

Note: TCF = 0.6 + (0.01 * TFactor); ECF = 1.4 + (–0.03 * EFactor)

…/Cont’d next page

Page 4 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Question 2 (Cont’d)
a) Using the above information, calculate:
(i) The total unadjusted use case points (UUCP),
(ii) The technical complexity factor (TCF),
(iii) The environment complexity factor (ECF),
(iv) The final use case points (UCP),
(v) A rough effort estimate,
(vi) A refined effort estimate in terms of person-months, stating any
assumption(s) that you make.
[1+1+1+1+1+2 marks]
b) Critically analyse the Use Case Points approach as an estimation method by
determining the benefits and drawbacks of such an approach. [3 marks]

c) A very critical and real-time software is to be built to control the radioactive

emissions of a nuclear power plant. It is estimated that the size of the system
would be around 150,000 lines of code.

Development Mode Nominal effort Schedule

Organic (PM)NOM=3.2(KDSI)1.05 TDEV=2.5(PMDEV))0.38
Semidetached (PM)NOM=3.0(KDSI)1.12 TDEV=2.5(PMDEV))0.35
Embedded (PM)NOM=2.8(KDSI)1.20 TDEV=2.5(PMDEV))0.32

Activity Effort (%) Schedule (%)

Plans and requirements (+8) (+36)
Product design 18 36
Detailed design 25 18
Code and unit test 26 18
Integration and test 31 28

Based on the above project characterisation parameters and using an effort

adjustment factor (EAF) of 1.31, Calculate:
(i) The estimated effort for development
(ii) The estimated effort for plans & requirements
(iii) The estimated total effort for the project
(iv) The estimated time to complete each of the 5 basic phases of the
COCOMO life cycle
(v) The staff distribution across each of the 5 phases
(vi) The average recommended number of people for the whole
development process
(vii) The forecasted productivity of each development staff
[1+1+1+2.5+2.5+1+1 marks]
…/Cont’d next page

Page 5 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Question 2 (Cont’d)
d) The key to substantial improvement in business performance is a balanced
attack across the 5 basic parameters of the simplified software cost model:
complexity, process, team, tools and quality. Develop a set of strategies that
you, as a software project manager, would adopt to achieve this.
[5 marks]
Question 3 [20 marks]

One of the skills of a software project manager is the ability to design and implement
an overall risk management process for the organisation. An effective software risk
management process can be considered as one of the main steps towards ensuring
project success.

a) The Carnegie Mellon University's Software Engineering Institute developed a

software risk model based on the Shewhart-Deming cycle. The model
provides information and feedback, internal and external to the project, on the
risk activities, current risks, and emerging risks.
Using an appropriate illustration, describe the different steps in the SEI Risk
Management Model. [4 marks]

b) According to Zhi (1994), there are four main strategies for responding to
project risks. Using a concrete risk example, develop a risk management plan
showing how you would apply three main strategies to tackle the risk.
[6 marks]

c) As a software project manager, discuss five different risk identification

techniques that you would employ to identify risks in a software project.
[5 marks]
d) The software manager responsible for the development of the software
application, ABASS, notices that his project might fall behind schedule if time
is spent on regression testing. If the project is delivered late, there will be a
penalty of Rs 10 million.

There are three possible consequences, whether or not, regression testing is

performed: finding a critical fault if one exists, not finding the critical fault
(even though it exists), or deciding (correctly) that there is no critical fault.

With regression testing, the software project manager estimates that the
probability of finding a critical error is 0.75, of not finding a critical error is
0.05, and of finding no critical error is 0.2.

Without regression testing, the probability of finding a critical error is 0.25, of

not finding a critical error is 0.55, and of finding no critical error is 0.2.

…/Cont’d next page

Page 6 of 7
 SOFTWARE PROJECT MANAGEMENT – CSE 6209

Question 3 (Cont’d)

There is also a penalty of Rs 30 million if a critical error is found by the client.

The software project manager estimates that any bug(s) would approximately
cost Rs 5 million to fix.

Using a decision tree analysis, advise the software project manager whether
or not he should proceed with the regression testing. [5 marks]

Question 4 [25 marks]

The Rational Unified Process attempts to capture many of modern software

development's best practices in a form suitable for a wide range of projects and
organizations. This process recognizes that the conventional waterfall approach can
be inefficient and is usually one of the main causes of software failures.

a) Identify the key differences between the conventional waterfall model and the
Rational Unified Process. [3 marks]

b) Conventional software projects focused on the sequential development of

software artifacts. However, this approach does not work well for most of
today’s software systems. Instead, the focus of activities sweeps across
artifacts repeatedly.

Discuss the evolution of artifacts over the different phases of the Unified
Process, highlighting which artifact set(s) have greater depth in each of the
phases. [4 marks]

c) An iteration consists of a loosely sequential set of activities in various

proportions, depending where the iteration is located in the development
cycle. Identify and describe the activities that you would include in an
iteration workflow. [4 marks]

d) Some software managers still practice the conventional software management

approach. In most cases, today projects following such an approach are
destined for trouble and exhibit a number of symptoms.

Briefly describe the five symptoms of such projects and show how RUP
exploits the critical approaches to resolve each of these issues. [5 marks]

e) Formulate and appraise a set of software project management best practices

that you would adopt to ensure project success. [5 marks]

f) According to you, how would software economics evolve in the future to

improve the accuracy and precision of software cost estimates. [4 marks]

END OF QUESTION PAPER

/ph

Page 7 of 7