0% found this document useful (0 votes)
4 views

20AI0903 Software Project Management 1

Uploaded by

LOVE INDIA
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

20AI0903 Software Project Management 1

Uploaded by

LOVE INDIA
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 80

UNIT I PROJECT EVALUATION AND PROJECT PLANNING

Importance of Software Project Management – Activities Methodologies – Categorization of


Software Projects – Setting objectives – Management Principles – Management Control –
Project portfolio Management – Cost-benefit evaluation technology – Risk evaluation –
Strategic program Management – Stepwise Project Planning.
PART-A
1 What is a project?
The dictionary definitions put a clear emphasis on the project being a planned activity.
The other definitions include
 A Specific plan or design
 A planned undertaking
 A large undertaking
2 Define software project management.
Software project management is the art and science of planning and
leading software projects. It is a sub-discipline of project management in
which software projects are planned, implemented, monitored and controlled.
3 What are the characteristics of a project?
 Non-routine tasks are involved
 Planning is required
 Specific objectives are to be met
 The project has a predetermined time span
 Work is carried out for someone other than yourself
 Work involves several specialisms
 People are formed into temporary work group
 Work is carried out in several phases
 Resources available are constrained
 The project is large and complex.
4 What are the characteristics that make software projects different from other projects?

Invisibility - When a physical artifact is being constructed the progress being made can
actually be seen. With Software, progress is not immediately visible.
Complexity - software products contain more complexity than other engineered
artifacts.
Conformity - The ‘traditional’ engineer is usually working with physical. These physical
systems can have some complexity, but are governed by physical laws that are
consistent. Software developers have to conform to the requirements of human clients.
It is not just that individual can be inconsistent.
Flexibility - The ease with which software can be changed is usually seen as one of its
strengths.
5 What are the three successive processes that bring a new system? (Dec 11)
 The feasibility study- Evaluate the cost of the software development
against the Software Engineering
 Planning-Outline the structure of the project
 Project Execution- Product Implementation activities.
Page 1 of 126
6 What are the phases in software development life cycle?
 Requirement analysis
 Architecture design
 Detailed design
 Code and test
 Integration
 Qualification testing
 Installation
 Acceptance support
7 List the various ways to categorize software projects.
 Compulsory versus voluntary projects
 Information systems versus embedded systems
 Outsourced projects
 Object driven versus product driven development
8 Who are project stakeholders? (May 15)
These are people who have a stake or interest in the project. Stakeholders can be
categorized as:
 Internal to the project team
 External to the project team but within the same organization
 External to both the project and the organization.
9 What is project steering committee? What are their roles?
Overall authority over the project is often termed as project steering committee or project
management board. The project manager runs the project on a day-to-day basis, but
regularly reports to the steering committee.
Roles:
 Setting, monitoring and modifying objectives.
 The project manager runs the project on a day-to-day basis, but regularly reports to
the steering committee.
10 What are the activities of management?
 Planning –deciding what is to be done.
 Organizing – making arrangements.
 Staffing-selecting the right people for the job
 Directing-giving instructions.
 Monitoring – checking on progress
 Controlling- taking action to remedy hold-ups
 Innovating-coming up with new solutions.
 Representing – liaising with clients, users, developers, suppliers
11 Define SMART.
S – specific, that is, concrete and well-defined
M – measurable, that is, satisfaction of the objective can be objectively judged
A – achievable, that is, it is within the power of the individual or group concerned to
meet the target
R – relevant, the objective must relevant to the true purpose of the project
T – time constrained: there is defined point in time by which the objective should be
achieved

Page 2 of 126
12 What is Goals/sub-objectives?
A goal can be allocated to an individual. Individual may have the capability of achieving
goal, but not the objective on their own. A more appropriate goal or sub- objective for
the software developers would be to keep development costs within a certain budget.
e.g. Objective – user satisfaction with software product, Analyst goal – accurate
requirements and Developer goal – software that is reliable

13 Define Management control.


Management Control System is defined a ‘set of policies and procedures designed to
keep operations going according to plan.
14 What is project evaluation?
Project evaluation is a step by step process of collecting, recording and organizing
information about
 Project results
 short - term outputs (immediate results of activities or project deliverables)
 Long – term outputs (changes in behavior, practice or policy resulting from the
result.
15 Why is project evaluation important?
 What progress has been made?
 Were the desired outcomes achieved? Why?
 Whether the project can be refined to achieve better outcomes?
 Do the project results justify the project inputs?
16 What is Project portfolio Management?
Project Portfolio Management (PPM) is the centralized management of the processes,
methods, and technologies used by project managers and project management
offices(PMOs) to analyze and collectively manage current or proposed projects based
on numerous key characteristics.
17 What are the key aspects of Project portfolio Management?
 Portfolio definition
 Portfolio management
 Portfolio optimization
18 What is objective of a project?
Informally, the objective of a project can be defined by completing the statement: The
project will be regarded as a success “if……….” Rather like post-conditions for the
project, focus on what will be put in place, rather than how activities will be carried out.
e.g. ‘a new payroll application will be operational by 4th April’ not ‘design and code a
new payroll application’

19 What are the steps in cost-benefit analysis? (Dec 12, 13)


Cost –benefit analysis consists of two steps
 Identifying and estimating all of the costs and benefits of carrying out the project
and operating the delivered application. It includes development cost of system,
Operating cost of system, Benefits obtained by system.
 Expressing these costs and benefits in common units.
Page 3 of 126
20 What is net profit?
The net profit of a project is the differences between the total costs and the total income
over the life of the project. Advantage is easy to calculate and disadvantages are does
not show profit relative to size investment
21 What do you understand by payback period? (Dec 14)
The payback period is the time taken to break even or pay back the initial investment.
Normally, the project with the shortest payback period will be chosen on the basis that
an organization will wish to minimize the time that a project is ‘in debt’.
 Advantage: Simple to calculate, not sensitive to small forecasting errors.
 Disadvantage: Ignores the overall profitability of the project.
22 What is Return on investment? (May 12)
 It provides a way of comparing the net profitability to the investment required.
 A performance measure used to evaluate the efficiency of an investment or to
compare the efficiency of a number of different investments
Disadvantages
 It takes no account of the timing of the cash flows.
 Rate of returns bears no relationship to the interest rates offered or changed by
bank.
 ROI = average annual profit * 100
Total investment
 Average annual profit = net profit
Total no. of years
23 When Net present value is calculated for a project? (Dec 12)
The calculation of net present value is a project evaluation technique that takes into
account the profitability of a project and the timing of cash flows that are produced. The
NPV for a project is obtained by discounting each cash flow and summing the
discounted values.
24 What is the use of decision tree in Risk Evaluation? (May 13)
A decision tree is a diagramming analysis technique used to help select the best course
of action in situations in which future outcomes are uncertain
25 What is the concept of strategic programmes? (Dec 13)
Several projects together can implement a single strategy. For example, the merging of
two organizations’ computer systems could require several projects each dealing with
particular application area. Each activity could be treated as a distinct project, but
would be coordinated as a programme.
26 What are the steps involved in step wise planning?
 Identify project scope and objectives.
 Identify project infrastructure. Analyze project characteristics.
 Identify project products and activities.
 Estimate effort for each activity.
 Identify activity risks.
 Allocate resources.
 Review / publicize plan
 Execute plan/ lower levels of planning.
Page 4 of 126
27 Draw the diagram of overview of stepwise project planning.

PART-B
1) Explain the difference between software projects and other projects in detail.
1. Invisibility: When a physical artifact such as a bridge or road is being constructed
the progress being made can actually be seen. With software, progress is not
immediately visible. One way of perceiving software project management is as the
process of making visible that which is invisible.
2. Complexity: Per dollar, pound or euro spent, software products contain more
complexity than other engineered artifacts.
3. Conformity: The ‘traditional’ engineer is usually working with physical systemsand
physical materials like cement and steel. These physical systems can have some
complexity, but are governed by physical laws that are consistent. Software
developers have to conform to the requirements of human clients. It is not just that
individuals can be inconsistent. Organizations, because of lapses in collective
memory, in internal communication or in effective decision making can exhibit
remarkable ‘organizational stupidity’ that developers have to cater for.
4. Flexibility: The ease with which software can be changed is usually seen as one of
its strengths. However, this means that where the software system interfaces with a
physical or organizational system, it is expected that, where necessary, the software
will change to accommodate the other components rather than vice versa. This
means the software systems are likely to be subject to a high degree of change.

Page 5 of 126
2) Describe about activities covered by the software project management with
example. (Or) Explain the various software development life cycle activities as
outlined by ISO 12207 with a neat diagram.
a. The feasibility study:
This investigates whether a prospective project is worth starting – that it has a valid
business case. Information is gathered about the requirements of the proposed
application. Requirements elicitation can, at least initially, be complex and difficult. The
client and other stakeholders may be aware of the problems they wish to overcome and
the aims they wish to pursue, but not be sure about the means of achievement. The
probable developmental and operational costs, along with the value of the benefits of
the new system, will also have to be estimated. With a large system, the feasibility study
could be treated as a project in its own right – and have its own planning sub- phase.
The study could be part of a strategic planning exercise examining and prioritizing a
range of potential software developments. Sometimes an organization has a policy
where a group of projects is planned as a programme of development.

b. Planning:
If the feasibility study produces results which indicate that the prospective project
appears viable, then planning of the project can take place. However, for a large project,
we would not do all our detailed planning right at the beginning. We would formulate
an outline plan for the whole project and a detailed one for the first stage. More detailed
planning of the later stages would be done as they approached. This is because we
would have more detailed and accurate information upon which to base our plans
nearer to the start of the later stages.
Project Planning:
The biggest single problem that afflicts software developing is that of underestimating
resources required for a project. Developing a realistic project plan is essential to gain
an understanding of the resources required, and how these should be applied.
Types of plan:
√ Software development plan.
The central plan, which describes how the system will be developed.
√ Quality assurance plan.
Specifies the quality procedures & standards to be used.
Page 6 of 126
√ Validation plan.
Defines how a client will validate the system that has been developed.
√ Configuration management plan.
Defines how the system will be configured and installed.
√ Maintenance plan.
Defines how the system will be maintained.
√ Staff development plan.
Describes how the skills of the participants will be developed.
c. Project execution:
The project can now be executed. The execution of a project often contains design and
implementation sub-phases. Students new to project planning often find it difficult to
separate planning and design, and often the boundary between the two can be hazy.
Essentially, design is thinking and making decisions about the precise form of the
products that the project is to create. In the case of software, this could relate to the
external appearance of the software, that is, the user interface, or the internal
architecture. The plan lays down the activities that have to be carried out in order to
create these products. Planning and design can be confused because at the most
detailed level, planning decisions are influenced by design decisions. For example, if a
software product is to have five major components, then it is likely that there will be
five sets of activities that will create them.

Page 7 of 126
Requirements analysis: This starts with requirements elicitation which investigates
what the potential users and their managers and employers require as features and
qualities of the new system. These will relate to the system as a whole. A quality
requirement might be, for instance, that the user should be able to complete a
transaction within a certain time. In this case transaction time would be affected by the
speed of human operation, as well as hardware and software performance. These are
‘customer-facing’ requirements.
● Architecture design: This maps the requirements to the components of the system
that is to be built. At the system level, decisions will need to be made about which
processes in the new system will be carried out by the user and which can be
computerized. This design of the system architecture thus forms an input to the
development of the software requirements. A second architecture design process then
takes place which maps the software requirements to software components.
● Code and test: This could refer to writing code in a procedural language such as C#
or Java, or could refer to the use of an application-builder such as Microsoft Access.
Initial testing to debug individual software components would be carried out at this
stage.
● Integration: The individual components are collected together and tested to see if
they meet the overall requirements. Integration could be at the level of software where
different software components are combined, or at the level of the system as a whole where
the software and other components of the system such as the hardware platforms and
networks and the user procedures are brought together.
● Qualification testing: The system, including the software components, has to be
tested carefully to ensure that all the requirements have been fulfilled.
● Installation: This is the process of making the new system operational. It would
include activities like setting up standing data (such as payroll details for employees if
this were a payroll system). It would also include setting system parameters, installing
the software onto the hardware platforms and user training.
● Acceptance support: This is the resolving of problems with the newly installed
system, including the correction of any errors that might have crept into the system
and any extensions and improvements that are required. It is possible to see
software maintenance as a series of minor software projects. In many environments,
most software development is in fact maintenance.
3) What are the activities involved by management? List the problems with software
projects.

Page 8 of 126
It has been suggested that management involves the following activities:
● Planning – deciding what is to be done;
● Organizing – making arrangements;
● Staffing – selecting the right people for the job etc.;
● Directing – giving instructions;
● Monitoring – checking on progress;
● Controlling – taking action to remedy hold-ups;
● Innovating – coming up with new solutions
● Representing – liaising with clients, users, developer, suppliers and other
Stakeholders
1. Planning:
Planning refers to determination of future course of action to achieve desired goals. It
means deciding in advance what to do, how to do it, when to do it and who is to do it.
It is an “executive action that embodies the skills of anticipating, influencing and
controlling the nature and direction of change”. Planning precedes all other functions
of a manager.

A planning process involves the following steps:


(1) Being aware of opportunities or developments marks the beginning of planning
process. This involves assessment of strengths and weaknesses of the environment in
and outside the business organization.
(2) Determination of goals for the organization and the individual organizational units
in the light of new opportunities developments.
(3) Establishment of critical planning premises regarding the internal and external

Page 9 of 126
environments in which the plans will operate. This involves identification of strengths
and weaknesses of the business enterprise in terms of products, markets, processes,
technologies, personnel, etc.
(4) Identification of the alternative courses of action to achieve the objectives.
(5) Evaluation of the alternative courses of action in the light of their impact on
achievement of the objectives.
(6) Selection of the best alternative course of action.
(7) Formulation of the derivative plans for supporting the plan.
It may be noted that each of the above steps in the planning process requires a lot of
information regarding the internal and external environment in which the plans have
to operate. The information regarding the external environment includes economic
trends, technological changes, availability and cost of various resources, etc.
The information regarding the internal environment includes sales forecasts, financial
resources and plans, state of availability of resources in the company, etc. A manager
also needs various tools for analysis of the information regarding the environment.
2. Organizing:
Organizing involves analysis of activities to be performed to meet the requirements of plan,
grouping them so that they could be assigned to people or groups of people in organizational
units and delegation of authority to use organization’s resources to perform the
responsibilities so assigned. Organizing relates to the people, tasks and technology. Since
these factors differ from organization to organization, there is no typical organizational
design that would be suitable for all organizations. The organization structure has to be
designed according to the specific requirements and conditions of the organization. As the
people, tasks and technology are subject to dynamics of environment, the organizations
are restructured in the light of changing business environment. Organization structures and
information systems are closely related to each other. If the organization structure is the
body of the business enterprise, information system is its nervous system.
The organization structure should be designed keeping in view the natural flow of
information in the business enterprise. The performance measurement schemes must
match the flow of information and the organization structure.
Ideally, any change in information systems should cause corresponding change in the
organization structure; otherwise the information systems would not be able to reflect
the plans of the business. For example, the advancements in data base technologies and
use of distributed information systems are having their own impact on the way
organization structures are designed today.
3. Staffing:
Staffing is the process of manning the organization structure. A manager should ensure
that the right type of people fill up the positions in the organization structure. Staffing
involves selection, appraisal and development of personnel in the organization. The
common mistake that a manager commits is to ignore the staffing activity, leaving it to
personnel department. The staffing activity is too important to be routinised in the
personnel department. As the manager’s performance depends, to a great extent, on
the performance of his sub-ordinates, any neglect of staffing function could adversely

