SOFTWARE PROJECT MANAGEMENT

UNIT -I

INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT

Project Management is the discipline of defining and achieving targets while optimizing the use
of resources (time, money, people, materials, energy, space, etc) over the course of a project (a set of activities
of finite duration).
What is software project management?(2 M)
Software project management is an art and discipline of planning and supervising software
projects. It is a sub-discipline of software project management in which software projects planned,
implemented, monitored and controlled.

Why is project management important?

 Large amounts of money are spent on ICT(Information and communications technology) e.g. UK
government in 2003-4 spent £2.3 billions on contracts for ICT and only £1.4 billions on road building
 Project often fail – Standish Group claim only a third of ICT projects are successful. 82% were late and
43% exceeded their budget.
 Poor project management a major factor in these failures
 1 billion = 100 crore

Define SDLC. (2m)

Software Development Life Cycle:
 The software development life-cycle is a methodology that also forms the framework for planning and
controlling the creation, testing, and delivery of an information system.
 The software development life-cycle concept acts as the foundation for multiple different development and
delivery methodologies, such as the Hardware development life- cycle and Software development life-cycle.
While Hardware development life-cycles deal specifically with
hardware and Software development life-cycles deal specifically with
software, a Systems development life-cycle differs from each in that it
can deal with any combination of hardware and software, as a system
can be composed of hardware only, software only, or a combination of
both.
 The steps of SDLC are:-
 Planning
 Requirement analysis
 Design
 Development
 Testing
  Implementation & maintenance

What are 4P’s? (2m)

Four Project Dimensions
 People
 Process
 Product
 Technology
The 5 Variables of Project Control
1. Time - amount of time required to complete the project.
2. Cost - calculated from the time variable
3. Quality - The amount of time put into individual tasks determines the overall quality of the project.
4. Scope - Requirements specified for the end result.
5. Risk - Potential points of failure.
Trade – off triangle:

 The triangle illustrates the relationship between three primary forces in a project. Time is the
available time to deliver the project, cost represents the amount of money or resources available and
quality represents the fit-to-purpose that the project must achieve to be a success.
 The normal situation is that one of these factors is fixed and the other two will vary in inverse
proportion to each other. For example time is often fixed and the quality of the end product will
depend on the cost or resources available. Similarly if you are working to a fixed level of quality then
the cost of the project will largely be dependent upon the time available (if you have longer you can
do it with fewer people).
What is a project?
 The dictionary definitions put a clear emphasis on the project being a planned activity.
Some dictionary definitions:
“A specific plan or design” “A planned undertaking” “A large undertaking e.g. a public works
scheme” Longmans dictionary

 A project is “a temporary endeavor undertaken to create a unique product, service, or result.”

Operations, on the other hand, is work done in organizations to sustain the business. Projects are
different from operations in that they end when their objectives have been reached or the project has
been terminated.
 A project is temporary. A project’s duration might be just one week or it might go on for years, but
every project has an end date. You might not know that end date when the project begins, but it’s there
somewhere in the future. Projects are not the same as ongoing operations, although the two have a great
deal in common.
 A project is an endeavor. Resources, such as people and equipment, need to do work. The endeavor is
undertaken by a team or an organization, and therefore projects have a sense of being intentional,
planned events. Successful projects do not happen spontaneously; some amount of preparation and
planning happens first.
 Finally, every project creates a unique product or service. This is the deliverable for the project and the
reason, why that project was undertaken.
Jobs versus projects

What are the characteristics of projects? (2m)

Characteristics of projects
A task is more ‗project-like‘if it is:
 Non-routine
 Planned
 Aiming at a specific target
 Carried out for a customer
 Carried out by a temporary work group
 Involving several specialism
 Made up of several different phases
 Constrained by time and resources
 Large and/or complex
Software projects vs other types of projects:
Many techniques in general project management also apply to software project management, but
Fred Brooks identified some characteristics of software projects which make them particularly difficult:-

Invisibility: When a physical artifact such as a bridge is constructed the progress can actually be seen. with
software, progress is not immediately visible. Software project management can be the process of making the
invisible visible.

Complexity: Per dollar, pound or euro spent, software products contain more complexity than other engineered
artifacts.

Conformity: The 'traditional' engineer usually works with physical systems and materials like cement and
steel. These physical systems have complexity, but are governed by consistent physical laws. Software
developers have to conform to the requirement 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'.

Flexibility: That software is easy to change is seen as strength. However, where the software system interfaces
with a physical or organizational system, it is accommodate the other components rather than vice versa. Thus
software systems are particularly subject to change.
Differentiate contract and technical project management? (13 m)
Contract Management and Technical Project Management
 In-house projects are where the users and the developers of new software work for the same organization.
However, increasingly organizations contract out ICT development to outside developers.
 Here, the client organization will often appoint a 'project manager' to supervise the contract who will
delegate many technically oriented decisions to the contractors.
 Thus, the project manager will not worry about estimating the effort needed to write individual software
components as long as the overall project is within budget and on time.
 On the supplier side, there will need to be project managers who deal with the more technical issues. This
book leans towards the concerns of these 'technical' project managers.
Activities covered by project management
 A software project is not only concerned with the actual writing of software. Usually there are three
successive processes that bring a new system into being.

 Feasibility study
Is project technically feasible and worthwhile from a business point ofview?(recommendation of
the feasibility study might be not to carry out the proposed project)
 Planning
Only done if project is feasible - evolving plan allows us to control the project.
 Execution
Implement plan, but plan may be changed as we go along
Write briefly about SDLC model? (15 m)
The software development life-cycle (ISO 12207)
 The software development life cycle is a technical model. It identifies the technical constraints on the order
activities are done. This does NOT imply that a waterfall ‘approach is the only way to organize projects.
The technical model could be implemented as increments or in an evolutionary manner.
 ISO 12207 life-cycles are:
1. Requirements analysis
2. Architecture Design
3. Code and test
4. Installation \ Acceptance support
  Requirements analysis
– Requirements elicitation (kindle): what does the client need?
– Analysis: converting customer-facing‘ requirements into equivalents that developers can
understand
– Requirements will cover
• Functions
• Quality
• Resource constraints i.e. costs
– Requirement analysis has to face in (at least) two different directions. It needs to
communicate and elicit the requirements of the users, speaking in their language. It needs
to organize and translate those requirements into a form that developers can understand and
relate to.
 Architecture Design

Software Software
Requirements Components

Based on system requirements

– Defines components of system: hardware, software, organizational
– Software requirements will come out of this
 Detailed design
– Each software component is made up of a number of software units that can be separately
coded and tested. The detailed design of these units is carried out separately.
 Code and test
– Of individual components (separately coded and tested)
 Integration
– Putting the components together
 Qualification testing(the whole system)
– Testing the system (not just the software)
 Installation(meaning most like implementation) Install –Complete System
– The process of making the system operational
– Includes setting up standing data, setting system parameters, installing on operational
hardware platforms, user training etc
 Acceptance support
– Including maintenance and enhancement
Plans, methods and methodologies
 A plan of an activity must be based on some idea of a method of work. For example, if we asked to test
some software, we may know nothing about the software to be tested, but we could assume that we would
need to:
 Analyze the requirements for the software
 Devise and write test cases
 Create test scripts and expected results
 Compare the actual results and the expected results.
 While a method relates to a type of activity in general, a plan takes one or more methods and converts them
into real activities by identifying:
 Start and end dates
 Who will carry it out
 What tools and materials would be needed?
 The output from the method might be the input to another. Groups of methods or techniques are often
grouped into methodologies such as object – oriented design.
 Plans, methods and methodologies

Context

Plan
Methods
Methodology = a set of methods + start and end dates for eachactivity, A way of working
staffing, tools and materialsetc

Describe the different categorization of software projects. (13 m)

Some Ways of Categorizing Software Projects:
 Projects may differ because of the different technical products to be created. Thus we need to identify the
characteristics of a project which could affect the way in which it should be planned and managed. Other
factors are discussed below.
Compulsory versus voluntary users
 In workplaces there are systems that staffs have to use if they want to do something, such as recording a
sale. However, use of a system is increasingly voluntary, as in the case of computer games.
 Here it is difficult to elicit precise requirements from potential users as we could with a business system.
 What the game will do will thus depend much on the informed ingenuity of the developers, along with
techniques such as market surveys, focus groups and prototype evaluation.
Information systems versus embedded systems
 A traditional distinction has been between information systems which enable staff to carry out office
processes and embedded systems which control machines.
 A stock control system would be an information system. An embedded, or process control, system
might control the air conditioning equipment in a building.
 Some systems may have elements of both where, for example, the stock control system also controls an
automated warehouse.
Outsourced projects
 While developing a large project, sometimes, it makes good commercial sense for a company to
outsource some parts of its work to other companies. There can be several reasons behind such a
decision. For example, a company may consider outsourcing as a good option, if it feels that it does not
have sufficient expertise to develop some specific parts of the product or if it determines that some parts
can be developed cost-effectively by another company.
 Since an outsourced project is a small part of some project, it is usually small in size and needs to be
completed within a few months. Considering these differences between an outsourced project and a
conventional project, managing an outsourced project entails special challenges.
 Indian software companies excel in executing outsourced software projects and have earned a fine
reputation in this field all over the world. Of late, the Indian companies have slowly begun to focus on
product development as well.
 The type of development work being handled by a company can have an impact on its profitability. For
example, a company that has developed a generic software product usually gets an uninterrupted stream
of revenue over several years. However, outsourced projects fetch only one time revenue to any
company.
Objective-driven development
 Projects may be distinguished by whether their aim is to produce a product or to meet certain objectives.
 A project might be to create a product, the details of which have been specified by the client. The client
has the responsibility for justifying the product.
 On the other hand, the project requirement might be to meet certain objectives which could be met in a
number of ways. An organization might have a problem and ask a specialist to recommend a solution.
 Many software projects have two stages. First is an objective-driven project resulting in
recommendations. This might identify the need for a new software system. The next stage is a project
actually to create the software product.
  This is useful where the technical work is being done by an external group and the user needs are
unclear at the outset. The external group can produce a preliminary design at a fixed fee. If the design is
acceptable the developers can then quote a price for the second, implementation, and stage based on an
agreed requirement.
Who are called stakeholders? (2m)
Stakeholders
 These are people who have a stake or interest in the project In general, they could be users/clients or
developers/implementers
 They could be:
 Within the project team
 Outside the project team, but within the same organization
 Outside both the project team and the organization
 Different stakeholders may have different objectives – need to define common project objectives Project
Leader is to recognize these different interests (good Communicator/Negotiator)
 Boehm & Ross – ‗Theory W‘ Win-Win
Setting objectives
 To develop a successful project, the project manager and the team members must be aware of the factors
that lead them to success. There must be well-defined objectives accepted by all the people involved in the
development process.
 A project authority must be identified to have an overall authority over the project. This authority is
governed by a project steering committee also called as a project management board. Day–to-day activities
must be reported to the steering committee by the project manager at regular intervals.
 Any changes to the defined objectives can be done only by the steering committee. An effective objective’s
scope for an individual must be within the individual’s control. Objectives can be broken down into goals or
sub-objectives in order to achieve them.
Define SMART technique. (2m)
SMART technique is used for a well-defined objective.
 Specific ; Concrete and well-defined; Up to the point.
 Measurable : measures of effectiveness.
 Achievable ; power within the individual or the group.
 Relevant : satisfy the purpose of the project.
 Time-oriented : time limit for successful achievement of the project.
 The objectives are met only when the system becomes operational. Performance measures deals the
reliability of the operational system and predictive measures are done during the development of the project
by measuring the effectiveness of the developing system.
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 etc
 Measures of effectiveness
 Performance Measurement-
– To measure reliability – mtbf(mean time between failures)
– +Seek Predictive Measures
• Large number of errors during code, inspections needed
The Business Case
 Most projects need to have a justification or business case: the effort and expense of pushing the project
through must be seen to be worthwhile in terms of the benefits that will eventually be felt.
 A cost—benefit analysis will often be part of the project's feasibility study. This will itemize and quantify
the project's costs and benefits. The benefits will be affected by the completion date: the sooner the project
is completed, the sooner the benefits can be experienced.
 The quantification of benefits will often require the formulation of a business model which explains how the
new application can generate the claimed benefits.
 A simple example of a business model is that a new web-based application might allow customers from all
over the world to order a firm's products via the internet, increasing sales and thus increasing revenue and
profits.
 Any project plan must ensure that the business case is kept intact. For example:
 That development costs are not allowed to rise to a level which threatens to exceed the value of benefits;
 That the features of the system are not reduced to a level where the expected benefits cannot be realized;
 That the delivery date is not delayed so that there is an unacceptable loss of benefits.

Project Success and Failure

 The project plan should be designed to ensure project success by preserving the business case for the
project. However, every non-trivial project will have problems, and at what stage do we say that a project is
actually a failure? Because different stakeholders have different interests, some stakeholders in a project
might see it as a success while others do not.
 Broadly speaking, we can distinguish between project objectives and business objectives. The project
objectives are the targets that the project team is expected to achieve. In the case of software projects, they
can usually be summarized as delivering:
 The agreed functionality
 To the required level of quality
 On time
 Within budget.
 A project could meet these targets but the application, once delivered could fail to meet the business case. A
computer game could be delivered on time and within budget, but might tfien not sell. A commercial
website used for online sales could be created successfully, but customers might not use it to buy products,
because they could buy the goods more cheaply elsewhere.

What is Management?
 We have explored some of the special characteristics of software. We now look at the 'management' aspect
of software project management. 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.
 Much of the project manager's time is spent on only three of the eight identified activities, viz., project
planning, monitoring and control. The time period during which these activities are carried out is indicated
in Fig. It shows that project management is carried out over three well-defined stages or processes,
irrespective of the methodology used.
Management Control
 Management in general, involves setting objectives for a system and then monitoring the performance of the
system. In Figure 1.5 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 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'.

What are the key aspects in which modern software project management practices differ from those of
traditional software project management? ( 15 m)
Traditional versus Modern Project Management Practices:
 Over the last two decades, the basic approach taken by the software industry to develop software has
undergone a radical change. Hardly any software is being developed from scratch any more. Software
development projects are increasingly being based on either tailoring some existing product or reusing
certain pre-built libraries
 We will discuss some important differences between modern project management practices and traditional
practices.
 Planning Incremental Delivery Few decades ago, projects were much simpler and therefore more
predictable than the present day projects. In those days, projects were planned with sufficient detail, much
before the actual project execution started. After the project initiation, monitoring and control activities
were carried out to ensure that the project execution proceeded as per plan. Now, projects are required to be
completed over a much shorter duration, and rapid application development and deployment are considered
key strategies. The traditional long-term planning has given way to adaptive short-term planning. Instead of
making a long-term project completion plan, the project manager now plans all incremental deliveries with
evolving functionalities. This type of project management is often called extreme project management.
Extreme project management is a highly flexible approach to project management that concentrates on the
human side of project management (e.g., managing project stakeholders), rather than formal and complex
planning and monitoring techniques.
 Quality Management Of late, customer awareness about product quality has increased significantly; Tasks
associated with quality management have become an important responsibility of the project manager. The
key responsibilities of a project manager now include assessment of project progress and tacking the quality
of all intermediate artifacts.
 Change Management Earlier, when the requirements were signed off by the customer, any changes to the
requirements were rarely entertained. Customer suggestions are now actively being solicited and
incorporated throughout the development process. To facilitate customer feedback, incremental delivery
models are popularly being used. Product development is being carried out through a series of product
versions implementing increasingly greater functionalities. Also customer feedback is solicited on each
version for incorporation. This has made it necessary for an organization to keep track of the various
versions and revisions through which the product develops. Another reason for the increased importance of
keeping track of the versions and revisions is the following. Application development through
customization has become a popular business model. Therefore, existence of a large number of versions of a
product and the need to support these by a development organization has become common. In this context,
the project manager plays a key role in product base lining and version control. This has made change
management a crucial responsibility of the project manager. Change management is also known as
configuration management.

AN OVERVIEW OF PROJECT PLANNING

Introduction to Step Wise project planning
Discuss about the outline of step wise project planning? (15 m)
 This chapter describes a framework of basic steps in project planning upon which the following chapters
build. Many different techniques can be used in project planning and this chapter gives an overview of
the points at which these techniques can be applied during project planning.
 The framework described is called the Step Wise method to help to distinguish it from other methods
such as PRINCE2.
 PRINCE2 is a set of project management standards that were originally sponsored by what is now the
Office of Government Commerce (OGC) for use on British government ICT and business change
projects. The standards are now also widely used on non-government projects in the United Kingdom.
Step Wise should be compatible with PRINCE2. It should be noted, however, that Step Wise covers
only the planning stages of a project and not monitoring and control.
 The fig provides an outline of the main planning activities. Steps 1 and 2 ‘Identify project scope and
objectives’ and ‘Identify project infrastructure’ could be tackled in parallel in some cases. Steps 5 and 6
will need to be repeated for each activity in the project.
 A major principle of project planning is to plan in outline first and then in more detail as the time
to carry out an activity approaches. Hence the lists of products and activities that are the result of Step4 will be
reviewed when the tasks connected with a particular phase of a project are considered in more detail. This will
be followed by a more detailed iteration of Steps 5 to 8 for the phase under consideration.
 Step 0: Select project

This is called Step 0 because in a way it is outside the main project planning process.
Proposed projects do not appear out of thin-air some process must decide to initiate this project rather than
some other. While a feasibility study might suggest that there is a business case for the project, it would still
need to be established that it should have priority over other projects. This evaluation of the merits of projects
could be part of project portfolio management.

Step 1: Identify project scope and objectives

The activities in this step ensure that all the parties to the project agree on the objectives and are
committed to the success of the project. We have already looked at the importance of the correct definition of
objectives.

Step 1.1: Identify objectives and practical measures of the effectiveness in meeting those objectives

Step 1.2: Establish a project authority

We have already noted that a single overall project authority needs to be established so that there
is unity of purpose among all those concerned.

Step 1.3: Stakeholder analysis identify all stakeholders in the project and their interests

Essentially all the parties who have an interest in the project need to be identified.

Step 1.4: Modify objectives in the light of stakeholder analysis

In order to gain the full cooperation of all concerned, it might be necessary to modify the project
objectives. This could mean adding new features to the system which give a benefit to some stakeholders as a
means of assuring their commitment to the project. This is potentially dangerous as the system size may be
increased and the original objectives obscured. Because of these dangers ,it is suggested that this process be
done consciously and in a controlled manner.

Step 1.5: Establish methods of communication with all parties

For internal staff this should be fairly straightforward, but a project leader implementing for
example, a payroll system would need to find a contact point with BACS (Bankers Automated Clearing
Scheme), for instance. This step could lead to the first draft of a communications plan.

Step 2: Identify project infrastructure

Projects are never carried out in a vacuum. There is usually some kind of existing infrastructure
into which the project must fit. Where project managers are new to the organization, they must find out the
precise nature of this infrastructure. This could be the case where the project manager works for an outside
organization carrying out the work for a client.

Step 2.1: Identify relationship between the project and strategic planning

We know how project portfolio management supported the selection of the projects to be carried
out by an organization. Also, how programmed management can ensure that a group of projects contribute to a
common organizational strategy. There is also a technical framework within which the proposed new systems
are to fit. Hardware and software standards, for example, are needed so that various systems can communicate
with each other. These technical strategic decisions
should be documented as part of an enterprise architecture process. Compliance with the enterprisearchitecture
should ensure that successive ICT projects create software and other components compatible with those created
by previous projects and also with the existing hardware and software platforms.

Step 2.2: Identify installation standards and procedures

Any organization that develops software should define their development procedures. As a
minimum, the normal stages in the software life cycle to be carried out should be documented along with the
products created at each stage. Change control and configuration management standards should be in place to
ensure that changes to requirements are implemented in a safe and orderly way. The procedural standards may
lay down the quality checks that need to be done at each point of the project life cycle or these may be
documented in a separate quality standards
and procedures manual. The organization, as part of its monitoring and control policy, may have a measurement
program me in place which dictates that certain statistics have to be collected at various stages of a project.
Finally the project manager should be aware of any project planning and control standards. These will relate to
how the project is controlled: for example, the way that the hours spent by team members on individual tasks
are recorded on timesheets control.

Step 2.3: Identify project team organization

Project leaders, especially in the case of large projects, might have some control over the
way that their project team is to be organized. Often, though, the organizational structure will be dictated to
them. For example, a high-level managerial decision might have been taken that software developers and
business analysts will be in different groups, or that the development of business-to-consumer web applications
will be done within a separate group from that responsible for ‘traditional’ database applications.

If the project leader does have some control over the project team organization then this would best be
considered at a later stage (see Step 7: Allocate resources).

Step 3: Analyse project characteristics

The general purpose of this part of the planning operation is to ensure that the appropriate
methods are used for the project.

Step 3.1: Distinguish the project as either objective- or product-driven

This has already been discussed. As development of a system advances it tends to

become more product-driven, although the underlying objectives always remain and must be respected.

Step 3.2: Analyse other project characteristics (including quality-based ones)

For example, is an information system to be developed or a process control system, or

will there be elements of both? Will the system be safety critical, where human life could be threatened by a
mal function?

Step 3.3: Identify high-level project risks

Consideration must be given to the risks that threaten the successful outcome of the
project. Generally speaking, most risks can be attributed to the operational or development environment, the
technical nature of the project or the type of product being created.

Step 3.4: Take into account user requirements concerning implementation

The clients may have their own procedural requirements. For example, an organization
might mandate the use of a particular development method.
Step 3.5: Select development methodology and life-cycle approach

The development methodology and project life cycle to be used for the project will be
influenced by the issues raised above. The idea of a methodology, that is, the group of methods to be used in
a project, was already discussed. For many software developers, the choice of methods will seemobvious: they
will use the ones that they have always used in the past.. While the setting of objectives involves identifying the
problems to be solved, this part of planning is working out the ways in which these problems are to be solved.
For a project that is novel to the planner, some research into the methods typically used in the problem domain
is worthwhile. For example, sometimes, as part of a project, a questionnaire survey has to be conducted. There
are lots of books on the techniques used in such surveys and a wise move would be to look at one or two of
them at the planning stage.

Step 3.6: Review overall resource estimates

Once the major risks have been identified and the broad project approach has been
decided upon, this would be a good point at which to re-estimate the effort and other resources required to
implement the project. Where enough information is available an estimate based on function points might be
appropriate.

Step 4: Identify project products and activities

The more detailed planning of the individual activities now takes place. The longer-term
planning is broad and in outline, while the more immediate tasks are planned in some detail.

Step 4.1: Identify and describe project products (or deliverables)

Identifying all the things the project is to create helps us to ensure that all the activities
we need to carry out are accounted for. Some of these products will be handed over to the client at the end of
the project these are deliverables. Other products might not be in the final configuration, but are needed as
intermediate products used in the process of creating the deliverables. These products will include a large
number of technical products, such as training material and operating instructions. There will also be products
to do with the management and the quality of the project. Planning documents would, for example, be
management products. The products will form a hierarchy. The main products will have sets of component
products which in turn may have sub-component products and so on. These relationships can be documented in
a Product Breakdown Structure (PBS)- see Figure 1.5. In this example the products have been grouped into
those relating to the system as a whole, and those related to individual modules. A third ‘group’, which happens
to have only one product, is called ‘management products’ and consists of progress reports. The asterisk in the
progress reports indicates that there will be new instances of the entity ‘progress report’ created repeatedly
throughout the project. Note that in Figure 1.5 the only boxes that represent tangible products are those at the
bottom of the hierarchy that are not further subdivided. Thus there are only six individual product types shown
in the diagram. The boxes that are higher up for example ‘module products’ – are simply the names of groups
of items. Some products are created from scratch, for example new software components. A product could quite
easily be a document, such as a software design document. It might be a modified version of something that
already exists, such as an amended piece of code. A product could even be a person, such as a ‘trained user’, a
product of the process of training. These specify that products at the bottom of the PBS should be documented
by Product Descriptions which contain:

 the name/identity of the product;

 the purpose of the product;
 the derivation of the product (that is, the other products from which it is derived);
 Fig 1.5 A fragment of a Product Breakdown Structure for a system development task

 the composition of the product;

 the form of the product;
 the relevant standards;
 the quality criteria that define whether the product is acceptable.

Fig 1.6 A Product Breakdown Structure (PBS) for the products needed to produce an invitation to tender (ITT)

Step 4.2: Document generic product flows

Some products will need one or more other products to exist first before they can be
created. For example, a program design must be created before the program can be written and the program
specification must exist before the design can be commenced. These relationships can be portrayed in a Product
Flow Diagram (PFD). Figure 1.7 gives an example. Note that the ‘flow’ in the diagram is assumed to be from
top to bottom and left to right. In the example in Figure 1.7, ‘user requirements’ is in an oval which means that
it is used by the project but is not created by it. It is often convenient to identify an overall product at the bottom
of the diagram, in this case ‘integrated/tested software’, into which all the other products feed. PFDs should not
have links between products which loop back iteratively. This is emphatically not because iterations are not
recognized. On the contrary, the PFD allows for looping back at any point. For example, in the PFD shown
in Figure 1.7, say that during integration testing it was found that a user requirement had been missed in the
overall system specification. If we go back to overall system specification and change it we can see from the
PFD that all the products that follow it might need to be reworked. A new module might need to be designed
and coded, test cases would need to be added to check that the new requirements had been successfully
incorporated, and the integration testing would need to be repeated. The form that a PFD takes will depend on
assumptions and decisions about how
the project is to be carried out. These decisions may not be obvious from the PFD and so a textual description
explaining the reasons for the structure can be helpful.

Fig 1.7 A fragment of a Product Flow Diagram (PFD) for a software development task

Step 4.3: Recognize product instances

Where the same generic PFD fragment relates to more than one instance of a particular type
of product, an attempt should be made to identify each of those instances. In the example in Figure1.5, it could
be that in fact there are just two component software modules in the software to be built.

Step 4.4: Produce ideal activity network

In order to generate one product from another there must be one or more activities that carry out
the transformation. By identifying these activities we can create an activity network which shows the tasks that
have to be carried out and the order in which they have to be executed.

The activity networks are ‘ideal’ in the sense that no account has been taken of resource
constraints. For example, in Figure 1.8, it is assumed that resources are available for both software modules
to be developed in parallel. A good rule is that activity networks are never amended to take account of resource
constraints.
 Fig 1.8 An example of an activity network