Page 10 of 126
affect the managerial effectiveness. With the increasing interdependence of various
functions, appraisal of staff is becoming more complex. There is a need to use more ad-
vanned techniques of performance appraisal. These techniques can be applied with the
help of IT infrastructure.
4. Directing:
Directing involves instructing, guiding and inspiring people in the organization to put
in their best to achieve the common goals of the organization. Thus, directing relates to
the process of motivating, leading and communicating with the people in the
organization in order to achieve the objectives of the company.
Dissemination of information plays a crucial role in directing the efforts of people in the
enterprise. In a business enterprise with operations spread over a wide geographical
area, the personnel have to be mobile and are likely to be located far away from other
members of the team and the immediate superior in the managerial hierarchy.
Directing the subordinates, thus, becomes difficult because the communication may be
quite expensive and may not reach the destination in time. Today, the information
systems are the vehicles of formal communication.
The facility of e-mail and use of the Intranet has transformed the way formal
communication takes place in business enterprises. Seamless flow of information across
various departments with the help of information systems can also help in reducing the
communication gaps that are many-a-time the main cause of employee dissatisfaction.
5. Controlling:
Controlling is a process that analyses whether the actions are being taken as per plans
and takes corrective action to make them to conform to plans. Thus, planning is the basis
of controlling. It focuses on activities that are being performed and the outcomes of these
activities in terms of their impact on the achievement of plan objectives. Increasing size of
the business enterprises has made all the more a difficult activity Increased competition in
the market requires greater delegation of work and decentralization of decision making in
order to ensure quicker response in the operations of the business enterprise. Thus,
controlling plays an important role in ensuring efficiency and effectiveness of the
enterprise. The information systems play an important role in the control process. These
systems not only help in measuring the performance of operations but also help in
identifying deviations of performance from plans.
The comparison between planned and actual performance is then analyzed with the
help of information systems to identify reasons for deviations. The environmental
information is used to identify such reasons. Information regarding what actions are
being taken or what is happening in the internal and external environments of business
is essential for exercising control. Earlier, most of such information used to come by
way of personal observation by the manager. Increasing size of the business enterprise
has made personal observation a very difficult form of control. There is greater reliance
on written reports. With the business becoming more knowledge intensive activity and
composition of personnel of the enterprise getting dominated by knowledge workers,
the measurement of performance is becoming more complex. Simple tabular reports
with regard to achievement of quantified goals are not adequate for controlling.

Page 11 of 126
Controlling function uses information regarding the planned performance and actual
performance to arrive at deviations. Efficient information systems not only identify
these deviations but also help in analyzing the deviations to pinpoint reasons for
deviation. They also help in modifying the plans quickly in the light of the feedback. The
concept of flexible budgeting has become popular due to availability of better
information processing facilities. With the availability of real time information systems,
the information regarding performance flows quickly. This helps in exercising control
quickly, resulting in lower cost of planning mistakes.
Problem with software projects are:
 Poor estimates and plans.
 Lack of quality standards and measures.
 Lack of guidance about making organizational decisions.
 Lack of techniques to make progress visible.
 Incorrect success criteria.
Problems occur from time to time and fixing them in a timely fashion is essential to
achieve correctness of a system and avoid delayed deliveries of products. The above list
looks at the project from the manager’s point of view. What about the staff who make
up the members of the project team? Below is a list of the problems identified by a
number of Computing and Information Systems degree students who had just
completed a year’s industrial placement.
4) Discuss about management control in detail.
Management, in general, can be seen as the process of setting objectives for a system
and then monitoring the system to see what its true performance is. In the ‘real world’
is shown as being rather formless. Especially in the case of large undertakings, there
will be a lot going on about which management should be aware. This will involve the
local managers in data collection. Bare details, such as ‘location X has processed
2000 documents’, will not be very useful to higher management: data processing will be

Page 12 of 126
needed to transform this raw data into useful information. This might be in such forms
as ‘percentage of records processed’, ‘average documents processed per day per
person’ and ‘estimated completion date’. In our example, the project management
might examine the estimated completion date’ for completing data transfer for each
branch. These can be checked against the overall target date for completion of this
phase of the project.
In effect they are comparing actual performance with one aspect of the overall
project objectives. They might find that one or two branches will fail to complete the
transfer of details in time. They would then need to consider what to do the project
manager would need to calculate carefully what the impact would be in moving staff
from particular branches. This is modeling the consequences of a potential solution.
Several different proposals could be modeled in this way before one was chosen for
implementation.

Fig 1.2: Project Control Cycle


The Project Control Cycle:
Management, in general, can be seen as the process of setting objectives for a
system and then monitoring the system to see what its true performance is. In Figure
1.2 the 'real world' is shown as being rather formless. Especially in the case of large
undertakings, there will be a lot going on about which management should be aware.

Page 13 of 126
As an example, take an IT project that is to replace locally held paper-based records
with a centrally-organized database. It might be that staff in a large number of offices
that are geographically dispersed need training and then need to use the new IT system
to set up the back-log of manual records on the new database. It might be that the
system cannot be properly operational until the last record has been transferred. It
might also be the case that the new system will be successful only if new transactions
can be processed within certain time cycles. The managers of the project ought to be
asking questions about such things as how effective training has been, how many
records have still to be transferred to the new database and transfer rates. This will
involve the local managers in data collection. Bare details, such as 'location X has
processed 2000 documents' will not be very useful to higher management: data
processing will be needed to transform this raw data into useful information. This might
be in such forms as 'percentage of records processed', 'average documentsprocessed
per day per person' and 'estimated completion date'.
In the example above, the project leader might examine the 'estimated completion date'
for completing data transfer for each branch and compare this with the overall target
date for completion of this phase of the project. In effect they are comparing actual
performance with one aspect of the overall project objectives. They might find that one
or two branches are not going to complete the transfer of details in time, and would
then need to consider what to do (this is represented in Figure 1.2 by the box making
decisions/plans). One possibility would be to move staff temporarily from one branch
to another. If this is done, there is always the danger that while the completion date for
the one branch is pulled back to before the overall target date, the date for the branch
from which staff are being moved is pushed forward beyond that date. The project
manager would need to calculate carefully what the impact would be in moving staff
from particular branches. This is modelling the consequences of a potential solution.
Several different proposals could be modelled in this way before one was chosen for
implementation. Having implemented the decision, the situation needs to be kept under
review by collecting and processing further progress details. For instance, the next time
that progress is reported, a branch to which staff has been transferred might still be
behind in transferring details. This might be because the reason why the branch has got
behind in transferring details is because the manual records are incomplete andanother
department, for whom the project has a low priority, has to be involved in providing the
missing information. In this case, transferring extra staff to do data input
will not have accelerated data transfer.
5) Explain in detail about setting objectives.
• Answering the question ‘What do we have to do to have a success?’
• Need for a project authority
 Sets the project scope
 Allocates/approves costs
• Could be one person - or a group
 Project Board
 Project Management Board
 Steering committee
Page 14 of 126
Objectives:
Informally, the objective of a project can be defined by completing the statement:
The project will be regarded as a success “if ............................................... ”
Rather like post-conditions for the project
Focus on what will be put in place, rather than how activities will be carried out
Objectives should be SMART:
An objective is a statement which describes what an individual, team or organization is
hoping to achieve. Objectives are 'SMART' if they are specific, measurable, achievable,
realistic and, timely (or time-bound).
S – specific, that is, concrete and well-defined
M – measurable, that is, satisfaction of the objective can be objectively judged
A – achievable, that is, it is within the power of the individual or group concerned to
meet the target
R – relevant, the objective must relevant to the true purpose of the project
T – time constrained, there is defined point in time by which the objective should be
achieved
1. Specific:
There are a number of different ways in which SMART objectives can be set, one method
is to start by identifying what you want the individual to do or achieve thatreflects both the
departmental or team objectives.
For example: You may be a Senior Lecturer and your department is looking at ways to
improve the student experience as one of its objectives or priorities (this may be linked
to results from the student satisfaction survey or feedback from other sources). You are
responsible for reviewing two lecturers and it would therefore be appropriate to look
at their role in this departmental priority. What does the Department need them to achieve?
Is it an increase in student satisfaction in a certain area (e.g. learning resources)? Is it
reducing the number of students who don’t progress on to the second year of studies? Etc.
You may be a manager in a Professional Services department and your department is also
looking at ways to improve the student experience as one of its objectives or priorities.
What does the department need the staff you manage to achieve? Is it theintroduction of
new processes/procedures in order to improve the service given to either students
directly or academic departments? Is it maintaining a certain (high) level of service to
students/staff over a period of time?
When setting SMART objectives wherever you are within the organisation and
whatever your role, as a reviewer you will need to have as much clarity as possible
about what you want or need your reviewee to achieve.
2.Measurable:
Having identified what needs to be achieved and having written this as a statement (in
the box above) you then apply the SMART criteria to it.
For example: Specific: For the lecturer: Increase student satisfaction levels in the learning
resources provided by the department. What kind of increase are you looking for – a
small % increase or a large one? What learning resources are you referring to?
For the administrator: Reduce the amount of time it takes to respond to academic

Page 15 of 126
departmental requests for information. What reduction are you aiming for? What do
you mean by respond to? Do you really mean all academic departmental requests for
information or a particular area? Measurable
For both examples – what measures are you going to use? Clarification is needed for both.
How will you know when the objective has been achieved? So for the lecturer the objective
may now look something like the example below: Increase student satisfaction levels in
the 201X student satisfaction survey by 25% in the learning resources provided for x
course. For the administrator the objective may have changed slightly to look as follows:
Ensure all academic departmental requests for information on x are dealt with within 3
working days by October 201X.
3. Achievable:
This is where you need to consider the context, abilities etc of the individual that you
are expecting to do this work. Is it something that they would be able to do? It may be
that the individual would need support in the form of resources, training/ development
etc in order to achieve the objective set (you would note these down in sections C & D
of the SRDS form). It might be that the time frame that you place on the objective (which
is currently missing from one of the examples) makes it less achievable so check this as
well.
4. Relevant:
Double check that the statement you are now crafting reflects both what is needed by the
department and fits in with the expectations of the individual as described in their job
summary/ job description.
5. Time Constrained:
A deadline, date or time when the objective will be accomplished or completed is
necessary and must be included so as to make the objective measurable. A deadline
helps to create the necessary urgency, prompts action and focuses the minds of those
who are accountable for the commitments that they have made through the objectives.
Not setting a deadline reduces the motivation and the urgency of those required to
perform the tasks. Ask yourself if the objective can be accomplished within the
deadlines which have been established, bearing in mind other possible competing
demands which may cause delay.
Goals/sub-objectives:
These are steps along the way to achieving the objective. Informally, these can be
defined by completing the sentence…
Objective X will be achieved
IF the following goals are all achieved
A……………
B……………
C… ............... etc.
Often a goal can be allocated to an individual. Individual may have the capability of
achieving goal, but not the objective on their own e.g.
 Objective – user satisfaction with software product
 Analyst goal – accurate requirements
 Developer goal – software that is reliable

Page 16 of 126
Measures of effectiveness:
How do we know that the goal or objective has been achieved?
By a practical test, that can be objectively assessed.
e.g. for user satisfaction with software product:
 Repeat business – they buy further products from us
 Number of complaints – if low etc.
6) Explain in detail about Project Portfolio Management.
 Strategic and operational assessment carried by an organization on behalf of
customer is called portfolio management [third party developers]
 They make use of assessment of any proposed project themselves.
 They ensure for consistency with the proposed strategic plan.
 They proposed project will form part of a portfolio of ongoing and planned projects
 Selection of projects must take account of possible effects on other projects in the
portfolio (example: competition of resource) and the overall portfolio profile
(example: specialization versus diversification).
When there are many projects run by an organization, it is vital for the organization to
manage their project portfolio. This helps the organization to categorize the projects
and align the projects with their organizational goals.
Project Portfolio Management (PPM) is a management process with the help of methods
aimed at helping the organization to acquire information and sort out projects according
to a set of criteria.
Objectives of Project Portfolio Management:
Same as with financial portfolio management, the project portfolio management also has
its own set of objectives. These objectives are designed to bring about expected results
through coherent team players.
When it comes to the objectives, the following factors need to be outlined.
 The need to create a descriptive document, which contains vital information such
as name of project, estimated timeframe, cost and business objectives. 
 The project needs to be evaluated on a regular basis to ensure that the project is
meeting its target and stays in its course.
 Selection of the team players, who will work towards achieving the project's
objectives.
Benefits of Project Portfolio Management:
Project portfolio management ensures that projects have a set of objectives, which when
followed brings about the expected results. Furthermore, PPM can be used to bring out
changes to the organization which will create a flexible structure within the organization
in terms of project execution. In this manner, the change will not be a threat for the
organization.
The following benefits can be gained through efficient project portfolio management:
 Greater adaptability towards change.
 Constant review and close monitoring bring about a higher return.
 Management's perspectives with regards to project portfolio management is seen
as an 'initiative towards higher return'. Therefore, this will not be considered to be
a detrimental factor to work.

Page 17 of 126
 Identification of dependencies is easier to identify. This will eliminate some
inefficiency from occurring.
 Advantage over other competitors (competitive advantage).
 Helps to concentrate on the strategies, which will help to achieve the targets rather
than focusing on the project itself.
 The responsibilities of IT are focused on part of the business rather than scattering
across several.
 The mix of both IT and business projects are seen as contributors to achieving the
organizational objectives.
Project Portfolio Management Tools:
There are many tools that can be used for project portfolio management. Following are
the essential features of those tools:
 A systematic method of evaluation of projects.
 Resources need to be planned.
 Costs and the benefits need to be kept on track.
 Undertaking cost benefit analysis.
 Progress reports from time to time.
 Access to information as and when its required.
 Communication mechanism, which will take through the information necessary. 
Techniques Used to Measure PPM:
There are various techniques, which are used to measure or support PPM process from
time to time. However, there are three types of techniques, which are widely used
 Heuristic model. 
 Scoring technique. 
 Visual or Mapping techniques. 