Step 4.5: Modify the ideal to take into account need for stages and checkpoints

The approach to sequencing activities described above encourages the formulation of a

plan which will minimize the overall duration, or ‘elapsed time’, for the project. It assumes that an activity will
start as soon as the preceding ones upon which it depends have been completed. There might, however, be a
need to modify this by dividing the project into stages and introducing checkpoint activities. These are activities
which draw together the products of preceding activities to check that they are compatible. This could
potentially delay work on some elements of the project- there has to be a trade-off between efficiency and
quality. The people to whom the project manager reports could decide to leave the routine monitoring of
activities to the project manager. However, there could be some key activities, or milestones, which represent
the completion of important stages of the project of which they would want to take particular note. Checkpoint
activities are often useful milestones.

Step 5: Estimate effort for each activity

Step 5.1: Carry out bottom-up estimates

Some overall estimates of effort, cost and duration will already have been done (see Step
3.6). At this point, estimates of the staff effort required, the probable elapsed time and the non-staff resources
needed for each activity will need to be produced. The method of arriving at each of these estimates will vary
depending on the type of activity. The difference between elapsed time and effort should be noted. Effort is the
amount of work that needs to be done. If a task requires three members of staff to work for two full days each,
the effort expended is six days. Elapsed time is the time between the start and end of a task. In our example
above, if the three members of staff start and finish at the same time then the elapsed time for the activity would
be two days. The individual activity estimates of effort should be summed to get an overall bottom-up estimate
which can be reconciled with the previous top-down estimate. The activities on the activity network can be
annotated with their elapsed times so that the overall duration of the project can be calculated.

Step 5.2: Revise plan to create controllable activities

The estimates for individual activities could reveal that some are going to take quite a
long time. Long activities make a project difficult to control. If an activity involving system testing is to take12
weeks, it would be difficult after six weeks to judge accurately whether 50 per cent of the work is completed. It
would be better to break this down into a series of smaller subtasks.

There might be a number of activities that are important, but individually take up very
little time. For a training course, there might be a need to book rooms and equipment, notify those attending,
and register students on the training system, order refreshments, copy training materials and so on. In a situation
like this it would be easier to bundle the activities into a single merged activity ‘make training course
arrangements’ which could be supplemented with a checklist.

In general, try to make activities about the length of the reporting period used for
monitoring and controlling the project. If you have a progress meeting every two weeks, then it would
convenient to have activities of two weeks’ duration on average, so that progress meetings would normally be
made aware of completed tasks each time they are held.

Step 6: Identify activity risks

Step 6.1: Identify and quantify activity-based risks

Risks inherent in the overall nature of the project have already been considered in Step 3.
We now want to look at each activity in turn and assess the risks to its successful outcome. Any plan is always
based on certain assumptions. Say the design of a component is planned to take five days. This is based on the
assumption that the client’s requirement is clear and unambiguous. If it is not then additional effort to clarify
the requirement would be needed.

The possibility that an assumption upon which a plan is based is incorrect constitutes a
risk. In this example, one way of expressing the uncertainty would be to express the estimate of effort as
arrange of values.

A project plan will be based on a huge number of assumptions, and so some way of
picking out the risks that are most important is needed. The damage that each risk could cause and the
likelihood of it occurring have to be gauged. This assessment can draw attention to the most serious risks. The
usual effect if a problem materializes is to make the task longer or more costly.

Step 6.2: Plan risk reduction and contingency measures where appropriate

It may be possible to avoid or at least reduce some of the identified risks. On the other hand,
contingency plans specify action that is to be taken if a risk materializes. For example, a contingency plan could
be to use contract staff if a member of the project team is unavailable at a key time because of serious illness.

Step 6.3: Adjust overall plans and estimates to take account of risks

We may change our plans, perhaps by adding new activities which reduce risks. For example, a
new programming language might mean we schedule training courses and time for the programmers to practice
their new programming skills on some non-essential work.

Step 7: Allocate resources

Step 7.1: Identify and allocate resources

The type of staff needed for each activity is recorded. The staffs available for the project are
identified and are provisionally allocated to tasks.

Step 7.2: Revise plans and estimates to take into account resource constraints
 Some staff may be needed for more than one task at the same time and, in this case, an order
of priority is established. The decisions made here may have an effect on the overall duration
of the project when some tasks are delayed while waiting for staff to become free. Ensuring someone isavailabl
e to start work on an activity as soon as the preceding activities have been completed might mean that they are
idle while waiting for the job to start and are therefore used inefficiently.
The product of Steps 7.1 and 7.2 would typically be a Gantt chart – see Figure 1.9. The Gantt chart gives a clear
picture of when activities will actually take place and highlights which ones will be executed at the same time.
Activity networks can be misleading in this respect.

Fig 1.9 Gantt chart showing when staff will be carrying out tasks

Step 8: Review/publicize plan

Step 8.1: Review quality aspects of the project plan

A danger when controlling any project is that an activity can reveal that an earlier activity was not properly
completed and needs to be reworked. This, at a stroke, can transform a project that appears to be progressing
satisfactorily into one that is badly out of control. It is important to know that when a task is reported as
completed, it really is – hence the importance of quality reviews. Each task should have quality criteria. These
are quality checks that have to be passed before the activity can be ‘signed off’ as completed.
Step 8.2: Document plans and obtain agreement

It is important that the plans be carefully documented and that all the parties to the project
understand and agree to the commitments required of them in the plan. This may sound obvious, but it is
amazing how often this is not done.

Steps 9 and 10: Execute plan/lower levels of planning

Once the project is under way, plans will need to be drawn up in greater detail for each activity
as it becomes due. Detailed planning of the later stages will need to be delayed because more information will
be available nearer the start of the stage. Of course, it is necessary to make provisional plans for the more
distant tasks, because thinking about what needs to be done can help unearth potential problems, but sight
should not be lost of the fact that these plans are provisional.

Conclusion
This chapter has presented a framework into which the techniques described in the other parts of
the book should slot. It is suggested that any planning approach should have the following elements:-
 the establishment of project objectives;
 the analysis of the characteristics of the project;
 the establishment of an infrastructure consisting of an appropriate organization and set of standards,
methods and tools;
 the identification of the products of the project and the activities needed to generate those products;
 the allocation of resources to activities;
 the establishment of quality controls.
Project planning is an iterative process. As the time approaches for particular activities to be
carried out they should be replanned in more detail.
TOTAL QUALITY MANAGEMENT

What is TQM? (2m)

Explain the concepts of TQM briefly. (13 m)
 TQM can be defined as a management technique for improving processes, products, services and the other
approaches associated with the product. It focuses on the entire business and NOT just on a particular
project or process.
Elements of TQM:
 Root Cause Analysis
 Customer-focused
 Active Employee Participation
 Process-oriented
 Internal and External self Assessment
 Continuous improvement
 Making Well Informed Decisions
 Effective Communication
Quality Control Tools:
 Cause - Effect Diagram
 Checklists
 Histogram
 Graphs
 Pareto Charts
 Tree Diagram
 Arrow Diagram
Process Improvement Cycle:

Six Sigma
What is Six Sigma? (2m)
 Six Sigma is the process of producing high and improved quality output. This can be done in two phases –
identification and elimination. The cause of defects is identified and appropriate elimination is done which
reduces variation in whole processes. A six sigma method is one in which 99.99966% of all the products to
be produced have the same features and are of free from defects.

Mention the characteristics of Six Sigma? (13 m)

Characteristics of Six Sigma:
The Characteristics of Six Sigma are as follows:
1. Statistical Quality Control:
Six Sigma is derived from the Greek Letter ? Which denote Standard Deviation in statistics. Standard
Deviation is used for measuring the quality of output.
2. Methodical Approach:
The Six Sigma is a systematic approach of application in DMAIC and DMADV which can be used to
improve the quality of production. DMAIC means for Design-Measure- Analyze-Improve-Control. While
DMADV stands for Design-Measure-Analyze-Design-Verify.
3. Fact and Data-Based Approach:
The statistical and methodical method shows the scientific basis of the technique.
4. Project and Objective-Based Focus:
The Six Sigma process is implemented to focus on the requirements and conditions.
5. Customer Focus:
The customer focus is fundamental to the Six Sigma approach. The quality improvement and control
standards are based on specific customer requirements.
6. Teamwork Approach to Quality Management:
The Six Sigma process requires organizations to get organized for improving quality.

What is DMAIC and DMADV? (2m)

Six Sigma Methodologies:
Two methodologies used in the Six Sigma projects are DMAIC and DMADV.
 DMAIC is used to enhance an existing business process. The DMAIC project methodology has five phases:
1. Define
2. Measure
3. Analyze
4. Improve
5. Control
 DMADV is used to create new product designs or process designs. The DMADV project methodology also
has five phases:
1. Define
2. Measure
3. Analyze
4. Design
5. Verify
SOFTWARE QUALITY

Discuss on software quality in detail. (15 m)

 Software quality product is defined in term of its fitness of purpose. That is, a quality product does precisely
what the users want it to do. For software products, the fitness of use is generally explained in terms of
satisfaction of the requirements laid down in the SRS document. Although "fitness of purpose" is a
satisfactory interpretation of quality for many devices such as a car, a table fan, a grinding machine, etc.for
software products, "fitness of purpose" is not a wholly satisfactory definition of quality.
 Example: Consider a functionally correct software product. That is, it performs all tasks as specified in the
SRS document. But, has an almost unusable user interface. Even though it may be functionally right, we
cannot consider it to be a quality product.
 The modern view of a quality associated with a software product several quality methods such as the
following:
 Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.
 Usability: A software product has better usability if various categories of users can easily invoke the
functions of the product.
 Reusability: A software product has excellent reusability if different modules of the product can
quickly be reused to develop new products.
 Correctness: A software product is correct if various requirements as specified in the SRS document
have been correctly implemented.
 Maintainability: A software product is maintainable if bugs can be easily corrected as and when they
show up, new tasks can be easily added to the product, and the functionalities of the product can be
easily modified, etc.

Defining software quality

 Functional requirements define what the system is to do, the resource requirements specify allowable costs
and the quality requirements state how well this system is to operate.
 Some qualities of a software product reflect the external view of software held by users, as in the case of
usability. These external qualities have to be mapped to internal factors of which the developers would be
aware. It could be argued, for example, that well-structured code is likely to have fewer errors and thus
improve reliability.
 when there is concern about the need for a specific quality characteristic in a software product then a quality
specification with the following minimum details should be drafted:
 definition/description: definition of the quality characteristic;
 scale: the unit of measurement;
 test: the practical test of the extent to which the attribute quality exists;
 minimally acceptable: the worst value which might be acceptable if other characteristics
compensated for it, and below which the product would have to be rejected out of hand;
 target range: the range of values within which it is planned the quality measurement value should
lie;
 now: the value that applies currently.
 There could be several measurements applicable to a quality characteristic. For example, in the case of
reliability, this might be measured in terms of:
 availability: the percentage of a particular time interval that a system is usable;
 mean time between failures: the total service time divided by the number of failures;
 failure on demand: the probability that a system will not be available at the time required or the
probability that a transaction will fail;
 support activity: the number Of fault reports that are generated and processed.

ISO 9126
Write short notes on ISO 9126 standard? (15 m)
What are the categories of quality model? Explain it. (13 m)
 ISO 9126 is an international standard proposed to make sure ‘quality of all software – intensive
products’ which includes system like safety-critical where in case of failure of of software lives will be
jeopardy. ISO i.e. International Standard Organization and IEC i.e. International Electrical Organization
have developed ISO/IEC 9126 standards for software engineering –> Product Quality to provide an all-
inclusive specification and evaluation model for the quality of the software product.
 The standard is divided into 4 parts as depicted in the following figure :
Part-1 Software Engineering – Product Quality “Quality model” :
It describes quality model framework which explains relationships between different approaches to quality as
well as identifying quality characteristics and sub-characteristics of software products.
Part-2 Software Engineering – Product Quality “External Metrices” :
It’s use is to describes external metrices that are used to measure characteristics and sub-characteristics which
are identifies in part 1.
Part-3 Software Engineering – Product Quality “Internal Metrices” :
It’s use is to describes internal metrices that are used to measure characteristics and sub-characteristics which
are identifies in part 1.
Part-3 Software Engineering – Product Quality “Quality in use metrices” :
It’s use is to identify metrices which are used to measure effects of combined quality characteristics for user.
As from above discussion, it is concluded that first three parts are concerned with describing and measuring
quality of software product and fourth part concerned about quality of software product from user point of
view.
 Furthermore, first part i.e. Quality model is concerned classified into two categories as depicted in the
following figure :

 Internal External Quality Part: It determines the quality of a software product through six
characteristics which are Functionality, Reliability, Usability, Efficiency, Maintainability and Portability.
Each characteristic is subdivided into related sub-characteristics which are also depicted in the above
example.
1. Functionality: The functions are those that will satisfy implied needs.
 Suitability
 Accuracy
 Interoperability
 Security
 Functionality Compliance
2. Reliability: A set of attributes that will bear on the capability of software to maintain the level of
performance.
  Maturity
 Fault Tolerance
 Recoverability
 Reliability Compliance
3. Usability: A set of attributes that bear on the effort needed for use by a implied set of users.
 Understandability
 Learn ability
 Operability
 Attractiveness
 Usability Compliance