The use of such techniques should be done in consideration of the project and
organizational objectives, resource skills and the infrastructure for project
management.
Why Project Managers to Focus on PPM?
PPM is crucial for a project to be successful as well as to identify any back lags if it were
to occur. Project Managers often face a difficult situation arising from lack of planning
and sometimes this may lead to a project withdrawal. It's the primary responsibility of
project managers to ensure that there are enough available resourcesfor the projects
that an organization undertakes. Proper resources will ensure that the project is
completed within the set timeline and delivered without a compromise on quality.
Project managers also may wish to work on projects, which are given its utmost
priority and value to an organization. This will enable project managers to deliver and
receive support for quality projects that they have undertaken. PPM ensures that these
objectives of the project management will be met.
The Five Question Model:
The five-question model of project portfolio management illustrates that the project
manager is required to answer five essential questions before the inception as well as

Page 18 of 126
during the project execution. The answers to these questions will determine the success
of the implementation of the project. Therefore, all the project managers of the organization
need to have an awareness of the organizational project portfolio management in order to
contribute to the organizational goals when executing respective projects.

7) Explain in detail about cost-benefit evaluation techniques and its methods with
examples.
Various cost-benefits Evaluation Techniques are
√ Net profit
√ Payback period
√ Return on investment
√ Net present value
√ Internal rate of return
1. Net profit:
 Difference between total cost and total income
 Pros: Easy to calculate
Cons
 Does not show profit relative to size investment (e.g., consider Project 2)
 Does not consider timing of payments (e.g., Projects 1 and 3)
 Not very useful other than for "back of envelope" evaluations

Four project cash flow projections


Year Project1 Project2 Project3 Project4
0 -100,000 -1,000,000 -100,000 -120,000
1 10,000 200,000 30,000 30,000
2 10,000 200,000 30,000 30,000
3 10,000 200,000 30,000 30,000
4 20,000 200,000 30,000 30,000
5 100,000 300,000 50,000 75,000
Net 50,000 100,000 50,000 75,000
profit
2. Payback period:
 The payback period is the time taken to recover the initial investment or is the length
of time required for cumulative incoming returns to equal the cumulative costs of an
investment
Advantages
 Simple and easy to calculate.
 It is also a seriously flawed method of evaluating investments
Disadvantages
 It attaches no value to cash flows after the end of the payback period.
 It makes no adjustments for risk.
Page 19 of 126
 It is not directly related to wealth maximization as NPV is.
 It ignores the time value of money.
 The "cut off" period is arbitrary.
Project 1 = 10,000+10,000+10,000+20,000+1,00,000=1,50,000
Project 2 = 2,00,000+2,00,000+2,00,000+2,00,000+3,00,000=11,000,00
Project 3 = 30,000+30,000+30,000+30,000 + 75,000 =1,95,000
3. Return on investment:
 It provides a way of comparing the net profitability to the investment required
 A performance measure used to evaluate the efficiency of an investment or to
compare the efficiency of a number of different investments
Disadvantages
 It takes no account of the timing of the cash flows.
 Rate of returns bears no relationship to the interest rates offered or changed by
bank.
ROI = average annual profit * 100
total investment
average annual profit = net profit
total no. of years
Calculate ROI for project 1.
Ans: Total investment =1,00,000
Net profit = 50,000
Total no. of year = 5
Average annual profit=50,000/5=10,000rs
ROI= (10,000/1,00,000) *100 = 10%
4. Net present value:
 A project evaluation technique that takes into account the profitability of a
project and the timing of the cash flows that are produced.
 Sum of all incoming and outgoing payments, discounted using an interest rate,
to a fixed point in time (the present)
 Present value = (value in year t)/(1+r)^t
Pros:
 Takes into account profitability
 Considers timing of payments Considers economic situation through discount
rate
Cons: Discount rate can be difficult choose
5. Internal rate of return (IRR):
 Internal rate of return (IRR) is the discount rate that would produce an NPV of 0
for the project. It can be used to compare different investment opportunities
 Pros: Calculates figure which is easily to interest rates
Cons: Difficult to calculate (iterative)
8 Explain risk evaluation.
Risk evaluation is meant to decide whether to proceed with the project or not, and
whether the project is meeting its objectives.
Risk Occurs:
 When the project exceeds its original specification
 Deviations from achieving it objectives and so on.
Every project involves risk. The project risks which prevent the project being
completed successfully and the business risk that the delivered products are nor
profitable.
Page 20 of 126
Risk evaluation consists of:
 Risk identification and ranking
 Risk and NPV
 Cost benefit analysis
 Risk profile analysis
Risk identification and ranking:
 Identify the risk and give priority.
 Could draw up draw a project risk matrix for each project to assess risks
 Project risk matrix used to identify and rank the risk of the project
Example of a project risk matrix

Risk and net present value:


 Where a project is relatively risky it is common practice to use a higher discount rate
to calculate the NPV. The risk premium be an additional 2 % for an safe projector 5
% for a fairly risky project
 Projects may be categorized as high, medium or low risk using a scoring method and
risk premiums designated for each category.
Cost-benefit analysis:
 A rather more sophisticated approach to the evaluation of risk is to consider each
possible outcome, probability of its occurring and the corresponding value of the
outcome.
 Rather than a single cash flow forecast for a project, we will then have a set of cash
flow forecasts, each with an associated probability of occurring.
 The value of the project is then obtained by summing of the cost or benefit for each
possible outcome weighted by its corresponding probability.
 Drawback: Does not take full account of worst-case scenarios. (averaging out the
negative and positive outcomes of the scenarios)
Risk profile analysis:
 An approach which attempts to overcome some of the objections to cost benefit
averaging is the construction of risk profiles using sensitivity analysis.
 This makes use of “risk profiles” using sensitivity analysis.
 It compares the sensitivity of each factor of project profiles by varying

Page 21 of 126
parameters which affect the project cost benefits.
 E.g: Vary the original estimates of risk plus or minus 5% and re-calculate the
expected cost benefits.
 P1 depart far from p2, have large variation
 P3 have much profitable than expected
 All three projects have the same expected profit
 Compare to p2, p1 is less risky.

9) Explain decision trees with examples.


Decision tree:
Decision tree provide tools for evaluating expected outcomes and choosing between
alternate strategies. A decision tree is a decision support tool that uses a tree- like graph or
model of decisions and their possible consequences, including chance event outcomes,
resource costs, and utility. It is one way to display an algorithm.

Decision trees method for risk evaluation: -

Page 22 of 126
1. Amanda is responsible for extending the invoicing system.
2. An alternative would be to replace the whole of the system.
3. The decision is influenced by the likelihood of org expanding their market.
4. There is a strong rumor that they could benefit from their main competitor going
out of business: in this case they could pick up a huge amount of new business, but
the invoicing system could not cope.
5. However, replacing the system immediately would mean other important projects
would have to be delayed.
6. The NPV of extending the invoicing system is assessed as £75,000 if there is no
sudden expansion.
7. If there were a sudden expansion then there would be a loss of £100,000.
8. If the whole system were replaced and there was a large expansion there would be
a NPV of £250,000 due to the benefits of being able to handle increased sales.
9. If sales did not increase then the NPV would be -£50,000.
10. The decision tree shows these possible outcomes and also shows the estimated
probability of each outcome.
11. The value of each outcome is the NPV multiplied by the probability of its occurring.
12. The value of a path that springs from a particular decision is the sum of the values
of the possible outcomes from that decision. If it is decided to extend the system the sum
of the values of the outcomes is £40,000 (75,000 x 0.8 – 100,000 x 0.2) while for
replacement it would be £10,000 (250,000 x 0.2 – 50,000 x 0.80).
13. Extending the system therefore seems to be best option.
10) Explain in detail about strategic program management.
Strategic Programmes:
Strategic planning is an organization's process of defining its strategy, or
direction, and making decisions on allocating its resources to pursue this strategy. In
order to determine the direction of the organization, it is necessary to understand its
current position and the possible avenues through which it can pursue a particular
course of action. Strategic programming makes sense when the world is expected to
hold still or change predictably while the intended strategies unfold, so that formulation
can logically precede implementation.
Strategic Project Management:
Strategic Project Management (SPM) (also called Enterprise Project Management by
some) has been defined by Callahan & Brooks (2004) as “the use of the appropriate
project management knowledge, skills, tools and techniques in the context of the
company’s goals and objectives so that the project deliverables will contribute to
company value in a way that can be measured”. Strategic Project Management is really
nothing more than picking the right projects for the organization to ensure optimal
returns. This sounds very simple and straightforward, but research shows that there
are many organizations that have overlooked the important fact of aligning projects
with corporate strategy. Strategy is a pattern in a stream of explicit and implicit strategic
projects designed to create a specific competitive positioning.
The Process of Strategic Project Management:
Now that we know that the goal of strategic project management is to take a project
from start to finish in ways that are competitive and efficient, let's look at the process.
The following are strategies a project manager, such as Kara, can use to push an

Page 23 of 126
ordinary project to an extraordinary project.
1. Know the direction of the project: Before starting the project, Kara fully outlines the
project objectives and identifies how the project will help the company's efficiency and
competitiveness as a whole. She determines who has the most at stake in this project, plans
a completion timeline, and develops a reliable budget.
Once Kara has completed these steps, she lets management know what the project will
accomplish, in this case, creation of a new Christmas doughnut. She makes sure
everyone understands why the project is important to the company, namely, to boost
holiday sales and test new efficiency techniques. Then she lays out the expected
timeline and budget to complete the project successfully.
2. Explain responsibilities: For her next step, Kara creates an ideal project team by
gathering employees with qualities that are essential for the project. In this case, such
qualities include visual creativity and efficiency, so that the product stays on track, is
completed in time for the holidays, and gives the company an edge over its competitors.
She consults with her boss to better understand the qualities certain employees offer and
how those qualities align with the overall goal of the project. She then meets with the
selected employees to explain the project and responsibilities and to make assignments
based on interests and strengths.

Creating a project team specifically based on strengths and interests is an approach


Kara hopes will make this project a superstar and be a work assignment technique the
company can use after the holiday season.

3. Project planning: During this stage, Kara outlines the steps and tasks of the project. This
means she aligns each step with the timeline so that everyone on the team is awareof
when each step needs to be completed. As she outlines the steps and tasks, Kara also focuses
on what each employee does best so that an outstanding project is completed and the
company's efficiency, quality, and competitiveness improve.

This is also the time when Kara decides how much money will be spent on each task or
responsibility. The less money spent, the more profit there is, thus helping the company
stay competitive with other businesses in the industry. So when Kara assigns the tasks
to her team, she lets each person know when she expects the tasks to be completed.

Page 24 of 126
The Relevance of Strategic Thinking to Project Management:
Strategic thinking is typically associated with 'very big picture' thinking, or 'helicopter
thinking' It is relevant to project management at a number of levels.
1. Business projects often materialize as a result of formal or informal strategy
development. Besides projects which are of a corporate development and
external nature, there are frequently internal projects which are aimed at
reaping major organizational change.
2. Individual business projects which have materialized on a 'bottom-up' basis.
Each project of that kind then needs to be linked back up to the businessstrategy.
This should be accomplished by teasing out the strategic objectives of each and
every major project.
3. Within the project itself: each and every project has both an internal
environment and also some strategy for achieving its own, inherent advantage.
11) Explain the step-wise project planning in detail with suitable flowchart.
(Dec 11,12,14, May 12,13,14,15)

Page 25 of 126
Step 1: Identify project scope and objectives.
Project objectives, Project authorities, and Modified project objectives.
Step 2: Identify project Infra structure.
Role of existing strategic plans, identifying standards, project organization.
Step 3: Analyze project characteristics, High-level risks.
Step 4: Identify project products and activities, Product break down structure, IOE has
standard PFD, Identifying product instances, Activity network for IOE Maintenance
Accounts.
Step 5: Estimate effort for each activity, IOE Maintenance Group Accounts- breaking
activities down into manageable tasks.
Step 6: Identify activity risks.
Identifying risks for Amanda
Step 7: Allocate Resources.
Taking resource constraints into account,
Step 8: Review/Publicize plan
IOE existing quality standards
Step 9 &10: Execute plan and lower levels of planning, lower level planning for
individual modules.
Page 26 of 126
UNIT II PROJECT LIFE CYCLE AND EFFORT ESTIMATION
Software process and Process Models – Choice of Process models - mental delivery – Rapid
Application development – Agile methods – Extreme Programming – SCRUM – Managing
interactive processes – Basics of Software estimation – Effort and Cost estimation techniques
– COSMIC Full function points - COCOMO II A Parametric Productivity Model - Staffing
Pattern.
PART-A
1 What is a software process model?
A Process Model describes the sequence of phases for the entire lifetime of a product.
Therefore, it is sometimes also called Product Life Cycle. This covers everything from
the initial commercial idea until the final de-installation or disassembling of the
product after its use.
2 What were the phases in software process model?
There are three main phases:
 Concept phase
 Implementation phase
 Maintenance phase
Each of these main phases usually has some sub-phases, like a requirement engineering
phase, a design phase, a build phase and a testing phase. The sub-phases may occur in
more than one main phase each of them with a specific peculiarity
depending on the main phase.
3 List various software process models.
Waterfall model, Spiral model, V-model, Iterative model, Agile model and RAD model.
4 Define RAD.
RAD model is Rapid Application Development model. It is a type of incremental model.
In RAD model the components or functions are developed in parallel as if they were
mini projects. The developments are time boxed, delivered and then assembled
into a working prototype.
5 Write down the major aims of the RAD model.
 To decrease the time taken and the cost incurred to develop software systems.
 To limit the cost of accommodating change requests by incorporating them as early
as possible before large investments have been made on development and testing.
6 What are the phases in the rapid application development (RAD) model?
 Business modeling
 Data modeling
 Process modeling
 Application generation
 Testing and turnover
7 What are the advantages of the RAD model?
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.
Page 27 of 126
8 Define Agile Methods.
 Agile model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of
working software product.
 Agile Methods break the product into small incremental builds. These builds are
provided in iterations. Every iteration involves cross functional teams working
simultaneously on various areas like planning, requirements analysis, design,
coding, unit testing, and acceptance testing.
9 List out the various agile approaches.
 Crystal Technologies
 Atern(formerly DSDM)
 Feature-driven Development
 Scrum
 Extreme Programming (XP)
10 What is extreme programming?
Extreme programming (XP) is a software development methodology, which is intended
to improve software quality and responsiveness to changing customer requirements. As a
type of agile software development, it advocates frequent "releases" in short development
cycles, to improve productivity and introduce checkpoints at
which new customer requirements can be adopted.
11 List the fundamental principles of extreme programming?
The fundamental principles of Extreme Programming are Rapid feedback, assume
simplicity, Incremental change, Embracing change and Quality work.
12 What are the values of extreme programming?
Extreme Programming (XP) is based on the five values
 Communication
 Simplicity
 Feedback
 Courage
 Respect
13 What are the limitations of extreme programming?
 This becomes difficult where developers and users belong to different
organizations.
 Development staff need to be physically located in the same office.
 Communication problems if the application does not have a visual interface.
 Large, complex systems may initially need significant architectural effort. This
might preclude the use of XP.
14 What is SCRUM?
 Scrum is an efficient framework within which you can develop software with
teamwork. It is based on agile principles.
 Scrum supports continuous collaboration among the customer, team members, and
relevant stakeholders.

Page 28 of 126
15 Define software estimation.
Estimation techniques are of utmost importance in software development life cycle,
where the time required to complete a particular task is estimated before a project
begins. Estimation is the process of finding an estimate, or approximation, which is a
value that can be used for some purpose even if input data may be incomplete,
uncertain, or unstable.
16 List out steps in software estimation.
The four basic steps in Software Project Estimation are
 Estimate the size of the development product.
 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.
17 What are software effort estimation techniques?
 Algorithm models
 Expert judgment
 Analogy
 Parkinson
 Price to win
 Top-down
 Bottom-up
18 Distinguish between Bottom-up and Top-Down estimate.
Bottom-up Top-down
Use when no past project data Based on past project data
Identify all tasks that have to be done – so Divide overall estimate between jobs to be
quite time-consuming done
19 Define COSMIC Full function points.
 COSMIC FFP – Common Software Measurement Consortium Full Function Point.
 COSMIC deals with decomposing the system architecture into a hierarchy of
software layers.
 Unit is Cfsu (COSMIC functional size units).
20 Write about COCOMO model.
 Constructive Cost Model.
 It refers to a group of models.
 The basic model was built around the equation:
Effort=c*sizek,
 Where effort is measured in pm,or the number of ‘person-months’.
21 Define organic mode.
Organic mode is the case when relatively small teams developed software in a highly
familiar in-house environment and when the system being developed was small and
the interface requirements were flexible.
22 Define application composition.
In application composition the external features of the system that the users will
experience are designed. Prototyping will typically be employed to do this. With small
application that can be built using high-productivity application building tools,
development can stop at this point.
Page 29 of 126
23 List the steps of estimate effort.
Step 1: Use Wideband Delphi Technique to construct WBS. We suggest that the tasks
should not be more than 8 hrs. If a task is of larger duration, split it.
Step 2: Use Wideband Delphi Technique or Three-point Estimation to arrive at the
Effort Estimates for the Tasks.
24 Give an idea about parametric model?
 Models that focus on task or system size. Eg.Function Points.
 FPs originally used to estimate Lines of Code, rather than effort

 Models that focus on productivity: e.g. COCOMO


 In this Lines of code (or FPs etc) is an input

25 What is the use of COCOMO model and its types?


COCOMO predicts the effort and schedule for a software product development based on
inputs relating to the size of the software and a number of cost drivers that affect
productivity.
COCOMO has three different models that reflect the complexity:
 The Basic Model
 The Intermediate Model
 The Detailed Model
26 Write any two advantages of function point analysis. (Dec 11)
 Improved project estimating
 Understanding project and maintenance productivity
 Managing changing project requirements
 Gathering user requirements.
PART-B
1) Discuss in detail about software process and process models.
A software process is a set of activities that leads to the production of a software
product. These activities may involve the development of software from scratch in a
standard programming language like Java or C. Increasingly, however, new software is
developed by extending and modifying existing systems and by configuring and

Page 30 of 126
integrating off-the-shelf software or system components.
Software processes are complex and, like all intellectual and creative processes,
rely on people making decisions and judgements. Because of the need for judgement
and creativity, attempts to automate software processes have met with limited success.
Computer-aided software engineering (CASE) tools can support some process activities.
However, there is no possibility, at least in the next few years, of more extensive
automation where software takes over creative design from the engineers involved in
the software process.
Although there are many software processes, some fundamental activities are
common to all software processes:
1. Software specification the functionality of the software and constraints on its
operation must be defined.
2. Software design and implementation the software to meet the specification must be
produced.
3. Software validation the software must be validated to ensure that it does what the
customer wants.
4. Software evolution the software must evolve to meet changing customer needs.
Software process models:
The waterfall model:
 Plan-driven model. Separate and distinct phases of specification and development.
 Incremental development
 Specification, development and validation are interleaved. May be plan-driven or
agile.
 Reuse-oriented software engineering
 The system is assembled from existing components. May be plan-driven or agile.
In practice, most large systems are developed using a process that incorporates
elements from all of these models.
The waterfall model:

Page 31 of 126
Fundamental development activities:
1. Requirements analysis and definition the system's services, constraints and goals
are, established by consultation with system users. They are then defined in detail and
serve as a system specification.
2. System and software design the systems design process partitions the requirementsto
either hardware or software systems. It establishes overall system architecture. Software
design involves identifying and describing the fundamental software system abstractions
and their relationships.
3. Implementation and unit testing during this stage, the software design is realised as a
set of programs or program units. Unit testing involves verifying that each unit meets
its specification.
4. Integration and system testing the individual program units or programs are integrated
and tested as a complete system to ensure that the software requirements have been met.
After testing, the software system is delivered to the customer.
5. Operation and maintenance normally (although not necessarily) this is the longest
life-cycle phase. The system is installed and put into practical use. Maintenance:
involves correcting errors which were not discovered in earlier stages of the life cycle,
improving the implementation of system units and enhancing the system’s services as
new requirements are discovered.
In principle, the result of each phase is one or more documents that are approved
('signed off). The following phase: should not start until the previous phase has finished.
In practice, these stages overlap and fled information to each other. During design,
problems with requirements are identified; during coding design problems are found
and so on. The software process is not a simple linear model but involves a sequence of
iterations of the development activities.
Incremental development benefits:
The cost of accommodating changing customer requirements is reduced.
 The amount of analysis and documentation that has to be redone is much less than
is required with the waterfall model.
 It is easier to get customer feedback on the development work that has been done.
 Customers can comment on demonstrations of the software and see how much has
been implemented.
 More rapid delivery and deployment of useful software to the customer is possible.
 Customers are able to use and gain value from the software earlier than is possible
with a waterfall process.
The process is not visible.
 Managers need regular deliverables to measure progress. If systems are developed
quickly, it is not cost-effective to produce documents that reflect every version of the
system.
 System structure tends to degrade as new increments are added.
 Unless time and money is spent on refactoring to improve the software, regular
change tends to corrupt it structure. Incorporating further software changes
becomes increasingly difficult and costly.

Page 32 of 126
2) Explain in detail about Rapid Application development.
Rapid Application Development model relies on prototyping and rapid cycles of
iterative development to speed up development and elicit early feedback from business
users. After each iteration, developers can refine and validate the features with
stakeholders. RAD model is also characterized by reiterative user testing and the re-use
of software components. Hence, RAD has been instrumental in reducing the friction
points in delivering successful enterprise applications.
WaveMaker makes use of the RAD model to provide a Rapid Application
Development platform to create web and mobile applications. The following diagram
depicts WaveMaker RAD platform architecture, based on the MVC (Model-View-
Controller) pattern. Open standards, easy customization and rapid prototyping are
central to the platform.

Phases in RAD Model:


 Business Modeling
 Data Modeling
 Process Modeling
 Application Modeling
 Testing and Turnover
Page 33 of 126
Business Modeling: In this phase of development business model should be designed
based on the information available from different business activities. Before start the
development there should be a complete picture of business process functionality.
Data Modeling: Once the business modeling phase over and all the business analysis
completed, all the required and necessary data based on business analysis are identified
in data modeling phase.
Process Modeling: All the data identified in data modeling phase are planned to
process or implement the identified data to achieve the business functionality flow. In
this phase all the data modification process is defined.
Application Modeling: In this phase application id developed and coding completed.
With help of automation tools all data implemented and processed to work as real time.
Testing and turnover: All the testing activates are performed to test the developed
application.
Advantages of RAD Model:
 Fast application development and delivery. 
 Lest testing activity required. 
 Visualization of progress. 
 Less resources required.
 Review by the client from the very beginning of development so very less chance
to miss the requirements. 
 Very flexible if any changes required. 
 Cost effective. 
 Good for small projects.
Disadvantages of RAD Model:
 High skilled resources required. 
 On each development phase client’s feedback required. 
 Automated code generation is very costly. 
 Difficult to manage. 
 Not a good process for long term and big projects. 
 Proper modularization of project required. 
Page 34 of 126
3) Explain about Agile methods.
Agile software development methodology is a process for developing software
(like other software development methodologies – Waterfall model, V-Model, Iterative
model etc.) However, Agile methodology differs significantly from other
methodologies. In English, Agile means ‘ability to move quickly and easily’ and
responding swiftly to change – this is a key aspect of Agile software development as well.
Brief overview of Agile Methodology
 In traditional software development methodologies like Waterfall model, a
project can take several months or years to complete and the customer may not
get to see the end product until the completion of the project.
 At a high level, non-Agile projects allocate extensive periods of time for
Requirements gathering, design, development, testing and UAT, before finally
deploying the project.
 In contrast to this, Agile projects have Sprints or iterations which are shorter in
duration (Sprints/iterations can vary from 2 weeks to 2 months) during which pre-
determined features are developed and delivered.
 Agile projects can have one or more iterations and deliver the complete product at
the end of the final iteration.
Example of Agile software development:
Example: Google is working on project to come up with a competing product for MS
Word, that provides all the features provided by MS Word and any other features
requested by the marketing team. The final product needs to be ready in 10 months of
time. Let us see how this project is executed in traditional and Agile methodologies.
In traditional Waterfall model –
 At a high level, the project teams would spend 15% of their time on gathering
requirements and analysis (1.5 months)
 20% of their time on design (2 months)
 40% on coding (4 months) and unit testing
 20% on System and Integration testing (2 months).
 At the end of this cycle, the project may also have 2 weeks of User Acceptance
testing by marketing teams.
 In this approach, the customer does not get to see the end product until the end
of the project, when it becomes too late to make significant changes.
project schedule in traditional software development.
With Agile development methodology –
 In the Agile methodology, each project is broken up into several ‘Iterations’.
 All Iterations should be of the same time duration (between 2 to 8 weeks).
 At the end of each iteration, a working product should be delivered.
 In simple terms, in the Agile approach the project will be broken up into 10
releases (assuming each iteration is set to last 4 weeks).
 Rather than spending 1.5 months on requirements gathering, in Agile software
development, the team will decide the basic core features that are required in the
product and decide which of these features can be developed in the first

Page 35 of 126
iteration.
 Any remaining features that cannot be delivered in the first iteration will be
taken up in the next iteration or subsequent iterations, based on priority.
 At the end of the first iterations, the team will deliver a working software with
the features that were finalized for that iteration.

There will be 10 iterations and at the end of each iteration the customer is delivered a
working software that is incrementally enhanced and updated with the features that
were shortlisted for that iteration.

Page 36 of 126
4) List the role and principles of extreme programming.
Extreme Programming technique is very helpful when there is constantly
changing demands or requirements from the customers or when they are not sure about
the functionality of the system. It advocates frequent "releases" of the product in short
development cycles, which inherently improves the productivity of the system and also
introduces a checkpoint where any customer requirements can be easily implemented.
The XP develops software keeping customer in the target.

Phases of Extreme programming:


There are 6 phases available in Agile XP method, and those are explained as follows:
Planning:
 Identification of stakeholders and sponsors
 Infrastructure Requirements
 Security related information and gathering
 Service Level Agreements and its conditions
Analysis:
 Capturing of Stories in Parking lot
 Prioritize stories in Parking lot
 Scrubbing of stories for estimation
 Define Iteration SPAN(Time)
 Resource planning for both Development and QA teams
Design:
 Break down of tasks
 Test Scenario preparation for each task
 Regression Automation Framework
Execution:
 Coding
 Unit Testing
 Execution of Manual test scenarios

Page 37 of 126
 Defect Report generation
 Conversion of Manual to Automation regression test cases
 Mid Iteration review
 End of Iteration review
Wrapping:
 Small Releases
 Regression Testing
 Demos and reviews
 Develop new stories based on the need
 Process Improvements based on end of iteration review comments
Closure:
 Pilot Launch
 Training
 Production Launch
 SLA Guarantee assurance
 Review SOA strategy
 Production Support
There are two storyboards available to track the work on a daily basis, and those are
listed below for reference.
Story Cardboard
 This is a traditional way of collecting all the stories in a board in the form of stick notes
to track daily XP activities. As this manual activity involves more effort and time, it is
better to switch to an online form.
Online Storyboard
 Online tool Storyboard can be used to store the stories. Several teams can use it for
different purposes.
Roles:
Customer:
 Writes User Stories and specifies Functional Tests
 Sets priorities, explains stories
 May or may not be an end-user
 Has authority to decide questions about the stories!
Programmer:
 Estimates stories
 Defines Tasks from stories, and estimates
 Implements Stories and Unit Tests
Coach:
 Watches everything, makes sure the project stays on course
 Helps with anything
Tracker:
 Monitors Programmers progress, takes action if things seem to be going off
track.
 Actions include setting up a meeting with Customer, asking Coach or another
Programmer to help
Tester:
 Implements and runs Functional Tests (not Unit Tests!)
 Graphs results, and makes sure people know when test results decline.
Doomsayer:
 Ensures that everybody knows the risks involved
 Ensures that bad news isn't hidden, glossed over, or blown out of proportion

Page 38 of 126
Manager:
 Schedules meetings (e.g. Iteration Plan, Release Plan), makes sure the meeting
process is followed, records result of meeting for future reporting, and passes to
the Tracker
 Possibly responsible to the Gold Owner.
 Goes to meetings, brings back useful information
Gold Owner:
 The person funding the project, which may or may not be the same as the
Customer
5) What is SCRUM? Explain.
SCRUM is an agile development method which concentrates specifically on how
to manage tasks within a team-based development environment. Basically, Scrum is
derived from activity that occurs during a rugby match. Scrum believes in empowering
the development team and advocates working in small teams (say- 7 to 9 members).
It consists of three roles, and their responsibilities are explained as follows

Scrum Master:
Master is responsible for setting up the team, sprint meeting and removes obstacles to
progress
Product owner:
The Product Owner creates product backlog, prioritizes the backlog and is responsible
for the delivery of the functionality at each iteration
Scrum Team:
Team manages its own work and organizes the work to complete the sprint or cycle
Product Backlog:
This is a repository where requirements are tracked with details on the no of requirements
to be completed for each release. It should be maintained and prioritized by product
owner, and it should be distributed to the scrum team. Team can also request for a new
requirement addition or modification or deletion