4. Efficiency: A set of attributes that bear on the relationship between the level of performance of the
software under stated conditions.
 Time Behavior
 Resource Utilization
 Efficiency Compliance
5. Maintainability: A set of attributes that bear on the effort needed to make specified modifications.
 Analyzability
 Changeability
 Stability
 Testability
 Maintainability Compliance
6. Portability: A set of attributes that bear on the ability of software to be transferred from one environment
to another.
 Adaptability
 Install ability
 Co-existence
 Replace ability
 Portability Compliance

****************UNIT I COMPLETED*******************

Referred In: Bob Hughes & Mike Cotterell “ Software Project Management”, fifth edition.
Gobalswamy ramesh, “Managing Global Software Projects”, 2003
www.w3schools.com
Wikipedia

UNIT II
SOFTWARE EVALUATION AND COSTING
Project Evaluation
Strategic Assessment–Technical Assessment–Cost Benefit Analysis–Cash Flow
Forecasting–Cost Benefit Evaluation Techniques–Risk Evaluation.

What is mean by project evaluation? (2M)

What are the benefits of project evaluation?(2 M)
What is Evaluation? (2M)
 Evaluation is a process that critically examines a program. It involves collecting and analyzing information
about a program’s activities, characteristics and outcomes. Its purpose is to make judgments about a
program, to improve its effectiveness and to inform programming decisions.
Project Evaluation:
 A high level assessment of the project
 to see whether it is worthwhile to proceed with the project
  to see whether the project will fit in the strategic planning of the whole organization
Project Evaluation
Why
 Want to decide whether a project can proceed before it is too late
 Want to decide which of the several alternative projects has a better success rate, a higher turnover, a higher
Is it desirable to carry out the development and operation of the software system
Who
 Senior management
 Project manager/coordinator
 Team leader
When
 Usually at the beginning of the project
e.g. Step 0 of Step Wise Framework
What
 Strategic assessment
 Technical assessment
 Economic assessment
How
 Cost-benefit analysis
 Cash flow forecasting
 Cost-benefit evaluation techniques
 Risk analysis
Strategic Assessment
What is strategic assessment? (2M)
 Used to assess whether a project fits in the long-term goal of the organization
 Usually carried out by senior management
 Needs a strategic plan that clearly defines the objectives of the organization
 Evaluates individual projects against the strategic plan or the overall business objectives
Programme management
Suitable for projects developed for use in the organization
Portfolio management
Suitable for project developed for other companies by software houses
SA – Programme Management
Individual projects as components of a program me within the organization
Program me as “a group of projects that are managed in a coordinated way to gain benefits that would not be
possible were the projects to be managed independently.
1. SA – Programme Management Issues
 Objectives
 How does the project contribute to the long-term goal of the organization?
 Will the product increase the market share? By how much?
 IS plan
 Does the product fit into the overall IS plan?
 How does the product relate to other existing systems?
 Organization structure
 How does the product affect the existing organizational structure? the existing workflow? the overall
business model?
 MIS
 What information does the product provide?
 To whom is the information provided?
 How does the product relate to other existing MISs?
 Personnel
 What are the staff implications?
 What are the impacts on the overall policy on staff development?
 Image
  How does the product affect the image of the organization?
2. SA – Portfolio Management
What is portfolio management? (2M)
 Suitable for product developed by a software company for an organization
 may need to assess the product for the client organization
 Programme management issues apply
 need to carry out strategic assessment for the providing software company
 Long-term goal of the software company
 The effects of the project on the portfolio of the company (synergies and conflicts)
 Any added-value to the overall portfolio of the company
Technical Assessment
 Functionality against hardware and software
 The strategic IS plan of the organization
 any constraints imposed by the IS plan

1. Economic Assessment
Why?
 Consider whether the project is the best among other options
 Prioritize the projects so that the resources can be allocated effectively if several projects are underway
How?
 Cost-benefit analysis
 Cash flow forecasting
 Various cost-benefit evaluation techniques
NPV and IRR
Cost Benefit Analysis
Explain the cost benefit analysis (13 M)
 The most common way of carrying out an economic assessment of a proposed information system or
software product, is by comparing the expected costs of development and operation of the system with the
benefits of having it in place.
 The standard way of evaluating the economic benefits of any project is cost-benefit analysis, comprising of
two steps. The steps are listed below:
o Step 1: Identifying and estimating all of the costs and benefits of carrying out the project and
operating the delivered application:
 These include the development costs, the operating costs and the benefits that are expected to accrue from
the new system. Where the proposed system is replacing an existing one, these estimates should reflect the
change in costs and benefits due to the new system.
o Step 2: Expressing these costs and benefits in common units:
 The net benefit hat is the difference between the total benefit and the total cost of creating and operating the
system need to be evaluated. To do this, we must express each cost and each benefit in some common unit.
Cash Flow Forecasting
 As important as estimating the overall costs and benefits of a project is the forecasting of the cash flows that
will take place and their timing.
 A cash flow forecast will indicate when expenditure and income will take place. Money has to be spend for
expenses such as staff wages, during the development stages of a project.
 Such expenditure cannot be deferred until income is received either from using the software if it is being
developed for in-house use or from selling it.
 When estimating future cash flows, it is usual to ignore the effects of inflation. Forecasts of inflation rates
tend to be uncertain.
 Moreover, if expenditure is increased due to inflation it is likely that income will increase proportionately
 The cash flow forecast for four projects is illustrated in Table. Negative values represent expenditure and
positive values represent income.
 In each case it is assumed that the cash flows take place at the end of each year. For short-term projects or
where there are significant seasonal cash flow patterns, quarterly, or even monthly, cash flow forecasts could
be appropriate.
 Typically products generate a negative cash flow during their development followed by a positive cash flow
over their operating life. There might be decommissioning costs at the end of a product’s life.
 Table : Four Project Cash Flow Projections – Figures and End of Year Totals (Rs.)

 Cash flows take place at the end of each year. The year 0 figure represents the initial investment made at the
start of the project.
Cost-Benefit Evaluation-Techniques
Discuss about the cost benefit evaluation techniques.(15 M)
What is cost benefit analysis? In context to cost benefit analysis, define the following term precisely.
(13 M)
1. Net Profit (NP)
2. Payback Period (PP)
3. Return on Investment (ROI)
4. Net Present Value (NPV)
 Costs and benefits have to be expressed using the same scale to be comparable
 Usually expressed in payments at certain times (cash flow table)
 Payments at different points in time are not comparable based only on the amount
 Time of payment should be considered
Techniques
– Net profit
– Payback period
– Return on investment
– Net present value
– Internal rate of return
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., compare Projects 1 and 3)
 Not very useful other than for "back of envelope" evaluations
Payback Period
 Time taken to break even or pay back the initial investment.
 Pros
o Easy to calculate
o Gives some idea of cash flow impact
 Cons: Ignores overall profitability
 Not very useful by itself, but a good measure for cash flow impact
Return On Investment
 Also known as the accounting rate of return (ARR), Provides a way of comparing the net profitability to
the investment required.
 The common formula–>ROI = (average annual profit/total investment) X 100
  Pros: Easy to calculate
 Cons
o Does not consider the timing of payments
o Misleading: does not consider bank interest rates
 Not very useful other than for "back of envelope" evaluations
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
o r is the discount rate
o t is the number of years into the future that the cash flow occurs
o (1+r)^t is known as discount factor
 In the case of 10% rate and one year
o Discount factor = 1/(1+0.10) = 0.9091
 In the case of 10% rate and two years
o Discount factor = 1/(1.10 x 1.10) = 0.8294
 Pros
o Takes into account profitability
o Considers timing of payments
o Considers economic situation through discount rate
 Cons: Discount rate can be difficult to choose
 Standard measure to compare different options
Internal Rate of Return
 Internal rate of return (IRR) is the discount rate that would produce an NPV of 0 for the project
 Can be used to compare different investment opportunities
 There is a Microsoft Excel function to calculate IRR
 Pros: Calculates figure which is easily comparable to interest rates
 Cons: Difficult to calculate (iterative)
 Standard way to compare projects

RISK EVALUATION
Write short notes on risk evaluation in project evaluation.(15 M)
What is risk? Explain risk evaluation in detail.(13 M)
Definition of Risk
 A risk is a potential problem – it might happen and it might not
Conceptual definition of risk
 Risk concerns future happenings
 Risk involves change in mind, opinion, actions, places, etc.
 Risk involves choice and the uncertainty that choice entails
Two characteristics of risk
 Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are called
constraints)
 Loss – the risk becomes a reality and unwanted consequences or losses occur
Risk Categorization – Approach
 Project risks
 They threaten the project plan
 If they become real, it is likely that the project schedule will slip and that costs will increase
 Technical risks
 They threaten the quality and timeliness of the software to be produced
 If they become real, implementation may become difficult or impossible
 Business risks
 They threaten the viability of the software to be built
 If they become real, they jeopardize the project or the product
Sub-categories of Business risks
 Market risk – building an excellent product or system that no one really wants
 Strategic risk – building a product that no longer fits into the overall business strategy for the
company
 Sales risk – building a product that the sales force doesn't understand how to sell
 Management risk – losing the support of senior management due to a change in focus or a change in
people
 Budget risk – losing budgetary or personnel commitment
 Known risks
 Those risks that can be uncovered after careful evaluation of the project plan, the business and
technical environment in which the project is being developed, and other reliable information
sources (e.g., unrealistic delivery date)
 Predictable risks
 Those risks that are extrapolated from past project experience (e.g., past turnover)
 Unpredictable risks
 Those risks that can and do occur, but are extremely difficult to identify in advance

Risk Identification and Ranking

 In any project evaluation we should attempt to identify the risk and quantify their potential effects. One
common approach to risk analysis is to construct a project risk matrix utilizing a checklist of possible
risks and to classify each risk according to its relative importance and likelihood.

In-House
 Developing a new IT application in-house:
 Time is needed to develop the software
 Would often require the recruitment of new technical staff to do the job
 Usually, the new staff won’t be needed after the project is completed
 Sometimes due to the novelty of the project there may be lack of executives to lead the effort
Outsourcing
 Contracting the project out to an external IT development company (outsourcing):
 Time is needed to develop the software
 The conducting company will have technical and project expertise not readily available to the client
 The client would still do management effort to establish and manage the contracts

SELECTION OF APPROPRIATE PROJECT APPROACH

Introduction
 The development of software in-house usually means that:
 the developers and the users belong to the same organization
 the application will slot into a portfolio of existing computer-based system
 the methodologies and technologies are largely dictated by organizational standards and policies,
including the existing enterprise architecture
CHOOSING TECHNOLOGIES
 Project analysis should select the most appropriate methodologies and technologies for a project.
 Methodologies include approaches like the unified Software Development Process (USDP), Structured
Systems Analysis and Design Method(SSADM) and Human-Centered Design, while technologies might
 include appropriate application-building and automated testing environments. The analysis identifies the
methodology, but also selects the methods within the methodology that are to be deployed.
 As well as the products and activities, the chosen methods and technologies will affect:
 the training requirements for development staff;
 the types of staff to be recruited:
 the development environment - both hardware and software;
 System maintenance arrangements.
CHOICE OF PROCESS MODEL

Software Process and Process Models

 A Software product development process usually starts when a request for the product is received from
the customer.
Starting from the inception stage:
 A product undergoes a series of transformations through a few identifiable stages
 Until it is fully developed and released to the customer.
After release:
 The product is used by the customer and during this time the product needs to be maintained for
fixing bugs and enhancing functionalities. This stage is called Maintenance stage.
 This set of identifiable stages through which a product transits from inception to retirement form the life
cycle of the product.
 Life cycle model (also called a process model) is a graphical or textual representation of its life cycle.

Choice of Process Models

 The no. of inter related activities to create a final product can be organized in different ways and we can
call these Process Models.
 A software process model is a simplified representation of a software process. Each model represents a
process from a specific perspective. These generic models are abstractions of the process that can be
used to explain different approaches to the software development.
Any software process must include the following four activities:
1. Software specification (or requirements engineering): Define the main functionalities of the software
and the constrains around them.
2. Software design and implementation: The software is to be designed and programmed.
3. Software verification and validation: The software must conforms to it’s specification and meets the
customer needs.
4. Software evolution (software maintenance): The software is being modified to meet customer and market
requirements changes.
The various Process Models are
1) Waterfall model
2) V-Process model
3) Spiral model
4) Prototype model
5) Increment model
6) Iterative development model

Waterfall model

 The waterfall model is a sequential approach, where each fundamental activity of a process represented
as a separate phase, arranged in linear order.
 In the waterfall model, you must plan and schedule all of the activities before starting working on them
(plan-driven process).
 Plan-driven process is a process where all the activities are planned first, and the progress is measured
against the plan. While the agile process, planning is incremental and it’s easier to change the process to
reflect requirement changes.
  The phases of the waterfall model are:
 Requirements
 Design
 Implementation
 Testing
 Maintenance
 Classical model of system development.
 Called one-shot or once-through model.
 Limited scope of iteration. Is this strength or a limitation??
 This is strength for the WF-model.
 Because it is suitable for some projects especially for large projects, we want to avoid reworking tasks
that are thought to be completed.
 Reworking tasks could result in late delivery.
 Suitable for systems with well defined requirements.
 Not suitable for systems of high uncertainty