Page 39 of 126
Scrum Practices:
Practices are described in detailed:

Process flow of Scrum:


Process flow of scrum testing is as follows:
 Each iteration of a scrum is known as Sprint
 Product backlog is a list where all details are entered to get end product
 During each Sprint, top items of Product backlog are selected and turned into Sprint
backlog
 Team works on the defined sprint backlog
 Team checks for the daily work
 At the end of the sprint, team delivers product functionality
6) Explain in detail about Managing interactive processes.
Models are defined as explicit representations of some portions of reality as perceived by
some actor. A model is active if it influences the reality it reflects; if changes to the
representation also change the way some actors perceive reality. Model activation is the
process by which a model affects reality. Activation involves actors interpreting the model
and adjusting their behavior to it. This process can be Automated, where a software
component executes the model, Manual, where the model guides the actionsof human
actors, or Interactive, where prescribed aspects of the model are automatically
interpreted and ambiguous parts are left to the users to resolve, with tool support. Fully
automated activation implies that the model must be formal and complete, while manual
and interactive activation also can handle informal and evolving models. We define a
model to be interactive if it is interactively activated. The
process of defining and updating an interactive model is called articulation. In this

Page 40 of 126
thesis we are primarily concerned with interactive models of work processes. By altering
models of their own work, users can control and customize the behaviour of an interactive
system. The inter-play of articulation and activation (Figure 2) keeps the models alive and
up to date as resources for learning, coordination and work support. The three engineering
challenges (articulation, activation, and reuse) all contribute to increasing the benefits of
interactive models and decreasing the efforts and learning required to use the system.

The Potential of Interactive Process Models:


The constantly changing nature of the competitive environment in the global network
economy creates emergent organizations, where” every feature of social organization
culture, meaning, social relationships, decision processes and so on are continually
emergent, following no predefined pattern”. This environment requires evolving
information systems, adapting their behavior to updated models of the usage
environment.
Articulation: Simple and User-Oriented Process Modelling-
Our approach relies on the assumption that end users must be actively involved in
creating, updating and interpreting models of their own work, as part of the work. Local
participants are the only ones with sufficient knowledge of the process. Modelling by
end users has met skepticism from the workflow research community. On the other
hand, studies of user participation in IS development, tailoring, knowledge management
and process improvement indicate that our approach is viable. In workflow
management, users also deal creatively with change and exceptions, often by taking the
process out of the system and handling it manually. Systems not designed for user
involvement thus present a barrier to local innovation, and are unable to capture these
contributions for further assessment and knowledge management. End user
participation remains primarily an organizational problem, involving trust, power and
community building, but simple, user-oriented, and adaptable modelling languages will
remove many barriers.
Activation: Customized and Integrated Software Support-
Simple and useful tools motivate use. Information systems that offer a wide range of
functionality often become overwhelmingly complex and incomprehensible.
Consequently, only a small portion of the available functionality is utilized. This
condition is known as featurisms. We need role and task specific user interfaces,
containing just what is needed in the current context. Interfaces and semantics should

Page 41 of 126
also adapt to the local needs of each project. Process models, articulating who performs
which tasks when and why, is a powerful resource for such customization. Systems and
processes should also adapt to the skills and preferences of each individual.
Personalization fosters a sense of ownership, further motivating active participation.
In virtual enterprises, the unique nature of each project, and the changing set
of partners, seldom makes it economically viable to integrate information systems
through conventional development methods. Standardization requires that the domain
is static and well understood, and is thus seldom appropriate for knowledge work.
Consequently, we need a flexible infrastructure that allows shared understanding and
semantic interoperability to emerge from the project, rather than being a prerequisite
for cooperation. Interactive models provide a simple, visual approach to capture shared
understanding as it unfolds.
Reuse: Process Knowledge Management-
The gap between what people say and what they do, makes it difficult to use plans and
other official descriptions of work as input to KM. Local articulation of process models
must thus be straightforward, but still some knowledge cannot be modelled and will
remain tacit. Process models will thus be incomplete while they are used, subject to an
ongoing elaboration and interpretation. Models are completed only when they are no
longer in use. Interactive modelling allows the system to handle incomplete, evolving
descriptions of work, by involving users in resolving incompleteness and
inconsistencies during activation. The openness of the approach allows local process
innovation to be captured, assessed and packaged for reuse in similar future projects.
7) Discuss in detail about basics of software estimation.
The four basic steps in software project estimation are:
1) Estimate the size of the development product. This generally ends up in either Lines
of Code (LOC) or Function Points (FP), but there are other possible units of measure. A
discussion of the pros & cons of each is discussed in some of the material referenced at
the end of this report.
2) Estimate the effort in person-months or person-hours.
3) Estimate the schedule in calendar months.
4) Estimate the project cost in dollars (or local currency)
Estimating size:
An accurate estimate of the size of the software to be built is the first step to an effective
estimate. Your source(s) of information regarding the scope of the project should,
wherever possible, start with formal descriptions of the requirements
Two main ways you can estimate product size are:
1) By analogy. Having done a similar project in the past and knowing its size, you
estimate each major piece of the new project as a percentage of the size of a similar piece
of the previous project. Estimate the total size of the new project by adding up the
estimated sizes of each of the pieces. An experienced estimator can produce reasonably
good size estimates by analogy if accurate size values are available for the previous
project and if the new project is sufficiently similar to the previous one.
2) By counting product features and using an algorithmic approach such as Function
Points to convert the count into an estimate of size. Macro-level “product features” may
Page 42 of 126
include the number of subsystems, classes/modules, methods/functions. More detailed
“product features” may include the number of screens, dialogs, files, database tables,
reports, messages, and so on.
Estimating effort:
Once you have an estimate of the size of your product, you can derive the effort estimate.
This conversion from software size to total project effort can only be done if you have a
defined software development lifecycle and development process that you follow to
specify, design, develop, and test the software. A software development project involves
far more than simply coding the software – in fact, coding is often the smallest part of
the overall effort. Writing and reviewing documentation, implementing prototypes,
designing the deliverables, and reviewing and testing the code take up the larger portion
of overall project effort. The project effort estimate requires you to identify and
estimate, and then sum up all the activities you must perform to build a product of the
estimated size.
There are two main ways to derive effort from size:
1) The best way is to use your organization’s own historical data to determine how
much effort previous projects of the estimated size have taken.
2) If you don’t have historical data from your own organization because you haven’t
started collecting it yet or because your new project is very different in one or more key
aspects, you can use a mature and generally accepted algorithmic approach such as
Barry Boehm’s COCOMO model or the Putnam Methodology to convert a size estimate
into an effort estimate.
Estimating schedule:
The third step in estimating a software development project is to determine the project
schedule from the effort estimate. This generally involves estimating the number of
people who will work on the project, what they will work on (the Work Breakdown
Structure), when they will start working on the project and when they will finish (this is
the “staffing profile”). Once you have this information, you need to lay it out into a
calendar schedule. Again, historical data from your organization’s past projects or
industry data models can be used to predict the number of people you will need for a
project of a given size and how work can be broken down into a schedule.
Estimating Cost:
There are many factors to consider when estimating the total cost of a project. These
include labor, hardware and software purchases or rentals, travel for meeting or testing
purposes, telecommunications (e.g., long-distance phone calls, video-conferences,
dedicated lines for testing, etc.), training courses, office space, and so on.
Exactly how you estimate total project cost will depend on how your organization
allocates costs. Some costs may not be allocated to individual projects and may be taken
care of by adding an overhead value to labor rates ($ per hour). Often, a software
development project manager will only estimate the labor cost and identify any
additional project costs not considered “overhead” by the organization.
The simplest labor cost can be obtained by multiplying the project’s effort estimate (in
hours) by a general labor rate ($ per hour). A more accurate labor cost would result
from using a specific labor rate for each staff position (e.g., Technical, QA, Project
Page 43 of 126
Management, Documentation, Support, etc.). You would have to determine what
percentage of total project effort should be allocated to each position. Again, historical
data or industry data models can help.

8) What are effort and cost estimation techniques? Explain in detail.


Size Oriented Metrics:
Source Lines of Code (SLOC): is software metric used to measure the size of software
program by counting the number of lines in the text of the program’s source code. This
metric does not count blank lines, comment lines, and library. SLOC measures are
programming language dependent. They cannot easily accommodate nonprocedural
languages. SLOC also can be used to measure others, such as errors/KLOC,
defects/KLOC, pages of documentation/KLOC, cost/KLOC. ii) Deliverable Source
Instruction (DSI): i similar to SLOC. The difference between DSI and SLOC is that s ”if -
then-else” statement, it would be counted as one SLOC but might be counted as several
DSI .
Function Oriented Metrics:
Function Point (FP): FP defined by Allan Albrecht at IBM in 1979, is a unit of
measurement to express the amount software functionality [5]. Function point analysis
(FPA) is the method of measuring the size of software. The advantage is that it can avoid
source code error when selecting different programming languages. FP is programming
language independent, making ideal for applications using conventional and
nonprocedural languages. It is based on data that are more likely to be known early in
the evolution of project.
Function types are as:
• External Inputs (EI): it originates from user or transmit ted from another application.
• External Outputs ( EO): it is derived data within application that provides
information to the user.
• External Enquiries (EQ): it is online i/p that results in the generation of some
immediate s/w response in the form of an online output.
• Internal Logical Files (ILF): is logical grouping of data that resides within the
applications boundary and maintained via EI.
Page 44 of 126
• External Interface Files (EIF): is logical grouping of data that resides external to
application but provides information that may be of use to the application.
Test Point (TP) Test point used for test point analysis (TPA), to estimate test effort for
system and acceptance tests. However, it is important to note that TPA itself only covers
functional testing. Hence, it is always used with FPA, that does not cover system and
acceptance tests. Consequently, FPA and TPA merged together provide means for
estimating both, white and black box testing efforts. There are a lot of dependent and
independent factors that need to be taken into account
Test effort estimation using UCP, is based upon use cases (UC). UC is systems behavior
under various conditions, based on requests from a stakeholder. UC capture contractual
agreements between these stakeholders about the systems behavior. Thus,the primary
task of UCP is to map use cases (UC) to test cases (TC). Hereby, each scenario together
with the corresponding exception flow for each UC serves as input for a specific TC.
Basically, the amount of test cases identified through this mapping results in the
corresponding test effort estimation
COCOMO (Constructive Cost Models):
This family of models proposed by Barry Boehm, is the most popular method which is
categorized in algorithmic methods. This method uses some equations and parameters,
which have been derived from previous experiences about software projects for
estimation. The models have been widely accepted in practice. In the COCOMOs, the
code-size S is given in thousand LOC (KLOC) and Effort is in person-month. Three
models of COCOMO given by Barry Boehm Simple COCOMO: It was the first model
suggested by Barry Boehm, which follows following formula: Effort = a*(KLOC)b where
S is the code-size, and a, b are complexity factors. This model uses three sets of a, b
depending on the complexity of the software only as given in table IX. The basic
COCOMO model is simple and easy to use. As many cost factors are not considered, it
can only be used as a rough estimate.
Intermediate COCOMO: In the intermediate COCOMO, a nominal effort estimation is
obtained using the power function with three sets of a, b, with coefficient a being slightly
different from that of the basic COCOMO as shown in table 1.

Expertise Based Estimation:


It is the most frequently applied estimation strategy for software projects. There is no
substantial evidence for use of estimation-based models however there are situationswhere
one can expect expert based estimation to be more precise than formal methods. This
method is usually used when there is limitation in finding data and gathering
requirements. Consultation is the basic issue in this method. The following expert

Page 45 of 126
estimation best practice guidelines are considered aiming at reducing the size of
situational and human biases in expert estimation.
. • Evaluate estimation accuracy, but avoid high evaluation pressure.
• Avoid conflicting estimation goals.
• Ask the estimators to justify and criticize their estimates.
• Avoid irrelevant and unreliable estimation information.
• Use documented data from previous development tasks.
• Find estimation experts with relevant domain background and good estimation
records.
• Estimate top-down and bottom-up, independently of each other.
• Use estimation checklists.
• Combine estimates from different experts and estimation strategies.
• Assess the uncertainty of the estimate.
Delphi Method:
The aim of Delphi method is to combine expert opinion and prevent bias due to
positions, status or dominant personalities. Delphi arranges an especial meeting among
the project experts and tries to achieve the true information. Delphi includes some steps
as,
a) The coordinator gives an estimation form to each expert.
b) Each expert presents his own estimation (without discussing with others).
c) The coordinator gathers all Forms and sum them up and start another iteration.
d) steps (b-c) are repeated until an approval is gained.
Rule Based Systems: Uses human expert knowledge to solve real-world problems that
normally would re- quire human intelligence. Expert knowledge is often represented in
the form of rules or as data within the Personnel Capability = Low THEN Risk Level =
High
Bayesian Belief Network:
It is the process of fore- casting the software effort to estimate software costs of both
development and maintenance. In the past decades, various kinds of software cost and effort
estimation methods have been proposed. However, there is no optimal approach to
accurately predict the effort needed for developing a software system. Because, the
information gathered at the early stages of software system development is insufficient for
providing a precise effort prediction. It is a complex activity that requires knowledge of
a number of key attributes. Bundle of data is needed, which is often impossible to get in
needed quantities. Hence, Bayesian Belief Networks are effective for cost and effort
estimation [9], [14]. BBNs are especially useful when the information about the past and/or
the current situation is vague, incomplete, conflicting, and uncertain. They are a very
effective method of modelling uncertain situations that depend on cause and effect. They
are compact networks of probabilities that capture the probabilistic relationship between
variables, as well as historical information about their relation- ships. BBNs are very
effective for modeling situations where some information is already known and incoming
data is uncertain or partially unavailable.An important fact to realize about Bayesian
Belief Networks is that they are not
dependent on knowing exact historical information or current evidence.
Page 46 of 126
9) Discuss in detail about COSMIC full function points.
Function Point Analysis (FPA) is one of the most widely used methods to determine the
size of software projects. FPA originated at a time when only a mainframe environment
was available. Sizing of specifications was typically based on functional decomposition
and modeled data. Nowadays, development methods like Object Oriented, Component
Based and RAD are applied more often. There is also more attention on architecture and
the use of client server and multitier environments. Another development is the growth
in complexity caused by more integrated applications, real‐ time applications and
embedded systems and combinations. FPA was not designed to cope with these various
newer development approaches.
The Common Software Measurement International Consortium (COSMIC), aimed to
develop, test, bring to market and to seek acceptance of a new software sizing method
to support estimating and performance measurement (productivity, time to market and
quality). The measurement method must be applicable for estimating the effort for
developing and maintaining software in various software domains. Not only business
software (MIS) but also real time software (avionics, telecom, process control) and
embedded software (mobile phones, consumer electronics) can be measured.
The basis for measurement must be found, just as in FPA, in the user requirements the
software must fulfil. The result of the measurement must be independent of the
development environment and the method used to specify these requirements. Sizes
depend only on the user require.
COSMIC Concepts:
The Functional User Requirements (FUR) are, according to the definition of a functional
size measurement method, the basis for measurement. They specify user’s needs and
procedures that the software should fulfil.
The FUR are analyzed to identify the functional processes. A Functional Process is an
elementary component of a set of FUR. It is triggered by one or more events in the world
of the user of the software being measured. The process is complete when it has executed
all that is required to be done in response to the triggering event.
Each functional process consists of a set of sub processes that are either movements or
manipulations of data. Since no one knows how to measure data manipulation, and since
the aim is to measure ‘data movement rich’ software, the simplifying assumption is
made that each functional process consists of a set of data movements.
A Data Movement moves one Data Group. A Data Group is a unique cohesive set of
data (attributes) specifying an ‘object of interest’ (i.e. something that is ‘of interest’ to
the user). Each Data Movement is counted as one CFP (COSMIC function point).
COSMIC recognizes 4 (types of) Data Movements:
 Entry moves data from outside into the process
 Exit moves data from the process to the outside world
 Read moves data from persistent storage to the process
 Write moves data from the process to persistent storage.

Page 47 of 126
From a pure size measurement point of view, the most important improvements of the
COSMIC method compared with using traditional Function Points are as follows
 The COSMIC method was designed to measure the functional requirements of
software in the domains of business application, real-time and infrastructure
software (e.g. operating systems, web components, etc.), in any layer of a multi-
layer architecture and at any level of decomposition. Traditional Function Points
were designed to measure only the functionality ‘seen’ by human usersof
business software in the application layer.
 Traditional Function Points use a size scale with a limited range of possible sizes
for each component. COSMIC functional processes are measured on a continuous
size scale with a minimum of 2 CFP and no upper size limit. Modern software can
have extremely large processes. Individual functional processes of roughly 100 CFP
have been measured in avionics software systems and in public national insurance
systems. Traditional Function Points can therefore give highly misleading sizes
for certain types of software which means that great care must be taken when using
these sizes for performance measurement or estimating
 The COSMIC method gives a much finer measure of the size of any changes to
be made to software than traditional function points. The smallest change that
can be measured with the COSMIC method is 1 CFP.
Users of the COSMIC method have reported the following benefits, compared with using
'1st generation' methods
 Easy to learn and stable due to the principles-based approach, hence 'future proof'
and cost-effective to implement;
 Well-accepted by project staff due to the ease of mapping of the method’s concepts
to modern software requirements documentation methods, and to its compatibility
with modern software architectures;
 Improves estimating accuracy, especially for larger software projects;
 Possible to size requirements automatically that are held in CASE tools;
 Reveals real performance improvement where using traditional function points
has not indicated any improvement due to their inability to recognise how
software processes have increased in size over time;
 Sizing with COSMIC is an excellent way of controlling the quality of the
requirements at all stages as they evolve.

Page 48 of 126
10) Explain in about COCOMO II a parametric productivity model.
COCOMO a parametric model:
COCOMO (Constructive Cost Estimation Model) was proposed by Boehm. According
to him, any software development project can be classified into one of the following
three categories based on the development complexity: organic, semidetached, and
embedded. The classification is done considering the characteristics of the product as
well as those of the development team and development environment. Usually these
three product classes correspond to application, utility and system programs,
respectively. Data processing programs are normally considered to be application
programs. Compilers, linkers, etc., are utility programs. Operating systems and real-
time system programs, etc. are system programs.
The definition of organic, semidetached, and embedded systems are elaborated below.
 Organic: A development project can be considered of organic type, if the project
deals with developing a well understood application program, the size of the
development team is reasonably small, and the team members are experienced
in developing similar types of projects.
 Semidetached: A development project can be considered of semidetached type, if
the development consists of a mixture of experienced and inexperienced staff.
Team members may have limited experience on related systems but may be
unfamiliar with some aspects of the system being developed.
 Embedded: A development project is considered to be of embedded type, if the
software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational procedures exist.
According to Boehm, software cost estimation should be done through three stages:
Basic COCOMO, Intermediate COCOMO, and Complete COCOMO.
Basic COCOMO Model:
The basic COCOMO model gives an approximate estimate of the project parameters.
The basic COCOMO estimation model is given by the following expressions:
Effort = a * (KLOC)b PM Tdev = 2.5 * (Effort)c Months
where
 KLOC is the estimated size of the software product expressed in Kilo Lines of
Code a, b, c are constants for each category of software products
 Tdev is the estimated time to develop the software, expressed in months
 Effort is the total effort required to develop the software product, expressed in
person months (PMs)
The effort estimation is expressed in units of person-months (PM). The value of the
constants a, b, c is given below:
Software project a b c

Organic 2.4 1.05 0.38

Semi-detached 3.0 1.12 0.35

Embedded 3.6 1.20 0.32

Page 49 of 126
Intermediate COCOMO Model:
The basic COCOMO model assumes that effort and development time are functions of
the product size alone. However, many other project parameters apart from the product
size affect the development effort and time required for the product. Therefore, in order
to obtain an accurate estimation of the effort and project duration, the effect of all
relevant parameters must be taken into account.
The intermediate COCOMO model recognizes this fact and refines the initial estimate
obtained using the basic COCOMO expressions by using a set of 15 cost drivers
(multipliers) based on various attributes of software development. For example, if
modern programming practices are used, the initial estimates are scaled downward by
multiplication with a cost driver having a value less than 1.
Each of the 15 attributes receives a rating on a six-point scale that ranges from "very
low" to "extra high" (in importance or value) as shown below. An effort multiplier from
the table below [i] applies to the rating. The product of all effort multipliers results in
an Effort Adjustment Factor (EAF).
Ratings
Cost Drivers Very Nomina Very Extra
Low l High
Low High High
l
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance constraints 1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environ
0.87 1.00 1.15 1.30
ment
Required turnabout time 0.87 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project attributes
Application of software engineering met
1.24 1.10 1.00 0.91 0.82
hods
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10
EAF is used to refine the estimates obtained by basic COCOMO as follows:
Effort|corrected = Effort * EAF
Tdev|corrected = 2.5 * (Effort|corrected) c
Page 50 of 126
Complete COCOMO Model:
Both the basic and intermediate COCOMO models consider a software product as a single
homogeneous entity. However, most large systems are made up several smaller sub-
systems, each of them in turn could be of organic type, some semidetached, or embedded.
The complete COCOMO model takes into account these differences incharacteristics of the
subsystems and estimates the effort and development time as the sum of the estimates for
the individual subsystems. This approach reduces the percentage of error in the final
estimate.
The following development project can be considered as an example application of the
complete COCOMO model. A distributed Management Information System (MIS) product
for an organization having offices at several places across the country can have the
following sub-components:
 Database part
 Graphical User Interface (GUI) part
 Communication part
Of these, the communication part can be considered as embedded software. The
database part could be semi-detached software, and the GUI part organic software. The
costs for these three components can be estimated separately, and summed up to give
the overall cost of the system.
11) Write short notes on Staffing Pattern.
Resource allocation in software development is important and many methods have
been proposed. Related empirical research is yet scarce and evidence is required to
validate the theoretical methods. This paper introduces the staffing pattern as a metric
of resource distribution among project phases, and verifies its effect on software quality
and productivity using real project data. The main findings are: (1) there exist different
staffing patterns in reality; (2) the staffing pattern has significant effect on software
quality (post-release defect density); (3) the staffing pattern has no significant effect on
productivity; (4) the effort invested on test, document or code inspection possibly
explains the effect of staffing pattern on software quality; (5) the effort consumed by
rework perhaps counteracts the effect of other potential factors on productivity.
Preliminary heuristics are suggested to resource allocation practices.
We name these as staffing patterns as follows:
(1) Rapid-team-buildup pattern (abbreviated Rapid for later reference). The staffing
levels peak in requirement phase, and decrease in later phases. This might mean the
culture of excessive documentation or design, leading to low ability to respond rapidly
for requirement change. Another possible reason would be to outsource part of the
system to other organization for design and development. In both situations, we
suppose the software quality and productivity are low.
(2) Fix-staff pattern (abbreviated Fix). The team size is fixed or stable across project
lifecycle. It is likely that the same team has done all work. Due to sufficient learning time
and communication within the team, we assumed that high software quality will be
yielded as a result. It is hard to assess its productivity: perhaps peoples work efficiently
due to effective communication, perhaps this effect cannot counteract against
the excessive human resources investment in a prolonged duration.
Page 51 of 126
(3) Design-construction-centric pattern (abbreviated Design). The staffing levels are
high in design and construction phases, and low in other phases. The reason for low
staffing level in requirement and test phases may be indifference to them, or
mature/simple product. The software quality and productivity might be low for the
former possibility, and high for the latter.
(4) Implementation-centric pattern (abbreviated Implement). The staffing levels are
high in construction and test phases, and low in other phases. The reason for low staffing
level in requirement and design phases may be indifference to them, or merelyproviding
coding and testing services in IT outsourcing market. The software quality and
productivity would be low for the former possibility, and high for the latter.
(5) Test-centric pattern (abbreviated Test). The staffing levels are relatively low in early
phases, but increase in test and transition phases. The increasing level in test phase may
be the result of intensive testing by a special team (in-house or outsourcing), or fire-
fighting for too many bugs. The software quality may be high, because the staffing level
in early phases is also stable and the situation is the same as Fix-staff pattern. Moreover,
it is possible that high staffing level in test or transition phase detects and removes more
defects before delivery. Similar to Fix-staff pattern, its productivity is hard to be
determined.
(6) Classical-Rayleigh pattern (abbreviated Rayleigh). Similar to classical Rayleigh
curve, the staffing levels are low at the beginning, gradually increase, peak at
construction phase, and drop at later phases. It is the most common pattern in our data
set. We assumed that the productivity is high in this situation, but the yield may be low
quality pertaining to insufficient communication inside team.
(7) Minimum-design pattern (abbreviated Mini Design). The trend of staffing level is an
“M” shape with 2 peaks at requirement and construction or test phases. Possibly the
design phase is minimized due to indifference to it, architecture reuse, mature or simple
product. It is also possible that several senior developers are branched from thewhole
team (and the design is parallel with other phase) rather than a turnover of staff.The
software quality and productivity might be low for the first possibility (indifference),
hard to assess for the last (branching), and high for the other
possibilities.
UNIT III ACTIVITY PLANNING AND RISK MANAGEMENT
Objectives of Activity planning – Project schedules – Activities – Sequencing and scheduling
– Network Planning models – Forward Pass & Backward Pass techniques – Critical path
(CRM) method – Risk identification – Assessment – Monitoring – PERT technique – Monte
Carlo simulation – Resource Allocation – Creation of critical patterns – Cost schedules.
PART-A
1 What are the objectives of activity planning? (Dec 12, May 13)
 Feasibility assessment
 Resource allocation
 Detailed costing
 Motivation
 Co-ordination

Page 52 of 126
2 Define Project Schedule.
A stage of a larger project, the project plan must be developed to the level of showing
dates when each activity should start and finish and when and how much of each
resource will be required. Once the plan has been refined to this level of detail we call it
a project schedule.
3 What are the three approaches to identify the activities that make up a project?
Essentially there are three approaches to identifying the activities or tasks that make up
a project
 The activity-based approach,
 The product-based approach
 The hybrid approaches.
4 Define activities
 If an activity must have a clearly defined start and a clearly defined end-point,
normally marked by the production of a tangible deliverable.
 An activity requires a resource (as most do) then that resource requirement must be
forecast able and is assumed to be required at a constant level throughout the
duration of the activity.
 The duration of an activity must be forecast able — assuming normal circum-
stances, and the reasonable availability of resources.
 Some activities might require that others are completed before they can begin these
are known as precedence requirements).
5 What do you understand by work breakdown structure (WBS)? (Dec 14)
This involves identifying the main (or high level) tasks required to complete a project
and then breaking each of these down into set of lower-level tasks.
Five levels of WBS.
 Project- engineering resources has been developed by TASK
 Deliverables- term for the quantifiable goods or services
 Components- designing the floor plane
 work-packages- Models for the description of software artifacts
 Tasks- Creation and distribution of organizing software
6 What are the rules for constructing precedence networks?
 A project network should have only one start node.
 A project network should have only one end node.
 A node has duration.
 Links normally have no duration.
 Precedents are the immediately preceding activities.
 Times moves from left to right
 A network may not contain loops.
 A network should not contain dangles.
7 Define Hammock activities. (Dec 13)
Hammock activities which, in themselves, have zero duration but are assumed to start
at the same time as the first ‘ham mocked’ activity and to end at the same time as the
last one.