V-Process model

 An extension of the waterfall model.

 V-process model expands the activity box “testing” in the waterfall model.
 Each step has a matching validation process.
 Validation process can cause a Loop back to the corresponding stage and reworking the following steps
in case of discrepancy
Spiral model

 The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The
spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.
 A software project repeatedly passes through these phases in iterations (called Spirals in this model).
 The baseline spiral, starting in the planning phase, requirements is gathered and risk is assessed.
 Each subsequent spiral builds on the baseline spiral. It is one of the software development models like
Waterfall, Agile, V-Model.
 A greater level of detail is considered at each stage of the project.
 Represented as a loop or a spiral where the system is considered in more detail.
 This means greater confidence about the probability of success.
 Each sweep is terminated by an evaluation before the next iteration is embarked upon.
 Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is
‘Bussiness
Requirement
Specifications’ and
‘SRS’ that is ‘System
Requirement
specifications’.
 Risk Analysis: In the
risk analysis phase,
a process is
undertaken to
identify risk and
alternate solutions. A
prototype is produced
at the end of the risk
analysis phase. If any
risk is found during
the risk analysis then
alternate solutions are suggested and implemented.
 Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.
 Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.
Advantages of Spiral model:
 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
Prototype model
 Prototype is a working model of one or more aspects of the projected system.
Goal:
 Gain knowledge
 reduce risk and uncertainty
 verify a design or implementation approach
 The prototype is constructed and tested, quickly and in expensively to test assumptions.

Classification of a prototype
Throw-away prototype:
 Tests out some ideas.
 Discarded when the true development of the operational system is started.
 The prototype could be developed using a different SW and HW environment than those that will be
used for the final system.
 Example: user interface
Prototype
Use a desktop application builder to produce an acceptable user interface.
Final system
Use a procedural programming language

Evolutionary prototypes
 The prototype is developed and modified until it is finally in a state where it can become the operational
system.

Benefits of prototyping:
 Learning by doing.
 Improved communication.
 Improved user involvement.
 Clarification of partially-known requirements.
 Demonstration of the consistency and completeness of a
 Specification
  Reduced need for documentation.
 Reduced maintenance costs.
 Feature constraint

Drawbacks of prototyping:
 Users sometimes misunderstand the role of the prototype.
 Lack of project standards possible.
 Lack of control.
 Additional expense.
 Machine efficiency.
 Close proximity of developers.

Prototypes at different stages

 Different projects will have uncertainties at different stages.
 Thus, prototypes can be used at different stages.
Examples:
 At the requirements gathering stage: to pin down requirements that seem blurred and shifting.
 At the design stage: to test out the user's ability to navigate through a sequence of input screens.

To what extent is the prototyping done? (2 M)

 The prototyping usually simulates only some aspects of the target application, thus there might be:
 Mock-ups
 e.g. Copies of input screens shown to the users on a terminal.
 They can’t actually be used.
 Simulated interaction
 A user can type in a request to see a record in a database and an example of a result is shown.
 There is no real access is made to the database.

Forms of prototyping
Partial working model
 Vertical: only some features are fully prototyped
 Horizontal: all featured are prototyped but not in detail

Incremental model
 Break the system into small components.
 Implement and deliver small components in sequence.
 Every delivered component provides extra functionality to the user.
 Deliver full system in the beginning.

 Enhance existing functionality in new releases.

  Every new release includes:
 Extra functionality.
 Enhancement of existing functionality.
 Popularly used in software industry.

*******UNIT – II COMPLETED *********

References :

1. Bob Hughes & Mike Cotterell, “Software project management”, Tata McGraw-Hill Publications, Fifth
Edition 2012
2. S.A. Kelkar, “Software project management”, PHI, new Delhi, Third Edition, 2013
3. Www.wikipedia.org

UNIT - III

SOFTWARE ESTIMATION TECHNIQUES

SOFTWARE EFFORT ESTIMATION
Introduction
 A successful project is one delivered 'on time and within budget and with the required quality'. This
implies that targets are set and the project leader then tries to meet.

Estimation is the process of finding an estimate or approximation, which is a valve that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable.

 Estimation determines how much money, effort, resources and time it will take to build a specific
system or product.
 This assumes that the targets are reasonable - the possibility of a project leaders achieving record levels
of productivity from the team, but still not meeting a deadline because of incorrect initial estimates is
not recognized.
 Estimating the effort required to implement software is notoriously difficult. Some of the difficulties of
estimating are inherent in the very nature of software, especially its complexity and invisibility.
 In addition the intensely human activities that make up system development cannot be treated in a
purely mechanistic way.
 Other difficulties include:
 Subjective nature of estimating
 Political implications
 Changing technology
 Lack of homogeneity of project experience.
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
Where are estimates done? (2M)
 Estimates are carried out at various stages of a software project for various reasons.
 Strategic planning
 Feasibility study
 System specification
 Evaluation of suppliers' proposals
 Project planning

PROBLEMS WITH OVER AND UNDER ESTIMATION

What are problems will occur with over and under estimation? (13 m)
Define Parkinson's law / Brooks' law. (2m)
 An over-estimate might cause the project to take longer than it would otherwise. This can be explained
by the application of two 'laws'.
Parkinson's Law
 'Work expands to fill the time available', which implies that, is given an easy target staff will work less
hard.
Brooks' Law
 The effort required to implement a project will go up disproportionately with the number of staff
assigned to the project. As the project team grows in size so will the effort that has to go into
management, co-ordination and communication.
 This has given rise, in extreme cases, to the notion of Brooks' Law: 'putting more people on a late job
makes it later'. If there is an over-estimate of the effort required then this might lead to more staff being
allocated.

BASIS OF SOFTWARE ESTIMATION

Define the term person-month (2m)
Mention the parameters needed to estimate software. (2m)
What is the meaning of 'project size'? (2m)
The need for historical data
 Nearly all estimating methods need information about how projects have been implemented in the past.
However, care needs to be taken in judging the applicability of data to the estimator's own
circumstance,: because of possible differences in factors such as the programming languages used, the
software tools available, the standards enforced and the experience of the staff.
Parameters to be estimated
 The project manager needs to estimate two project parameters for carrying out project planning. They
are effort and duration.
 Duration measured in months. Work-month (wm) is a popular unit for measurement.
 The term person-month (pm) is also frequently used to mean the same as work-month.
 One person-month is the effort an individual can typically put in a month.
 The person-month estimate implicitly takes into account the productivity losses that normally occur due
to time lost in holidays, weekly offs, coffee breaks etc.,
Measure of work
 Measure of work involved in completing a project is also called the size of the project.
 Impossible to calculate directly the actual cost or time required to implement a project. The time taken
to write a program might vary according to the competence or experience of the programmer.
Implementation times might also vary of factors such as the software tools available. The usual practice
is therefore to express the work content of the system to be implemented independently of effort, using a
measure such as source lines of code.
 The size of the project is obviously not the number of bytes that the source code occupies, neither is it
the size of the executable code.
 It is a measure of the problem complexity in terms of the effort and time required to develop the
product.
 There are two metrics to measure size: i) Source Lines of Code(SLOC) ii) Function Point(FP).
  Disadvantages of SLOC are:-
 No precise definition
 Difficult to estimate at start of a project
 Only a code measure
 Programmer-dependent
 Does not consider code complexity
Complexity:
 Two programs with the same' KLOC will not necessarily take the same time to write, even if done by
the same developer in the same environment, One program might be more complex

SOFTWARE ESTIMATION TECHNIQUES

Mention the various software effort models to estimate software? (13 m)
Describe Bottom-up Estimation. (15 m)
Write short notes on Top-Down Approach? (13 m)
 Barry Boehm, in his classic work on software effort models, identified the main ways of deriving
estimates of software development effort as:
1) Algorithmic models
Which use 'effort drivers' representing characteristics of the target system and the
implementation environment to predict effort.
2) Expert judgment
Where the advice of knowledgeable staff is solicited:
3) Analogy
Here a similar, completed, project is identified and its actual effort is used as a basis for
the new project;
4) Parkinson
Which identities the staff effort available to do a project and uses that as the 'estimate';
5) Price to win
Where the 'estimate' is at figure that appears to be sufficiently low to win a contract:
6) Top-down
Where an overall estimate is formulated for the whole project and is then broken down
into the effort required for component tasks:
7) Bottom-up
Where component tasks are identified and sited and these individual estimates are
aggregated.
Bottom-up estimating
 With the Bottom-up approach, the estimator breaks the project into its component tasks and then
estimates how much effort will be required to carry out each task.
 With a large project, the process of breaking down into tasks would be a repetitive one: each task would
be analyzed into its component sub-tasks and these in turn would be further analyzed.
 The bottom-up part comes in adding up the calculated effort for each activity to get an overall estimate.
A procedural code-oriented approach
 The bottom-up approach described above works at the levels of activities.
 In software development a major activity is writing code.
 The software components used at each levels are:-
 Envisage the number and type of software modules in the final system
 Estimate the SLOC of each identified module
 Estimate the work content, taking into account complexity and technical difficulty
 Calculate the work-days effort
The top-down approach and parametric models
What are the two key components for the forecast of software development effort? (2m)
 The top-down approach is normally associated with parametric models. The effort needed to implement
a project will be related mainly to variables associated with characteristics of the final system. The form
of the parametric model will normally be one or more formulae in the form
effort = (system size) x (productivity rate)
 A model to forecast software development effort therefore has two key components. The first is a
method of assessing the size of the software development task to be undertaken. The second assesses the
 rate of work at which the task can be done. Some parametric models such as that implied by function
points, are focused on system or task size, while others, such are COCOMO, are more concerned with
productivity factors.

EXPERT JUDGMENT
What is the mean by expert judgment? (2m)
 This is asking someone who is knowledgeable about either the application area or the development
environment to give an estimate of the effort needed to carry out a task.
 This method will most likely be used when estimating the effort needed to change an existing piece of
software.
 The estimator would have to carry out some kind of impact analysis in order to judge the proportion of
code that would be affected and from that derives an estimate. Someone already familiar with the
software would be in the best position to do this.

ESTIMATING BY ANALOGY
How to estimate Software project effort using analogies. (13m)
 The use of analogy is also called case-based reasoning.
 The estimator seeks out projects that have been completed and that have similar characteristics to the
new project. The effort that has been recorded for the matching source case can then be used as a base
estimate for the target.
 The estimator should then try to identify any differences between the target and the source and make
adjustments to the base estimate for the new project.
 A problem here is how you actually identify the similarities and differences between the different
systems.
 Attempts have been made to automate this process.
 One software application that has been developed to do this is ANGEL.
 This identifies the source case that is nearest the target by measuring the Euclidean distance between
cases.
 The source case that is at the shortest Euclidean distance from the target is deemed to be the closest
match.
 The Euclidean distance is calculated:
Euclidean distance = square-root of (target_parameter1, Source_parameter1)2 + +
(target_parametern, Source_parametern) …
Function Point Analysis
 The basis of function point analysis is that computer-based information systems comprise five major
components, or external users type that are of benefit to the users:
1) External input types are input transactions that update internal computer tiles.
2) External output types are transactions where data is output to the user. Typically these would he
printed reports, since screen displays would come under external inquiry types
3) Logical internal tile types are the standing files used by the system. The term 'file does not sit
easily with modern information systems. It refers to a group of data that is usually accessed
together. It might be made up of one or more record types.
4) External interface file types allow for output and input that might pass to and from other
computer applications. Files shared among applications would also be counted here.
5) External inquiry types - note the US spelling of inquiry - are transactions initiated by the user
that provide information but do not update the internal tiles. The user inputs some information
that directs the system to the details required
 The analyst has to identify each instance of each external user type in the projected system. Each
component is then classified as having high, average or low complexity. The counts of each external
user type in each complexity hand arc multiplied by specified weights to get IT scores, which are
summed to obtain an overall FP count, which indicates the information processing size.
 Estimates are really management targets;
 Collect as much information about previous project as possible.
 Top-down approaches will be used at the earlier stages of project planning while bottom-up
approaches will be on later stages
 ACTIVITY PLANNING
What is activity planning? (2m)
What are the objectives of activity planning? (2m)
Introduction
 A detailed plan for the project includes a schedule indicating the start and completion times for each
activity.
 To be effective, a plan must be stated as a set of targets, the achievement or non-achievement of which
can be unambiguously measured. The activity plan does this by providing a target start and completion
date for each activity
 The starts and completions of activities must be clearly visible and this is one of the reasons why it is
advisable to ensure that each and every project activity produces some tangible product or ‘deliverable’.
The objectives of activity planning
 The objectives of activity planning is as follows:-
 Feasibility assessment
 Resource allocation
 Detailed costing
 Motivation providing
 Coordination
 Activity planning and scheduling techniques place an emphasis on completing the project in a minimum
time at an acceptable cost or, alternatively, meeting a set target date at minimum cost.
When to plan
 Planning is an ongoing process of refinement, each iteration becoming more detailed and more accurate
than the last. Over successive iterations, the emphasis and purpose of planning will shift.
 During the feasibility Study and project start-up, the main purpose of planning will be to estimate
timescales and the risks of not achieving target completion dates or keeping within budget. As the
project proceeds beyond the feasibility study, the emphasis will be placed upon the production of
activity plans for ensuring resource availability and cash flow control.