Page 53 of 126
8 What is meant by forward pass?
The forward pass is carried out to calculate the earliest dates on which each activity
may be started and completed. Significance-calculation method used in Critical Path
Method.
9 What is meant by backward pass?
The second stage in the analysis of a critical path network is to carry out a backward
pass to calculate the latest date at which each activity may be started and finished
without delaying the end date of the project. The calculating the latest dates, we assume
that the latest finish date for the project is the same as the earliest finish date-
that is we wish to complete the project as early as possible.
10 What is critical path?
There will be at least one path through the network that defines the duration of the
project. This is known as critical path. Any delay to any activity on this critical path
will delay the completion of the project.
11 What do you mean by activity-based approach?
The activity-based approach consists of creating a list of all the activities that the project
is thought to evolve.
12 What are the measures of activity float?
Free float: the time by which an activity may be delayed without affecting any
subsequent activity
Interfering float: the difference between total float and free float. This i s quite
commonly used, particularly in association with the free float.
13 Define activity float.
The difference between an activity’s earliest start date and its latest start date (or
difference between an activity’s earliest and latest finish dates) is known as the
activity’s float-it is measure of how much the start or completion of an activity may be
delayed without affecting the end date of the project. Any activity with a float of zero is
critical (any delay in carrying out the activity delay the completion date of the project
as a whole.
14 What is the significance of a critical path? (Dec 14)
 In managing the project, we must pay particular attention to monitoring activities
on the critical path so that the effects of any delay or resource unavailability are
detected and corrected at the earliest opportunities.
 In planning the project, it is the critical path that we must shorten if we are to
reduce the overall duration of the project.
15 Write any three network diagram methods?
 PERT — Program evaluation and review technique.
 CPM — Critical path method.
 ADM — Arrow Diagramming method.
16 Define Risk Identification.
Risk management begins with analyzing the risks involved in the project. Risk
identification is not a one-off initiative since projects are constantly evolving and new
risks arise while other risks may dissipate or reduce in importance.

Page 54 of 126
17 What is meant by known Risk?
Risk is defined “an uncertain event or condition that, if it occurs has a positive or negative
effect on a project objective”. It includes transferring the risk to another party, avoiding
the risk, reducing the negative effect of the risk, and accepting some or all of the
consequences of a particular risk.
18 What is risk management? (Dec 11)
Risk management process begins when somebody asks what kind of events can damage
the business and how much damage can be done. Identifying and measuring the
potential loss exposures, choosing the most efficient methods of controlling and
financing loss exposure and implementing them and finally monitoring all the
outcomes are the main steps involved in Risk Management.
19 List out the framework for dealing with risk
 Risk identification – what risks might there be?
 Risk analysis and prioritization – which are the most serious risks?
 Risk planning – what are we going to do about them?
 Risk monitoring – what is the current state of the risk?
20 List the factors used to identify the risk. (Dec 12)
Approaches to identifying risks include:
 Use of checklists – usually based on the experience of past projects.
 Brainstorming – getting knowledgeable stakeholders together to pool concerns.
 Causal mapping – identifying possible chains of cause and effect.
21 Draw the categories of risk.

22 Define Risk Assessment.


A systematic process of evaluating the potential risks that may be involved in a
projected activity or undertaking.
23 What is PERT?
Project Evaluation and Review Technique (PERT) is a project management tool used to
schedule, organize, and coordinate tasks within a project. Its estimation considers three
values: the most optimistic estimate (O), a most likely estimate (M), and a pessimistic
estimate (least likely estimate (L)).
24 List the advantages of PERT Technique.
 Useful at many stages of project management
 Mathematically simple
 Give critical path and slack time
 Provide project documentation
 Useful in monitoring costs
Page 55 of 126
25 Difference between PERT and CPM.
PERT CPM
It is probabilistic whereas CPM is It estimates of activity duration are based
deterministic. on historical data.
It estimates are uncertain and we talk of CPM concentrates on time/cost trade off.
ranges of duration and the probability that
activity duration will fall into that range.
26 What is Monte Carlo (MC) method?
The Monte Carlo method is a numerical method for statistical simulation which utilizes
sequences of random numbers to perform the simulation

27 List out the components of Monte Carlo Simulation.


 Probability Distribution Function.
 Random Number Generation.
 Sampling Rule.
 Scoring/Tallying.
 Error Estimation.
 Parallelization.
28. What is resource allocation?
Resource Allocation is used to assign the variable resource in an economic way. In project
management, resource allocation is the scheduling of activities and the resources
required by those activities while taking into consideration both the resource
availability and the project time.
29 What are the categories of resources?
 Labour
 Equipment (E.G. Workstations)
 Materials
 Space
 Services
 Time: Elapsed Time Can Often Be Reduced by Adding More Staff
 Money: Used To buy the other resources.
30 List out Burman’s priority list
 Shortest critical activities
 Other critical activities
 Shortest non-critical activities
 Non-critical activities with least float
 Non-critical activities
31 List out the schedules under resource allocation.
 Activity Schedule indicating start and completion dates for each activity
 Resource Schedule indicating dates when resources needed + level of resources
 Cost Schedule showing accumulative expenditure

Page 56 of 126
32 How costs are categorized?
 Staff costs
 Overheads
 Usage charges
33 Define staff costs.
Staff costs includes not just salary, but also social security contributions by the employer,
holiday pay etc. Timesheets are often used to record actual hours spent oneach project
by an individual. One issue can be how time when a staff member is allocated and available
to the project, but is not actually working on the project, is dealt
with.
34 Define Overheads costs.
Overheads e.g. space rental, service charges etc. Some overheads might be directly
attributable to the project, in other cases a percentage of departmental overheads may
be allocated to project costs.
35 Define Usage charges.
Usage charges are some charges can be on a ‘pay as you go’ basis e.g. telephone
charges, postage, car mileage – at the planning stage an estimate of these may have to
be made.
PART-B
1) Explain in detail about the objectives of activity planning? (Dec 13)
 Ensure Appropriate resources available when required
 Avoid different competing for the same resources at the same time
 Produce a detailed schedule showing which staffs carry out each activity.
 Time cash flow forecast
 Replan the project during its life to correct drift from the target
 A detailed plan against which actual achievement may be measured.
Objectives of activity planning
Feasibility assessment:
Is the project possible within required timescales and resource constraints? It is
not until we have constructed a detailed plan that we can forecast a completion date
with any reasonable knowledge of its achievability.
Resource allocation:
What are the most effective ways of allocating resources to the project. When should
the resources be available? The project plan allows us to investigate the relationship
between timescales and resource availability
Detailed costing:
How much will the project cost and when is that expenditure likely to take place?
After producing an activity plan and allocating specific resources, we can obtain more
detailed estimates of costs and their timing.
Motivation:
Providing targets and being seen to monitor achievement against targets is an
effective way of motivating staff, particularly where they have been involved in setting
those targets in the first place.
Co-ordination:
When do the staff in different departments need to be available to work on a
particular project and when do staff need to be transferred between projects? The project
plan, particularly with large projects involving more than a single project team,
provides an effective vehicle for communication and coordination among teams.
Page 57 of 126
2) Explain in detail about the steps involved in project schedule. (May 14)

Step 1: Identify project scope and objectives.


Project objectives, Project authorities, and Modified project objectives.
Step 2: Identify project Infra structure.
Role of existing strategic plans, identifying standards, project organization.
Step 3: Analyze project characteristics, High-level risks.
Step 4: Identify project products and activities, Product break down structure, IOE has
standard PFD, Identifying product instances, Activity network for IOE Maintenance
Accounts.
Step 5: Estimate effort for each activity, IOE Maintenance Group Accounts- breaking
Page 58 of 126
activities down into manageable tasks.
Step 6: Identify activity risks.
Identifying risks for Amanda
Step 7: Allocate Resources.
Taking resource constraints into account,
Step 8: Review/Publicize plan
IOE existing quality standards
Step 9 &10: Execute plan and lower levels of planning, lower level planning for
individual modules.
3) Explain the different network planning models. Give example for precedence
construction.
A project is made up of a sequence of activities that form a network representing a
project.
 The path taking longest time through this network of activities is called the
“critical path.”
 The critical path provides a wide range of scheduling information useful in
managing a project.
 Critical Path Method (CPM) helps to identify the critical path(s) in the project
networks.
 CPM with a Single Time Estimate
 Used when activity times are known with certainty.
 Used to determine timing estimates for the project, each activity in the
project, and slack time for activities.
 CPM with Three Activity Time Estimates (a.k.a. PERT)
 Used when activity times are uncertain.
 Used to obtain the same information as the Single Time Estimate model
and probability information.
Time-Cost Models:
 Used when trade-off information cost is a major consideration in planning.
 Used to determine the least cost in reducing total project time.

Example1:
CPM with Single Time Estimate Consider the following consulting project

Page 59 of 126
Develop a critical path diagram (network) and determine the duration of the critical
path and Slack times for all activities
1. Draw the network
2. Compute early starts and early finish times (forward pass)
3. Compute late starts and late finish times (backward pass)
4. Compute Slack (LS-ES) per activity and Critical Path(s)

Example 2:
CPM with Three Activity Time Estimates Develop a critical path diagram (network)
and determine the duration of the critical path and Slack times for all activities
1. Draw the network
2. Compute early starts and early finish times (forward pass)
3. Compute late starts and late finish times (backward pass)
4. Compute Slack (LS-ES) per activity and Critical Path(s)
What is the probability of finishing this project in less than 53 days?
What is the probability that the project duration will exceed 56 days?

Time-Cost Models:
 Sometimes it is possible to "crash" (expedite) some activities thus reducing the
overall completion time for the entire project.
 Crashing an activity implies spending additional funds (e.g., overtime costs,
hiring more workers, and so on) to get the task done earlier
On many occasions reducing the project completion time that in turn reduces the fixed
cost outlays can generate substantial savings.
1. Draw the CPM network, identify the CP
2. Identify the least cost activity(ies) on the critical path(s)
3. Shorten the project completion time (CP) at the least cost Repeat until no more
crashing is possible (or cost exceeds the benefits)
• Assume fixed costs = $1,000 day.
• Find the optimum time-cost schedule.
CPM Assumptions/Limitations:
 Project activities can be identified as entities. (There is a clear beginning and
ending point for each activity.)
 Project activity sequence relationships can be specified and networked.
 Project control should focus on the critical path.
 The activity times follow the beta distribution, with the variance of the project
assumed to equal the sum of the variances along the critical path. Project control
should focus on the critical path.
Project Evaluation and Review Technique (PERT):
PERT is a project management tool used to schedule, organize, and coordinate tasks within
a project. It estimation considers three values: the most optimistic estimate (O), a most likely
estimate (M), and a pessimistic estimate (least likely estimate (L)).
Evaluate the PERT techniques:
Three estimates are produced for each activity
Page 60 of 126
• Most likely time (m)
• Optimistic time (a)
• Pessimistic (b)
Expected time’ te = (a + 4m +b) / 6
Activity standard deviation’ S = (b-a)/6
• Expected time: Helps to carry out a forward pass through a network similar to
CPM
• Activity standard deviation: Used as ranking measure of the degree of
uncertainty or risk for each activity.
Activity Optimistic Most Pessimisti Expected Standard
(a) likely (m) c(b) te deviation
s
A 5 6 8 6.17 0.5
B 3 4 5 4.00 0.33
C 2 3 3 2.83 0.17
D 3.5 4 5 4.08 0.25
E 1 3 4 2.83 0.5
F 8 10 15 10.50 1.17
G 2 3 4 3.00 0.33
H 2 2 2.5 2.08 0.08
Why Network Diagrams?
Splits up the decision-making process into
 Method/logic - the order in which tasks have to be completed
 Time – estimates for the time to completion can be added to each task
 Resources – these can be added and then analysis carried out
Two Parts to the Analysis:
 Forward Pass
 Calculates the Duration of the Project
 Backward Pass
 Calculates the slack/float for each task and shows the critical path
To calculate the total duration of the Project…
 For each task:
 Take the earliest start time (EST)
 Calculate the Earliest finish time (EFT):
EFT = EST+Duration

Page 61 of 126
Backward Pass:
 To calculate the float for each task?
 For each task:
 Take the latest start time (LST)
 Calculate the latest finish time (LFT):
LST = LFT-Duration

Constructing a Project Network:


 Terminology
 Activity: an element of the project that requires time.
 Merge activity: an activity that has two or more preceding activities on which it
depends.
 Parallel (concurrent) activities: Activities that can occur independently and, if
desired, not at the same time

Page 62 of 126
Activity-on-Node Fundamentals:

 Path: a sequence of connected, dependent activities.


 Critical path: the longest path through the activity network that allows for the
completion of all project-related activities; the shortest expected time in which
the entire project can be completed. Delays on the critical path will delay
completion of the entire project.
Forward Pass Computation:
 Add activity times along each path in the network (ES + Duration = EF).
 Carry the early finish (EF) to the next activity where it becomes its early start
(ES) unless the next succeeding activity is a merge activity, in which case the
largest EF of all preceding activities is selected.
Backward Pass Computation:
 Subtract activity times along each path in the network (LF - Duration = LS).
 Carry the late start (LS) to the next activity where it becomes its late finish (LF)
unless...
 The next succeeding activity is a burst activity, in which case the smallest LF of
all preceding activities is selected.
Determining Slack (or Float):
 Free Slack (or Float)
o The amount of time an activity can be delayed without delaying
connected successor activities

Page 63 of 126
 Total Slack
o The amount of time an activity can be delayed without delaying the entire
project
 The critical path is the network path(s) that has (have) the least slack in common.
Sensitivity of a Network:
 The likelihood the original critical path(s) will change once the project is
initiated.
Function of:
The number of critical paths
The amount of slack across near critical activities
4) Explain the importance of forward pass with an example. (Dec 14, May 15)
Forward pass:

The forward pass is carried out to calculate the earliest dates on which each activity
may be started and completed.
The forward pass and the calculation of earliest start dates is calculated according to the
following reasoning.
 Activities A, B and F may start immediately, so the earliest date for their start is
zero.
 Activity A will take 6 weeks, so the earliest it can finish is week 6.
 Activity B will take 4 weeks, so the earliest it can finish is week 4.
 Activity F will take 10 weeks, so the earliest it can finish is week 10.
 Activity C can start as soon as A has finished so its earliest start date is week 6. It
will take 3 weeks so the earliest it can finish is week 9.

Page 64 of 126
 Activities D and E can start as soon as B is complete so the earliest they can each
start is week 4. Activity D, which will take 4 weeks, can therefore finish by week
8 and activity E, which will take 3 weeks, can therefore finish by week 7.
 Activity G cannot start until both E and F have been completed. It cannot
therefore start until week 10 — the later of weeks 7 (for activity E) and 10 (for
activity F). It takes 3 weeks and finishes in week 13.
 Similarly, Activity H cannot start until week 9 — the later of the two earliest fin-
ished dates for the preceding activities C and a
 The project will be complete when both activities H and G have been completed.
Thus, the earliest project completion date will be the later of weeks 11 and 13—
that is, week 13.
The results of the forward pass are shown in Figure 6.18.

5) How to evaluate the pert techniques. (Dec 11, Apr 14)


Three estimates are produced for each activity
 Most likely time (m)
 Optimistic time (a)
 Pessimistic (b)
Expected time’ te = (a + 4m +b) / 6
Activity standard deviation’ S = (b-a)/6
 Expected time: Helps to carry out a forward pass through a network similar to
CPM
 Activity standard deviation: Used as ranking measure of the degree of
uncertainty or risk for each activity
 Pert labeling convention
Event Number Target Date

Expected Date Standard


deviation

Page 65 of 126
Activity Description Precedents Optimi Most Pessimistic(
stic (a) likely b)
(m)
A Hardware Selection 5 6 8
B Software Design 3 4 5
C Install Hardware A 2 3 3
D Code & test software B 3.5 4 5
E File take-on B 1 3 4
F Write user manuals 8 10 15
G User training E, F 2 3 4
H Install and test C,D 2 2 2.5

Activity Optimistic Most Pessimisti Expected Standard


(a) likely (m) c(b) te deviation s
A 5 6 8 6.17 0.5
B 3 4 5 4.00 0.33
C 2 3 3 2.83 0.17
D 3.5 4 5 4.08 0.25
E 1 3 4 2.83 0.5
F 8 10 15 10.50 1.17
G 2 3 4 3.00 0.33
H 2 2 2.5 2.08 0.08

Page 66 of 126
6) Explain in detail about the risk identification.
Risk identification:
Approaches to identifying risks include:
• Use of checklists – usually based on the experience of past projects
• Brainstorming – getting knowledgeable stakeholders together to pool concerns
• Causal mapping – identifying possible chains of cause and effect
Boehm’s top 10 development risks
Risk Risk reduction techniques

Personnel shortfalls Staffing with top talent; job matching; teambuilding;


training and career development; early scheduling of
key personnel
Unrealistic time and cost Multiple estimation techniques; design to cost;
estimates incremental development; recording and analysis of
past projects; standardization of methods
Developing the wrong Improved software evaluation; formal specification
software functions methods; user surveys; prototyping; early user
manuals
Developing the wrong Prototyping; task analysis; user involvement
user interface

Gold plating Requirements scrubbing, prototyping,


design to cost

Late changes to Change control, incremental development


requirements

Shortfalls in externally Benchmarking, inspections, formal specifications,


supplied components contractual agreements, quality controls

Shortfalls in externally Quality assurance procedures, competitive design etc


performed tasks

Real time performance Simulation, prototyping, tuning


problems

Development technically Technical analysis, cost-benefit analysis, prototyping ,


too difficult training

7) Explain in detail about the PERT technique and justify how PERT techniques
provide details in identifying the uncertainties and effort in a project. Find out the
expected duration and the standard deviation.
Project Evaluation and Review Technique (PERT) is a project management tool used to
schedule, organize, and coordinate tasks within a project. Its estimation considers three
values: the most optimistic estimate (O), a most likely estimate (M), and a pessimistic
estimate (least likely estimate (L)).

Page 67 of 126
Evaluate the PERT techniques:
Three estimates are produced for each activity
• Most likely time (m)
• Optimistic time (a)
• Pessimistic (b)
Expected time’ te = (a + 4m +b) / 6
Activity standard deviation’ S = (b-a)/6
• Expected time: Helps to carry out a forward pass through a network similar to
CPM
• Activity standard deviation: Used as ranking measure of the degree of
uncertainty or risk for each activity.
• Pert labeling convention

Event Number Target Date

Expected Date Standard deviation

Activity Description Precedents Optimi Most Pessimistic(


stic (a) likely b)
(m)
A Hardware Selection 5 6 8
B Software Design 3 4 5
C Install Hardware A 2 3 3
D Code & test software B 3.5 4 5
E File take-on B 1 3 4
F Write user manuals 8 10 15
G User training E, F 2 3 4
H Install and test C,D 2 2 2.5

Fig 3 The critical path

Page 68 of 126
PERT activity time estimates:
Activity Optimistic Activity durations(weeks), Pessimistic
(a) Most likely (m) (b)

A 5 6 8
B 3 4 5
C 2 3 3
D 3.5 4 5
E 1 3 4
F 8 10 15
G 2 3 4
H 2 2 2.5

The above table provides additional activity duration estimates for the network shown
in figure 3. There

Activity Optimistic Most Pessimistic Expected Standard


(a) likely (b) te deviation
(m) s

A 5 6 8 6.17 0.5
B 3 4 5 4.00 0.33
C 2 3 3 2.83 0.17
D 3.5 4 5 4.08 0.25
E 1 3 4 2.83 0.5
F 8 10 15 10.50 1.17
G 2 3 4 3.00 0.33
H 2 2 2.5 2.08 0.08

Activity Standard Deviations:


A quantitative measure of the degree of uncertainty of an activity duration estimate may
be obtained by calculating the standard deviation of an activity time, using the formula
s=b-a/6. The activity standard deviation is proportional to the difference between the
optimistic and pessimistic estimates, and can be used as a ranking measureof the degree
of uncertainty or risk for each activity.

The PERT technique uses the following three-step method for calculating the
probability of meeting or missing a target date:
 Calculate the standard deviation of each project event;
 Calculate the z value for each that has a target date;
 Convert z values to a probability.
Page 69 of 126
8) Explain with an example how critical path can be identified in precedence
networks?
(Dec 11, Jun 13)
 Formulating a network model
 Constructing Precedence network
 Representing lagged activities
 Hammock activities
 Labeling conventions
 Adding the time dimension
Forward pass
Backward pass
A project usually consists of multiple activities that occur both simultaneously and
sequentially. To determine the flow of these activities, you’ll need to create a Precedence
Diagram. After creating the Precedence Diagram, you can identify the activities that
would, if delayed, cause your project to come in late. This is the Critical Path definition.
A delay in any of the critical path activities will delay the entire project, regardless of
whether the other project activities are completed on or before time. The act of
determining the Critical Path is known as the Critical Path Method or the Critical Path
Analysis.
To determine the Critical Path and conduct Critical Path Analysis, you need to:
 Define the duration of each activity.
 Identify all the paths.
 Calculate the duration of each path.
 Identify the longest path.
 Identifying the critical path
There will be at least one path through the network that defines the duration of the
Page 70 of 126
project. This is known as critical path. Any delay to any activity on this critical path will
delay the completion of the project.
Significance of critical path
 In managing the project, we must pay particular attention to monitoring activities
on the critical path so that the effects of any delay or resource unavailability are
detected at the earliest opportunities.
 In planning the project, it is the critical path that we must shorten if we are to reduce
the overall duration of the project.

9) Explain in detail formulating a network model. (Dec 12, May 12)


Formulating a network model:
The first stage in creating a network model is to represent the activities and their
relationships as a graph. In activity-on-node we do this by representing activities as
nodes in the graph-the lines between nodes represent dependencies.

Constructing precedence networks:


 A project network should have only one start node.
 A project network should have only one end node.
 A node has duration.
 Links normally have no duration.
 Precedents are the immediate preceding activities. (Fig 6.9)

Page 71 of 126
 Times moves from left to right
 A network may not contain loops. (Fig 6.10)

 A network should not contain dangles. (Fig 6.11)

Representing lagged activities:


We might come across situations where we wished to undertake two activities in
parallel so long as there is a lag between the two. We might wish to document
amendments to a program as it was being tested - particularly if evaluating a prototype.
Where activities can occur in parallel with a time lag between them we represent the
lag with duration on the linking arrow as shown in Figure 6.13. This indicates that
documenting amendments can start one day after the start of prototype testing and will
be completed two days after prototype testing is completed.

Hammock activities:
A hammock activity (also hammock task) is a schedule or project planning term for a
grouping of tasks that "hang" between two end dates it is tied to. A hammock activity
can group tasks which are not related in the hierarchical sense of a Work Breakdown
Structure, or are not related in a logical sense of a task dependency where one task
must wait for another.
Page 72 of 126
Labeling conventions:
Earliest Estimated Earliest
Start Duration Finish

Activity Label, Activity Description

Latest Latest
Float
Start Finish
10) Explain how you will identify the major risks that might affect your project and
identify the strategies for minimizing each of those risks. (Dec 14, May 13,15)
Risk Evaluation:
After the potential risks have been identified, the project team then evaluates the risk
based on the probability that the risk event will occur and the potential loss associated with
the event. Not all risks are equal. Some risk events are more likely to happen than others,
and the cost of a risk event can vary greatly. Evaluating the risk for probability of occurrence
and the severity or the potential loss to the project is the next step in the risk management
process.

RISK AND IMP ACT:

1. There is a positive correlation—both increase or decrease together—between project


risk and project complexity. A project with new and emerging technology will have a
high-complexity rating and a correspondingly high risk.
2. The project management team will assign the appropriate resources to the
technology managers to assure the accomplishment of project goals. The more
complex the technology, the more resources the technology manager typically
needs to meet project goals, and each of those resources could face unexpected
problems.
3. Risk evaluation often occurs in a workshop setting. Building on the identification
of the risks, each risk event is analyzed to determine the likelihood of occurring and
the potential cost if it did occur. The likelihood and impact are both rated as high,
medium, or low. A risk mitigation plan addresses the items that have high
ratings on both factors—likelihood and impact.

Page 73 of 126
RISK ANALYSIS OF EQUIPMENT DELIVERY:
1. A project team analyzed the risk of some important equipment not arriving to the
project on time. The team identified three pieces of equipment that were critical to
the project and would significantly increase the costs of the project if they were late
in arriving.
2. One of the vendors, who was selected to deliver an important piece of equipment,
had a history of being late on other projects. The vendor was good and often took on
more work than it could deliver on time. This risk event (the identified equipment
arriving late) was rated as high likelihood with a high impact. The other two pieces
of equipment were potentially a high impact on the project but with a low
probability of occurring.
RISK MI TIG ATI ON :
After the risk has been identified and evaluated, the project team develops a risk
mitigation plan, which is a plan to reduce the impact of an unexpected event. The project
team mitigates risks in the following ways:
 Risk avoidance
 Risk sharing
 Risk reduction
 Risk transfer
Each of these mitigation techniques can be an effective tool in reducing individual risks
and the risk profile of the project. The risk mitigation plan captures the risk mitigation
approach for each identified risk event and the actions the project management team
will take to reduce or eliminate the risk.
Risk avoidance usually involves developing an alternative strategy that has a higher
probability of success but usually at a higher cost associated with accomplishing a
project task.
Risk sharing involves partnering with others to share responsibility for the risk
activities. Many organizations that work on international projects will reduce political,
legal, labor, and others risk types associated with international projects by developing a
joint venture with a company located in that country.
Risk reduction is an investment of funds to reduce the risk on a project. On international
projects, companies will often purchase the guarantee of a currency rate to reduce the risk
associated with fluctuations in the currency exchange rate. A project manager may hire an
expert to review the technical plans or the cost estimate on a project to increase the
confidence in that plan and reduce the project risk.
Risk transfer is a risk reduction method that shifts the risk from the project to another
party. The purchase of insurance on certain items is a risk transfer method. The risk is
transferred from the project to the insurance company.
11) Explain in detail about Monte Carlo Simulation.
A Monte Carlo method is a technique that involves using random numbers and probability
to solve problems. Monte Carlo simulation is a method for iteratively
evaluating a deterministic model using sets of random numbers as
inputs. This method is often used when the model is complex, nonlinear, or involves

Page 74 of 126
more than just a couple uncertain parameters. A simulation can typically involve over
10,000 evaluations of the model, a task which in the past was only practical using super
computers. The Monte Carlo method is just one of many methods for analyzing
uncertainty propagation, where the goal is to determine how random variation, lack of
knowledge, or error affects the sensitivity, performance, or reliability of the system
that is being modeled.
Monte Carlo simulation is categorized as a sampling method because the inputs are
randomly generated from probability distributions to simulate the process of sampling from
an actual population. So, we try to choose a distribution for the inputs that most closely
matches data we already have, or best represents our current state of knowledge. The
data generated from the simulation can be represented as probability distributions (or
histograms) or converted to error bars, reliability predictions, tolerance zones, and
confidence intervals. (See Figure 2).

The steps in Monte Carlo simulation corresponding to the uncertainty propagation


shown in Figure 2 are fairly simple, and can be easily implemented in Excel for simple
models. All we need to do is follow the five simple steps listed below:
Step 1: Create a parametric model, y = f(x1, x2, ..., xq).
Step 2: Generate a set of random inputs, xi1, xi2, ..., xiq.
Step 3: Evaluate the model and store the results as yi.
Step 4: Repeat steps 2 and 3 for i = 1 to n.
Step 5: Analyze the results using histograms, summary statistics, confidence intervals,
etc.

Page 75 of 126
12) Write short notes on Resource Allocation and Cost Schedule.
Resource allocation is the assignment of available resources to various uses. In the context
of an entire economy, resources can be allocated by various means, such as markets
or central planning. In project management, resource allocation or resource management is the
scheduling of activities and the resources required by those activities while taking into
consideration both the resource availability and the project time.
Nature of Resources:
 Labour – Members of the project team
 Equipment – Workstations and other communicating and office equipments
 Material – Items that are consumed
 Space – Office space
 Services – Some specialist services telecommunicating
 Time – Offset against the other primary resource
Identifying Resource Requirements:
 What resources are required along with the expected level of demand
 Consider each activity
 Identify required resources

Page 76 of 126
Scheduling Resources:
 Allocating resources for one activity limits flexibility for resource allocation and
scheduling of other activities
Priorities resource allocation:
 Total float priority
Activities are ordered according to their total float. Those with the smallest float are
assigned the highest priority
Ordered list priority:
 Ordered according to predefined criteria
 Shortest critical path – Critical activities
 Shortest non-critical activity
 Non-critical activity with least float
 Non-critical activities
Map on activity plan to assess the distribution of resources required over the duration of
the project
 Recruiting staff has cost
 Smooth the histogram by delaying the start of some activities

Creating Critical Paths:


 Scheduling resources can create new critical paths
 Delaying the start of an activity because of lack of resources will cause that activity
become critical if this uses up its float.
Page 77 of 126
Manage the allocation of resources within programmers:
The resources of an organization consist of people, materials, equipment, knowledge and
time. Organizations typically have limited resources; therefore, tradeoffs on what project
resources are expended and when are made every day within organizations. A resource
allocation plan is an important tool in effective management of scarce resources. The
timing of the need of those resources can be and should be determined within the project
schedules. A resource plan, which describes the type of resource needed and the timing of
that need, is critical to effective resource management. As the project schedule changes, the
resource plan must also be flexible enough to adjust as these changes occur.
Examples:
Allocating resources is fairly self-explanatory. If allocating stone for building a house,
the project manager must ensure that she procures enough stone to complete the project.
Regarding leveling, if renting equipment, the project manager must ensure it will be used
steadily rather than sporadically rented and returned. If contracting carpenters, the project
manager should aim to strive to keep a set number of carpenters working at a set number
of hours for the duration of the project to ensure consistency. Carpenters may have
difficulty scheduling more sporadic hours into their schedule, meaning the firm might then
have to contract more workers, leading to inconsistent results. Meanwhile, materials don't
necessarily need to be leveled as they have been purchased rather than rented or paid by
the hour.
Cost Schedules:
 Calculating cost is straightforward where organization has standard cost figures for
staff and other resources. Staff costs includes not just salary, but also social security
contributions by the employer, holiday pay etc. Timesheets are often used to record actual
hours spent on each project by an individual. One issue can be how time when a staff
member is allocated and available to the project, but is not actually working on the project,
is dealt with. Overheads e.g. space rental, service charges etc. Some overheads

Page 78 of 126
might be directly attributable to the project, in other cases a percentage of departmental
overheads may be allocated to project costs. Usage charges are some charges can be on a‘pay
as you go’ basis e.g. telephone charges, postage, car mileage – at the planning stage an
estimate of these may have to be made.

Cost profile:

This shows how much is going to be spent in each week. This could be important where
an organization allocates project budgets by financial year or quarter and the project
straddles more than one of these financial periods
Accumulative costs:
The project manager will also be concerned about planned accumulative costs. This chart
can be compared to the actual accumulative costs when controlling the project to assess
whether the project is likely to meet its cost targets.

Balancing concerns:
Successful project scheduling is not a simple sequence. Because of the inter-linking of
different concerns project planning will need to be iterative. The consequences of decisions
will need to carefully assessed and plans adjusted accordingly.

Page 79 of 126
Page 80 of 126

You might also like