PROJECT SCHEDULES
How to schedule project? Explain it (13 m)
 Before work commences on a project or, possibly, 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. Creating a project
schedule comprises four main stages.
1) The first step in producing the plan is to decide what activities need to be carried out and in what
order they are to be done. From this we can construct an ideal activity plan that is, a plan of when
each activity would ideally be undertaken were resources not, a constraint. It is the creation of the
ideal activity plan.
2) The ideal activity plan will then be the subject of an activity risk analysis, aimed at identifying
potential problems. This might suggest alterations to the ideal activity plan and will almost certainly
have implications for resource allocation.
3) The third step is resource allocation. The expected availability of resources might place constraints
on when certain activities can be carried out, and our ideal plan might need to be adapted to take
account of this.
4) The final step is schedule production. Once resources have been allocated to each activity, we will
be in a position to draw up and publish a project schedule, which indicates planned start and
completion dates and a resource requirements statement for each activity.

PROJECTS AND ACTIVITIES

Write a detail on projects and various activities? (15 m)
Defining Activities
 A project is composed of a number of interrelated activities
 A project may start when at least one of its activities is ready to start
 A project will be completed when all of the activities it encompasses have been completed
  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 then that resource requirement must be forecastable and is assumed to be
required at a constant level throughout the duration of the activity
 The duration of an activity must be forecastable — assuming normal circumstances, and the reasonable
availability of resources.
 Some activities might require that others are completed before they can begin (these are known as
precedence requirements).
What are the three approaches of identifying the activities of project? Explain (13 m)
Identifying Activities
 Essentially there are three approaches to identifying the activities or tasks that make up a project. They
are:-
1. The activity-based approach
2. The product-based approach and
3. The hybrid approach
The Activity-based Approach
 The activity-based approach consists of creating a list of all the activities that the project is thought to
involve.
 This might involve a brainstorming session involving the whole project team or it might stem from an
analysis of similar past projects.
 When listing activities, particularly for a large project, it might be helpful to subdivide the project into
the main lifestyle stages and consider each of these separately.
 Rather than doing this in an ad hoc manner, a much favored way of generating a task list is to create a
Work Breakdown Structure (WBS).
 This involves identifying the main (or high- level) tasks required to complete a project and then
breaking each of these down into a set of lower-level tasks.
 Figure illustrates a fragment of a WBS where the design task has been broken down into three tasks and
one of these has been further decomposed into two tasks

 The advantages of the WBS approach include the belief that it is much more likely to result in a task
catalogue that is complete and is composed of non- overlapping activities

Write short notes on product-based approach? (15 m)

The Product-based Approach
 The product-based approach consists of producing a Product Breakdown Structure and a Product Flow
Diagram.
 The PFD indicates, for each product, which other products are required as inputs.
 The PFD can therefore be easily transformed into an ordered list of activities by identifying the
transformations that turn some products into others.
 Proponents of this approach claim that it is less likely that a product will be left out of a PBS than that
an activity might be omitted from an unstructured activity list.
 The SSADM Reference Manual also supplies generic activity networks and, using the project-specific
PBS and derived PFD, these may be used as a basis for developing a project-specific activity network.
Figure illustrates an activity network for the activities required to create the products
Write the key points on hybrid approach? (13 m)
The Hybrid Approach
 The WBS illustrated in Figure is based entirely on a structuring of activities.
 Alternatively, and perhaps more commonly, a WBS may be based upon the project’s products as
illustrated in Figure which is in turn based on a simple list of final deliverables and, for each deliverable,
a set of activities required to produce that product.
 The degree to which the structuring is product-based or activity-based might be influenced by the nature
of the project and the particular development method adopted.
 As with a purely activity-based WBS, having identified the activities we are then left with the task of
sequencing them.
 A framework dictating the number of levels and the nature of each level in the structure may be imposed
on a WBS. The following five levels should be used in a WBS:
 Level 1:
Project
 Level 2:
Deliverables such as software, manuals and training courses
 Level 3:
 Components which are the key work items needed to produce deliverables, such as the modules
and tests required to produce the system software
 Level 4:
Work-packages which are major work items, or collections of related tasks, required to produce
a component
 Level 5:
Tasks which are tasks that will normally be the responsibility of a single Person

 Throughout a project, we will require a schedule that clearly indicates when each of the project’s
activities is planned to occur and what resources it will need.
 One way of presenting such a plan is to use a bar chart as shown in Figure.
 The chart shown has been drawn up taking account of the nature of the development process (that is,
certain tasks must be completed before others may start) and the resources that are available (for
example, activity C follows activity B because Ani cannot work on both tasks at the same time).
 In drawing up the chart, we have therefore done two things, we have sequenced the tasks (that is,
identified the dependencies among activities dictated by the development process) and scheduled them
(that is, specified when they should take place).
SEQUENCING AND SCHEDULING ACTIVITIES
 The scheduling has had to take account of the availability of staff and the ways in which the activities
have been allocated to them.
 The schedule might look quite different were there a different number of staff or were we to allocate the
activities differently.
 In the case of small projects, this combined sequencing, scheduling approach might be quite suitable,
particularly where we wish to allocate individuals to particular tasks at an early planning stage.
 However, on larger projects it is better to separate out these two activities: to sequence the tasks
according to their logical relationships and then to schedule them taking into account resources and
other factors.
  Approaches to scheduling that achieve this separation between the logical and the physical use networks
to model the project.
NETWORK PLANNING MODELS
Describe about network planning models in detail? (13 m)
 These project scheduling techniques model the project’s activities and their relationships as a network.
 In the network, time flows from left to right. The best known techniques are CPM (Critical Path
Method) and PERT (Program Evaluation Review Technique).
 Both of these techniques used an activity-on-arrow approach to visualizing the project as a network
where activities are drawn as arrows joining circles, or nodes, which represent the possible start and/or
completion of an activity or set of activities.
 More recently a variation on these techniques, called precedence networks, has become popular.
 This method uses activity-on-node networks where activities are represented as nodes and the links
between nodes represent precedence (or sequencing) requirements.
 This latter approach avoids some of the problems inherent in the activity-on-arrow representation and
provides more scope for easily representing certain situations.
 It is this method that is adopted in the majority of computer applications currently available.
 These three methods are very similar and it must be admitted that many people use the same name
(particularly CPM) indiscriminately to refer to any or all of the methods.
FORMULATING A NETWORK MODEL
 The first stage in creating a network model is to represent the activities and their interrelationships as a
graph
Constructing Precedence Networks
Rules for constructing network models:
1) A project network should have only one start node
2) A project network should have only one end node
3) A node has duration
4) Links normally have no duration
5) Precedents are the immediate preceding activities
 6) Time moves from left to right

Fragment of a Precedence Network

A Loop Represents an Impossible Sequence

Dangle

Resolving the Dangle

Representing Lagged Activities
There may be situations where we wish to undertake two activities in parallel as there is a lag between the two.
Indicating Lags
Hammock Activities
 Hammock activities are activities which, in themselves, have zero duration but are assumed to start at
the same time as the first ‘hammocked’ activity and to end at the same time as the last one.
 They are normally used for representing overhead costs or other resources that will be incurred or used
at a constant rate over the duration of a set of activities.
Labeling Conventions:
 There are a number of differing conventions that have been adopted for entering information on an
activity-on-node network.
 One of the more common conventions for labeling nodes is illustrated in Figure

Commonly Used Labeling Convention

***** UNIT – III COMPLETED *****

___________________________________________________________________________

References:

1. Bob Hughes & Mike Cotterell, “Software project management”, Tata McGraw-Hill Publications, Fifth
Edition 2012
2. S.A. Kelkar, “Software project management”, PHI, new Delhi, Third Edition, 2013
3. Www.wikipedia.org
_________________________________________________________________________________
 UNIT - IV

RISK MANAGEMENT
Risk Management: Introduction
Define Risk.(2M)
What is Risk management?(2m)
What are the key elements of the risk? (2M)
 Risk is defined as 'an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project's objectives.
 The key elements of a risk follow
 It relates to the future
 It involves cause and effect
What are reactive and proactive risk strategies? (2M)
How are risk classified?(2m)
 Risk is the potential future harm that may arise from some present action”
 Management is a process that is used to minimize or eradicate risk before it can harm the productivity of
software.
 There are two risk strategies namely reactive strategies and proactive strategies.
 A reactive software engineer corrects a problem as it occurs, while a proactive software engineer starts
thinking about possible risks in a project before they occur.
 There are several types of risk that can occur during a software development project.
 The same is illustrated in table

NATURE OF RISK
 To identify and managing the risks which cause the project to overrun its time-scale or budget, there are
three types of risks:-
 those caused by the inherent difficulties of estimation --> Estimation errors
 those due to assumptions made during the planning process --> Planning assumptions
 those of unforeseen events occurring --> Eventualities
MANAGING RISK
How to manage the risks. Explain briefly (13 m)
 The objective of risk management is to avoid or minimize the adverse effects of unforeseen events by
avoiding the risks or drawing up contingency plans for dealing with them.
 There are number of models for risk management, but most are similar, in that they identify two main
components- risk identification and risk management.
 Risk identification: It consists of listing all of the risks that can adversely affect the successful
execution of the project.
 Risk Estimation: It consists of assessing the likelihood and impact of each hazard.
 Risk Evaluation: It consists of ranking the risk and determining risk aversion strategies.
 Risk planning: It consists of drawing up contingency plans and ,where appropriate, adding these
to the project's task structure. For smaller projects done by project manager and for large or
medium by risk manager.
  Risk control: It concerns the major function of risk manager in minimizing and reacting to
problems throughout the project.
 Risk Monitoring: It is an ongoing activity
 Risk directing and risk staffing: Concerned with the day-to-day management of risk. Risk
aversion and problem solving strategies involves the use of additional staffs and this must be
planned for and directed.

RISK IDENTIFICATION AND ANALYSIS

Define a brainstorming technique.(2m)
What is a hazard? List out the generic risks.(2m)
Describe about Risk Identification and Analysis.(15 m)
Risk Identification:
 The first stage in any risk assessment is to identify the hazards that might affect the duration or resource
cost of the project.
 A hazard is an event that might occur and will, if it does occur. Create a problem for the successful
completion of the project.
 The two main approaches to the identification of risks are the use of checklists and brainstorming.
 All stakeholders identified in the project are brought together to have a brainstorming session before
the project commences.
 These stakeholders identify the various features of the project and analyze the problems that can arise in
due course.
 The outcome of the discussions of these sessions is beneficial in view point of the development process
because almost all kinds of risks that the project will face are analyzed.
 Checklists are those risks that occur frequently in software development projects. These risks contain a
list of specialized software development risks that occur.
 Every stakeholder must undergo a through checking of this list and find out the kind of risk that can
happen in their projects.
 Project managers will have a separate list of risks solely associated with the software process. Any new
kind of risks that happens in any of the projects can be added on to the organizational risk list.
 Casual mapping can be represented as a cognitive map that describes the causes and effects that
influence the outcomes in the activity development. The outcome can be a negative or a positive
influence depends on the particular factor. For example, high staff turnover can be a positive factor but
unstable requirements have a negative impact.
 Casual maps usually represent people’s perspective towards the development of the project.
 Some of the factors might involves in risk identification are:-
o Application factors o Changeover factors
o Staff factors o Supplier factors
o Project factors o Environment factors
o Project methods o Health and safety factors
o Hardware/Software factors
Risk Analysis:
 The probability of a hazard’s occurring is known as the risk likelihood; the effect that the resulting
problem will have on the project, if it occurs, is known as the risk impact and the importance of the risk
is known as the risk value or risk exposure.
 Most frequent risks that occur, causes more damage to the process. Risk exposure for every risk has to
be calculated with the probability of occurrence.
 Risk exposure is defined by

Risk exposure = (value of damage) X (probability of occurrence)

 Here the potential damage is assessed the money value of the development process.
 Few risk exposure assessments are listed below:
o Requirement specification changes during coding phase
o Staffs inability to complete the task assigned affecting the critical activities.
o Specification process takes much longer than expected.
o Module testing produces errors of design phase.
 Managers try to produce very precise estimates of loss or they expect something to happen. It is the duty
of the managers to prioritize the risk and handle them giving due importance to its existence.
 The potential damage and the likelihood of risk are described by qualitative descriptors, depicts the
causes and the impact of the project are shown below:

 A probability impact grid or summary risk profiles are described in a matrix which indicates the position
of risk. The top right of the matrix denotes the tolerance line with serious risks levels.

REDUCING THE RISK

Write short notes on Software Project risks and strategies for risk reduction. (13 m)
 There are five Strategies for risk reduction
Hazard Prevention
 Some hazards can be prevented from occurring or their likelihood reduced to insignificant levels.
The risk of key staff being unavailable for meetings can be minimized by early scheduling.
Likelihood Reduction
 Some risks, while they cannot be prevented, can have their likelihoods reduced by prior
planning. The risk of late changes to a requirements specification can, for example, be reduced
by prototyping. Prototyping will not eliminate the risk of late changes and will need to be
supplemented by contingency planning.
Risk Avoidance
 A project can, for example, be protected from the risk of overrunning the schedule by increasing
duration estimates or reducing functionality.
Risk Transfer:
 The impact of some risks can be transferred away from the project by, for example, contracting
out or taking out insurance.
Contingency Planning:
 Some risks are not preventable and contingency plans will need to be drawn up to reduce the
impact should the hazard occur.
 Table: Software projects risks and strategies for risk reduction

RESOURCE ALLOCATION
What is a resource? (2m)
 The allocation of resources to activities will lead us to review and modify the ideal activity plan.
 It may cause us to revise stage or project completion dates. In any event, it is likely to lead to a
narrowing of the time-spans within which activities may be scheduled.
 The final result of resource allocation will normally be a number of schedules including:
 activity schedule indicating the planned start and completion dates for each activity;
 resource schedule showing the dates on which each resource will be required and the level of
that requirement
 cost schedule showing the planned cumulative expenditure incurred by the use of resources over
time
The nature of resources:
 A resource is any item or person required for the execution of the project.
 Categories of resources are:-
o Labour
o Equipment
o Materials
o Space
o Services
o Time
o Money
 SCHEDULING RESOURCES
What is scheduling? (2m)
How to schedule resources to the software project. Elaborate.(13 M)
 Having produced the resource requirements list, the next stage is to map this onto the activity plan to
assess the distribution of resources required over the duration of the project.
 This is best done by representing the activity plan as a bar chart and using this to produce a resource
histogram for each resource.
 Each activity has been scheduled to start at its earliest start date a sensible initial strategy, since we
would, other things being equal, wish to save any float to allow for contingencies.
 Earliest start date scheduling, as is the case with Amanda's project, frequently creates resource
histograms that start with a peak and then Mil off

 Changing the level of resources on a project over time, particularly personnel, generally adds to the cost of a
project. Recruiting staff has costs and even where staffs are transferred internally, time will be needed for
familiarization with the new project environment.

Of the various ways of prioritizing activities, two are described below.

What is free float?(2m)
Total float priority
 Activities are ordered according to their total float, those with the smallest total float having the highest
priority.
  In the simplest application of this method, activities are allocated resources in ascending order of total float.
 However, as scheduling proceeds, activities will be delayed and total floats will be reduced. It is
therefore desirable to recalculate floats each time an activity is delayed.

Ordered list priority

 With this method, activities that can proceed at the same time are ordered according to a set of simple
criteria.
 An example of this priority list, which takes into account activity duration as well as total float:
1) shortest critical activity
2) Critical activities
3) Shortest non-critical activity
4) Non-critical activity with least float,
5) Non-critical activities
CRITICAL PATHS
Define critical path(2m)
 Scheduling resources can create new critical paths. Delaying the start of an activity because of lack of
resources will cause that activity to become critical if this uses up its float.
 Furthermore, a delay in completing one activity can delay the availability of a resource required for a later
activity. If the later one is already critical then the earlier one might now have been made critical by
linking their resources.
 As a result of examining the progress information and comparing it against what was planned, some
remedial action might need to be taken.
 Instructions may be formulated and passed down to a lower level of management. The lower level
managers will have to interpret what needs to be done and formulate more detailed plans to fulfill the
directive. As the directives filter down the hierarchy, they will be expanded into more detail at each level.
Levels of decision making and information
 Each decision made in a project environment should be based on adequate information of the correct
sort. The type of information needed depends on the level of decision making. Decision, can he grouped
at three levels:
 strategic,
 tactical, and
 Operational.
 Strategic decision making is essentially about deciding objectives. In the case of the, the decision to
become administratively independent could be regarded a strategic decision. In our example we were
interested only in the payroll, but this might have been part of a wider programme which may have affected
many other administrative functions.
 Tactical decision making is needed to ensure that the objectives will be fulfilled. The project leader
who has the responsibility for achieving objectives will have to formulate a plan of action to meet those
objectives. The project leader will need to monitor progress to see whether these objective are likely to he
met and to take action where needed to ensure that the things remain on course.
 Operational decisions relate to the day-to-day work of implementing the project. Deciding the content
of the acceptance tents might come under this heading.
COST SCHEDULING
What is cost scheduling? (2m)
What are the categories of costs? (2m)
 Calculating cost is straightforward where organization has standard cost figures for staff and other
resources. Where this is not the case, then the project manager will have to calculate the costs.
 In general, costs are categorized as follows:-
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 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
  Overheads for 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.
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.
MONITORING AND CONTROL
Explain in detail about creating the framework for monitoring & control.(13 m)
 After the work schedules have been finalized and the project is under way, concentration must be
focused on ensuring progress.
 This requires monitoring of what is happening, comparison of actual achievement against the schedule
and, when necessary, revision of plans and schedules to bring the project as far as possible back on
target.
CREATING FRAMEWORK
 Exercising control over a project and ensuring that targets are met is a matter of regular monitoring,
finding out what is happening, and comparing it with current targets.
 If there is a mismatch between the planned outcomes and the actual one then either replanning is needed
to bring the project back on target or the target will have to be revised.
 A model of the project control cycle is illustrated in Figure

Figure: The Project Control Cycle

 It shows how, once the initial project plan has been published, project control a continual process of
monitoring progress against that plan and, where necessary revising the plan to take account of
deviations.
  It also illustrates the important steps that must be taken after completion of the project so that the
experience gained in anyone project can feed into the planning stages of future projects, thus allowing
us to learn from past mistakes.
 In practice we are normally concerned with departures from the plan in four dimensions delays in
meeting target dates, shortfalls in quality, inadequate functionality, and costs going over target

Responsibility:
 The overall responsibility for ensuring adequate progress on a project is often the role of the project-
steering committee or Project Board.
 Day-to-day responsibility will be with the project manager and, in all but the smallest of projects;
aspects of this can be delegated to team leaders.
Figure illustrates the typical reporting structure found with medium and large projects

 With small projects employing less number of staff individual team members usually report directly to
the project manager.
 But in most cases team leaders will collate reports on their section’s progress and forward summaries to
the project manager. These, in turn, will be incorporated into project-level reports for the steering
committee and, via them or directly, progress reports for the client.
Assessing the Progress
 Progress assessment will be made on the basis of information collected and collated at regular intervals
or when specific events occur.
 Wherever possible, this information will be objective and tangible - whether or not a particular report
has been delivered. Progress assessment will have to rely on the judgment of the team members who are
carrying out the project activities.
Table: Categories of Reporting
Setting Checkpoints
 A series of checkpoints in the initial activity plan need to be set. Checkpoints maybe:
 Regular (Daily, for example)
 Tied to specific events such as the production of a report or other deliverable

Taking Snapshots
 The frequency with which a manager needs to receive information about progress will depend upon the
size and degree of risk of the project or that part of the project under their control. Team leaders, for
example, need to assess progress daily whereas project managers may find weekly or monthly reporting
appropriate.
 In general, the higher the level, the less frequent and less detailed the reporting needs to be. A formal
weekly collection of information from staff carrying out activities is favored.
COST MONITORING
Write short notes on cost monitoring?(15m)
 Expenditure monitoring is a vital component of project control because it provides an indication of the
effort that has gone into a project.
 A project might be on time but only because more money has been spent on activities than originally
budgeted.
 A cumulative expenditure chart such as that shown in Figure provides a simple method of comparing
actual and planned expenditure. Figure illustrates a project that is running late or one that is on time but
has shown substantial costs savings.
 The current status of the project activities has to be taken into account before attempting to interpret the
meaning of recorded expenditure.
 Cost charts become useful if we add projected future costs calculated by adding the estimated costs of
uncompleted work to the costs already incurred. Where a computer based planning tool is used, revision
of cost schedules is generally provided automatically once actual expenditure has been recorded.

Figure: Tracking Cumulative Expenditure

  Figure illustrates the additional information available once the revised cost schedule is included. In this
case it is apparent that the project is behind schedule and over budget.

PRIORITIZING MONITORING
 The priority that must be applied in deciding the levels of monitoring is discussed below:
1) Critical path activities:
 Any delay in an activity on the critical path will cause a delay in the completion date for the
project. Critical path activities are therefore likely to (have a very high priority) for close
monitoring.
2) Activities with no free float:
 Free float is the amount of time an activity may be delayed without affecting any subsequent
activity.
 A delay in any activity with no free float will delay at least some subsequent activities even
though, if the delay is less than the total float, it might not delay the project completion date.
 These subsequent delays can have serious effects on our resource schedule as a delay in a
subsequent activity could mean that the resources for that activity will become unavailable
before that activity is completed because they are committed elsewhere.
3) Activities with less than a specified float:
 If any activity has very little float it might use up this float before the regular activity
monitoring brings the problem to the project manager’s attention.
 It is common practice to monitor closely those activities with less than one week free float.
4) High risk activities:
 A set of high-risk activities should have been identified as part of the initial risk profiling
exercise.
 If we are using the PERT three-estimate approach we will designate as high risk those
activities that have a high estimated duration variance.
 These activities will be given close attention because they are most likely to overrun or
overspend.
5) Activities using critical resources
 Activities can be critical because they are very expensive (as in the case of specialized
contract programmers). Staff or other resources might be available only for a limited period,
especially if they are controlled outside the project team.
 In any event, an activity that demands a critical resource requires a high level of monitoring

********UNIT – IV COMPLETED *********

Reference Books:-

1. Bob Hughes & Mike Cotterell, “Software project management”, Tata McGraw-Hill Publications,
 Fifth Edition 2012
2. S.A. Kelkar, “Software project management”, PHI, new Delhi, Third Edition, 2013
3. Www.wikipedia.org

UNIT - V

GLOBALIZATION ISSUES IN PROJECT MANAGEMENT

What is globalization? (2m)
 Globalization is the tendency of firms to extend their sales or manufacturing to new markets abroad.
 For businesses everywhere, the rate of globalization in the past few years has been nothing short of
phenomenal.
 Globalization has impacted project management profoundly, and has only reinforced the trend toward
adoption of the project mode of work organization.
 Globalization in project management means among other matters more projects executed in the multi-
cultural environment
 The spectacular globalization of firms in the course of the past decade has been a key challenge for
practitioners and researchers alike
 Strategy researchers have attempted to pin down the various alternatives for firms to gain competitive
advantages in international markets
 They have also considered the challenge of managing across borders and implementing a global
strategic management process.
 Forming multicultural teams has been one of the organizational responses taken by multinational
corporations.

EVOLUTION OF GLOBALIZATION
Explain the evolution of globalization? (13m)
 The key aspects of the various stages of evolution of global teams are:-
 CHALLENGES IN BUILDING GLOBAL TEAMS
What are the challenges in building global teams? (5m)
1. Poor communication
Most virtual teams cite communication as one of their greatest challenges. They lack informal, everyday
face to face communication, which often results in loss of information or miscommunication. The team
members often go for days without contact which can lead to a feeling of isolation.
2. Lack of social interaction
The second challenges of virtual teams are that virtual working can be draining, as it is hard for team
members to create working friendships. Team members do not see how their work and projects fit as a whole,
so they often become demotivated and despondent.

3. Lack of trust
Virtual working often creates mistrust among team members, which is often one of the biggest
challenges of managing virtual teams. Members rarely work at the same time, cannot see what others are doing
and do not get immediate responses. Trust is, therefore, a big problem which can be averted by creating
awareness of the contribution and achievements of every team member.
4. Diverse multicultural teams
Virtual teams often constitute people from different ethnic groups, with different cultures. As a result,
the team members have conflicting customs, work habits, and values. Overcoming cultural diversity
automatically becomes a challenge as everyone follows his or her way of working and leaders face the
challenge of finding common grounds

5. Loss of morale and team spirit

A significant percentage of virtual team members have trouble keeping their spirits high. Unlike face to
face teams that create cohesiveness, virtual teams feel more like some globally dispersed individuals who are
working on the same project.

6. Physical distance
Lack of face to face interaction means cold relations among members, which pose great risks for the
competence of the virtual team.

7. Time zone differences

This is an obvious challenge of working in virtual teams, as members reside in different locations.

8. Routine
Just like in any other working environment, working on a daily routine reduces motivation especially in
virtual teams.
9. Personal life and work-life imbalance
The concept of virtual teams involves tasks being accomplished from the same physical space, where
most team members go about their personal lives.

10. Lack of clarity, direction, and priorities

The most difficult part of entrenching a specific goal is maintaining it and keeping everyone focused.
Virtual staff consists of professionals living in different time zones, with varying priorities and abilities, making
it difficult to keep everyone in the same direction.

MODELS FOR THE EXECUTION OF GLOBAL PROJECTS

Elaborate the different models used for the execution of global projects? (15 m)
 There are different types of models under which the global project teams operate. There are three models
that are commonly used when executing projects with geographically distributed teams.
Resource Model:
In the Resource Model, one of the teams is identified as the primary team. The primary team
directs and allocates work for the other team (called the extended team). The extended team acts as a
resource to the primary team. Some of the attributes of this model are:
 The primary team dictates all aspects of work allocation
 The extended team executes the work allocated to them
 The extended team reports to the primary team
 The local manager of the extended team is more in charge of the administrative aspects than the
work allocation aspects.
 Life cycle model:
In this model, different teams have specialisation and responsibility in different life cycle
phases. For example, the responsibility for finalizing requirements may lie with the team which is closest
to the customers / market, because the most logical place to do the requirement study is where the major
market is. A given location may have developed and established competence in certain key technology
areas.
The primary benefit of this model stems from the fact that each location is being called upon to
do what it is good at doing. This ties in well with the concept of "core competence" that has gained
acceptance in the management practice.
One risk element in this model is the tendency of a team to become prisoner of its own success
and be straight-jacketed or labeled for a given life cycle activity.
Integrated team model:
This represents the true Global, distributed model. The teams in different locations work in close
unison through all the life cycle phases as peers. As a result, they generally gel better, thus overcoming
the primary disadvantage of the resource model. Because no team is confined to any one aspect or a life
cycle phase, they get the opportunity to do different Kinds of work, thus overcoming the problem straight-
jacketing as the case of the life cycle model. Thus this model seems to be the best of all models.
But there is a price to be paid for this. The teams have to have a good level of understanding to
make this model work. The fact that they have to work in close unison leads to an increased demand for
better and more frequent communication between them. The success of this model depends upon the
different teams being more or less on par with one another in terms of competencies and capabilities.
Comparison Of The Three Models:
In the resource model, the process or communication is as simple as the primary team telling the
extended team, this needs to be done.
In the life cycle model, the need for communication between the teams increases because each
life cycle phase has to get the right inputs from the previous phase.
In the integrated team model, the need for communication is extremely high because there is no
clear cut separation between either the life cycle phases or the teams.

SOME EFFECTIVE MANAGEMENT TECHNIQUES FOR MANAGING GLOBAL TEAMS

1) Project Mission
This involves determination of a clearly defined project’s goals and mission by management with clear
indications.

2) Competent project manager

A skilled project leader who possesses the essential interpersonal, technical and administrative
competencies.

3) Top Management Support

No project is likely to succeed unless it enjoys the full support of the senior management within the
organization.

4) Project Plan
All activities surrounding the projects have to be meticulously planned for and the necessary resources
required to carry out the project have to be fully allocated.

5) Client Consultation
A detailed understanding of your client requirement is a must for a project manager, and thus regular meetings between client
and the project manager are deemed necessary at all stages of the project.

6) Competent project team

Recruitment, Selection of competent staff backed by their training is critical in order to ensure the
success of the project.

7) Technical Task
Technical skills have to be matched with the right people in terms of qualifications and expertise
 8) Client Acceptance
Gaining acceptance from one’s client for any given project is critical. Thus a project manager needs to
develop a sound selling strategy at an early phase of the project in order to sell the project to the client.

9) Monitoring and Feedback

Obtaining feedback throughout the project from key individuals is necessary to ensure a quality
outcome for the project.

10) Communication
The concept of communication in project management refers to the spoken and written
documentation, plans, and drawings used in the processes of an international project.

IMPACT OF THE INTERNET ON PROJECT MANAGEMENT

INTRODUCTION
Describe the various impacts of the internet in project management? (15 m)
 The IoT is essentially the global network of devices that can communicate with one another and end
users through the internet.
 In terms of project management technology, the IoT will fundamentally alter the speed of project
execution. Organizations that capitalize on the IoT will complete projects faster than those that don’t,
and organizations that fail to adapt to the IoT revolution will be left hopelessly behind.

EFFECT OF INTERNET ON PROJECT MANAGEMENT

List the main characteristics of internet economy. (2m)
 Two of the main characteristics of the internet economy are
a) Neck-breaking speed at which technology is evolving: The hardware infrastructure as well
as the internet software is making advances at a very rapid pace.
b) Drastic reduction in product cycle times: To cope up with the rapid changes in technology,
product cycle times-the time gap that spans a project from the conceptualization stage through product
development and finally to product obsolescence-has come down drastically.
 There are at least three significant effects of this race for time on project management. These are:
 Reduction in training time of employees through the use of technology and e-Learning.
 Reduction in software distribution costs and time.
 Reduction in time needed for dissemination of accurate information.
Training Time Planning:
 'Time' is an important factor while planning a project to ensure that the employees are fully trained for
their job.
 But planning for training in the pre-internet days was not easy owing to several factors:
 Scheduling of training
 Quality of training
 Cost of training
 With the advent of the internet has come e-learning, which overcomes the disadvantages of above.
 The model for e-learning is as follows:
 A competent and capable trainer is indentified.
 The offered training is captured and stored on the internet. E.g., learning management
system.
 The "stored training" consists of the instrumental material (like slides) as well as multimedia
material (video classes).
 The employees take the training as and when they need it and as and when they have the time.
 Employee’s questions must be answered and all doubts are clarified either in a chat room or via
email by the instructor.
 This e-Learning is supplemented by the necessary conventional training mechanism like
classroom training, use of books, etc.
Software Distribution and deployment changes:
 In the pre-Internet days, software had to be distributed to the customers through some media. The
distribution media has changed over the years from tapes to floppies to CDs. But in each of these cases,
 the project manager had to account in his plan the delay between the actual completion of the project
and the software reaching the customer. The typical steps involved would be:
a. The software product organization makes the product available on a "master media from which
copies can be made.
b. The customer would be notified of the availability of the software
c. The customer would place an order for the software with the software organization
d. The software would be copied into an appropriate media after ensuring that the customer has met
all the pre-requisite conditions (licensing, legalities, payment, etc.)
e. The media is shipped to the customer
f. The customer receives and installs the product.
 With the advent of the internet, the software distribution model moved to web based deployment. The
new model is based on self service.

Explain the role of internet in enhancing communication in brief? (13 m)

Internet’s Role in enhancing communication:
 The success of the project is influenced by the effectiveness of communication among the terms.
 Internet has opened up several new avenues to facilitate this. They are:-
o Sharing a common repository of geographically distributed project information
o Better and less expensive means of communication
o Ability to access information anytime, anywhere

MANAGING PROJECTS FOR THE INTERNET

Characteristics of Applications for the internet:
 The evolution of an organisation's presence on the Internet generally goes through three distinct phases:
 First, an organisation provides non-interactive web sites. This calls for no simpler page design. The
organisation can choose to use the Internet to display an online catalog. It can also give product and
pricing information online. This phase of web presence is just a conduit for customers to get to know a
point of contact in the organisation (like an email id).
 In the next phase of evolution, the organisation opens the doors to customers for transactions over the
Internet. For example, the customers can place orders for products over the Internet. Such orders get into
the normal order processing system of the organisation and get fulfilled by the normal "brick and mortar"
system of deliveries. This is the first exposure a customer gets to the applications in an organisation. Such
applications on the Internet are called "B2C", which stands for, Business to Consumers.
 In the final phase of evolution, the customer's application seamlessly integrates with that of its suppliers
and customers. The suppliers know which goods the organisation needs and at what time and interface
 with the bricks and mortars infrastructure to get the goods delivered. Similarly, the customers of the
organization gain an automatic window into the organisation's ordering system and place orders for what
they want. There is a tight link between the logistics at the organisation's end that cover transportation,
billing payment, etc. to that of the customer. All the interaction and communication is over the Internet.
The entire supply chain is fairly transparent. This type of application over the Internet is called "B2B",
which stands for, Business to Business.
 The next phase of evolution in progress is the concept of exchanges. During this phase, there is no real
organisation-specific software. Everyone "comes in to" a common market place called exchange. There
are usually industry specific exchanges for example, airline exchange, automobile industry exchange,
retail exchange, etc. All the requirements of various organisations are registered into the exchange. There
is a process of bidding, auctioning and reverse auctioning that happens before a deal is struck.
 There are other types of internet arena includes Internet service providers (ISPs), Application Service
Providers (ASPs), Portals and content providers.

 Most of the typical applications for the internet are characteristics by the following attributes:
o Very simple deployment model
o Need for mass customization
o Self service
o Convergence of media
o Importance of standards

EFFECT ON PROJECT MANAGEMENT ACTIVITIES

 The unknown Customer and requirements management
 Configuration management issues
 Design and development issues
 The unique challenges of performance testing
 The need to do it right first time: The “word of mouse” spreads faster than the word of mouth!
 Maintenance phase changes

COMPARISON OF PROJECT MANAGEMENT SOFTWARE

DOTPROJECT

Compare and contrast project management software? (13 m)

What are the features of DotProject/ LaunchPad/ OpenProj? (2 m)
 Written in 2000 on the PHP platform, dotProject’s latest stable release is 2.1.8, released on July 27,
2013.
  It has a GNU GPL and supports all types of OS.
 Developer team includes Gregor Erhardt, Benjamin Young, Adam Donnison, Karen Chisholm, Eamon
Brosnan and Ivan Peevski. dotProject is currently available for download at Sourceforge.
Features
 Since it is one of the best maintained open source project management application, it has an intuitive
browser-based interface, and offers an entire spectrum of sophisticated project management tools and
features for multiple users.
 Task Management features include Task Description, Assigning, Scheduling and Duration of the task.
 It allows nodal user permissions, discussion dashboards, Gantt charts, contact lists, file checkout,
reporting, and user-based or list-based task features.
Technical Requirements
 DotProject works on all operating systems and is therefore highly appreciated for its agility across all
platforms.
 This allows teams and multiple users or companies using various operating systems to work
collaboratively on dotProject.
Advantages
 Easy to use interface.
 USP: Appending files to projects and tasks enabled with a file repository.
 Multiple users can work collaboratively.
 Issue Tracking becomes easier.
Disadvantages
 One downside is it is not a stand-alone application and needs to be on a web server to work. Advanced
technical expertise might be required for installation.
LAUNCH PAD
 A launch pad is a midi device which is primarily used to launch clips in Ableton Live (FL studio as well).
It can also be used as a midi controller in other softwares such as Traktor Pro, as a Keyboard, as a Drum
machine, etc.
Features
 Control Ableton Live. Get hands-on control of anything in Ableton Live without any set up.
 Fits Anywhere. As our smallest and lightest Launchpad, this is perfect for a compact setup.
 Make Something Spectacular. ...
 Mix with Your Grid. ...
 Get Creative. ...
 Control FL Studio. ...
 Plug-In and Play. ...
 Create a Full Studio.
Advantages
 It consolidates all Advantage shortcuts into one application
 It eliminates the need to reinstall user shortcuts
 It replaces the Advantag.ini files
 It provides an applications that shows you all the available areas between test and production
OPENPROJ
 OpenProj is a Java-based open source project management tool developed at Projity by Howard Katz,
Marc O’Brien and Laurent Chretienneau in 2007.
 In 2008, the company was acquired by Serena Software, and development has ceased thereafter.
 In May 2016, Serena was acquired by Micro Focus and has become one of its subsidiaries.
 In 2012, the original creators of OpenProj forked the abandoned code and developed ProjectLibre,
which was initially released in 2012.
Features
 Closely following proprietary software Microsoft in features, OpenProj offers a similar User Interface
(UI) and the same project development plan.
 Version 1.4 is the last stable release and includes features and tasks that are the open source version of
commercial software Microsoft Project.
 With the greatest resemblance to MS Project, OpenProj, is the free software option which offers similar
features, except for the price. However, it is no longer compatible with MS Project.
Technical Requirements
 It is a Java-based application and is rather tacky on Windows, but works perfectly on Linux and Unix as
well as Mac OS platforms. It supports 10 languages and is included in Open Office program’s European
version.
Advantages
 Well organized and covers essential business requirements: CRM, HRM and financial management as
well as workflows that can be set up for approval.
 GUI is intuitive and easy to use.
 Scope for collaborative work and functioning are good because of advanced feature tools.
 Clean, uncluttered and non-confusing work scope.
 OpenProj does support graphic view of Work Breakdown Structure.
Disadvantages
 No resource leveling.
 No export to spreadsheet.

CASE STUDY: PRINCE2

Explain PRINCE2. (5/10 m)
 PRINCE2 (an acronym for PRojects IN Controlled Environments) is a de facto process-based method
for effective project management. Used extensively by the UK Government, PRINCE2 is also widely
recognized and used in the private sector, both in the UK and internationally. The PRINCE2 method is
in the public domain, and offers non-proprietarily best practice guidance on project management.
Features of PRINCE2:
 Focus on business justification
 Defined organization structure for the project management team
 Product-based planning approach
 Emphasis on dividing the project into manageable and controllable stages
 Flexibility that can be applied at a level appropriate to the project.
Prince 2 history
 PRINCE was established in 1989 by CCTA (the Central Computer and Telecommunications Agency),
since renamed the OGC (the Office of Government Commerce).
 In June 2010, the Office of Government Commerce Best Practice Management functions moved into the
Cabinet Office.
 PRINCE was originally based on PROMPT, a project management method created by Simpact Systems
Ltd in 1975, and adopted by CCTA in 1979 as the standard to be used for all Government information
system projects.
 When PRINCE was launched in 1989, it effectively superseded PROMPT within Government projects.
PRINCE remains in the public domain and copyright is retained by the Crown. PRINCE2 was
published in 1996, having been contributed to by a consortium of some 150 European organizations.

How can PRINCE2 benefit you? (2m)

 Using PRINCE2 provides you with greater control of resources, and the ability to manage business and
project risk more effectively. This will benefit:
 Individuals seeking leading project management skills and greater employment prospects
 Project managers
 Directors/executives (senior responsible owners) of projects, and Organizations.

************ UNIT – V COMPLETED ************

References
1. Bob Hughes & Mike Cotterell, “Software project management”, Tata McGraw-Hill Publications, Fifth
Edition 2012
2. S.A. Kelkar, “Software project management”, PHI, new Delhi, Third Edition, 2013
3. Www.wikipedia.org