[CSc.

351 Software Engineering]

Lecturer: Hiranya Bastakoti

Amrit Science Campus

Downloaded From: csitascolhelp

Project Management: Chapter- Four Software Engineering
Introduction:
Project:
 A project is a temporary endeavor undertaken to provide a unique product or service
 A project is a (temporary) sequence of unique complex and connected activities that have one
goal or purpose and that must be completed by a specific time, within budget and according to
specification.
OR
 A project is a sequence of activities that must be completed on time, within budget and according
to specification.
Project management
 Project management is the process of scoping, planning, staffing, organizing, directing and
controlling the development of an acceptable system at a minimum cost within a specified time
frame.
A project is considered as a success if:
 The resulting information system is acceptable to the customer.
 The system is delivered “on time”.
 The system is delivered “within budget”.
 The system development process had minimal impact ongoing business operations.
A project is said to be failed if:
 Failure to establish upper management commitment to the project.
 Lack of organization’s commitment to the system development method.
 Taking shortcuts through or a around the system development method
 The project gets behind schedule.
 The project is over budget.
 The team is not trained or skilled.
 Poor planning
 Lack of quality standards.
 Lack of communication between end users and developers.
 Changing requirements.
Software project management:
 It is concerned with activities involved in ensuring that software is delivered on time and on
schedule and in accordance with the requirements of the organisations developing
and procuring the software.
 Project management is needed because software development is always subject to budget and
schedule constraints that are set by the organisation developing the software.
Software management distinctions:
 Software engineering is different from other types of engineering in a number of ways. These
distinctions make software management particularly difficult. some of differences are:
 The product is intangible: it cannot be seen or touched. Software mangers cannot see
progress.
 The product is uniquely flexible.

Compiled by: Hiranya Bastakoti Page 1

 Software engineering is not recognized as an engineering discipline with the same status as
mechanical, electrical engineering, etc.
 The software development process is not standardised: process may vary dramatically from
one organization to another.
 Many software projects are 'one-off' projects: rapid technological changes in computers
and communications can make a manager’s experience obsolete (out dated). Lessons
learned from previous projects may not be transferable to new projects.
Software Manager:
 Software managers are responsible for planning and scheduling project development. They
supervise the work to ensure that it is carried out to the required standards and monitor
progress to check that the development is on time and within budget.
 The software project manager’s job is to ensure that the software project meets constraints
(Budget and schedule constraints) and delivers software that contributes to the goals of the
company developing the software.
Common activities software managers include:
 Management
 Leadership
 Technical problem solving
 Problem solving
 Conflict management
 Customer relations
 Team management
 Risk and change management
Management activities:
 Proposal writing:
 Project planning and scheduling.
 Project costing.
 Project monitoring and reviews.
 Personnel selection and evaluation.
 Report writing and presentations.
Management commonalities
 These activities are not peculiar to software management.
 Many techniques of engineering project management are equally applicable to software project
management.
 Technically complex engineering systems tend to suffer from the same problems as software
systems.
Project staffing
 May not be possible to appoint the ideal people to work on a project
• Project budget may not allow for the use of highly-paid staff;
• Staff with the appropriate experience may not be available;
• An organisation may wish to develop employee skills on a software project.
 Managers have to work within these constraints especially when there are shortages of trained
staff.
Project planning
 It involves making detailed plan to achieve the objectives.
 Probably the most time-consuming project management activity.

Compiled by: Hiranya Bastakoti Page 2

 Continuous activity from initial concept through to system delivery. Plans must be regularly
revised as new information becomes available.
 Various different types of plan may be developed to support the main software project plan that
is concerned with schedule and budget.

Types of plan:
 Quality Plan: It describes quality procedures and standards that will be used in a project.
 Validation Plan: It describes the approach, resources and schedules used for system validation.
 Configuration management plan: it describes the configuration management procedures and
structures to be used.
 Maintenance plan: It predicts the maintenance requirements of the system maintenance costs
and effort required.
 Staff development plan: It describes how the skills and experience of the project team members
will be developed.
Project planning process

Establish the project constraints

Make initial assessments of the project parameters
Define project milestones and deliverables
While project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait (for a while)
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if (problems arise) then
Initiate technical review and possible revision
end if
end loop

The project plan

 The project plan sets out:
• The resources available to the project;
• The work breakdown;
• A schedule for the work.
 The details of the project plan vary depending on the type of project and organization. However,
most plans should include the following sections:
1. Introduction: This briefly describes the objectives of the project and sets out the constraints
(e.g. budget, time etc.) that affect the project management
2. Project organization: This describes the way in which the development team is organized, the
people involved and their roles in the team.

Compiled by: Hiranya Bastakoti Page 3

3. Risk analysis: This describes possible project risks, the likelihood of these risks arising and the
risk reduction strategies that proposed.
4. Hardware and software resource requirements: This specifies the hardware and the support
software required to carry out the development. If hardware has to be bought, estimate of the
prices and delivery schedule may be included.
5. Work breakdown: This sets out the breakdown of the project into activities and identifies the
milestones and deliverables associated with each activity.
6. Project schedule: This shows the dependencies between activities, the estimated time required
to reach each milestone and the allocation of people to activities.
7. Monitoring and reporting mechanisms: This defines the management reports that should be
produced, when these should be produced and the project monitoring mechanisms used.

Milestones and Deliverables:

 Activities in a project should be organised to produce tangible outputs for management to judge
progress.
 Milestones are the end-point of a process activity.
 A project milestone is a predictable state where a formal report of progress is presented to
management.
 Deliverables are project results delivered to customers. It is usually delivered at the end of some
major phase such as specification or design. Deliverables are usually milestones, but milestones
need not be deliverables.
 Milestones may be internal project results that are used by the project manager to check project
delivered to the customer
 The waterfall process allows for the straightforward definition of progress milestones.
 To establish milestones, the software process must be broken down into basis activities with
associated outputs. The fig (below) shows possible activities involved in requirement
specification when prototyping is used to help validate requirements. The milestones in this
case are completion of the outputs for each activity. The project deliverables, which are
delivered to the customer, are the requirements definition and the requirements specification.
Milestones in the RE process

Project scheduling

 It is the one of the most difficult job for a project manager. managers estimate time and
resources required to complete activities and organize them into coherent sequence.

Compiled by: Hiranya Bastakoti Page 4

It involves:

 Split project into tasks and estimate time and resources required to complete each task.
 Organize tasks concurrently to make optimal use of workforce.
 Minimize task dependencies to avoid delays caused by one task waiting for another to
complete.
It‘s Dependent on project managers intuition and experience.
 Project scheduling involves preparing various graphical representations showing project
activities, their durations and staffing.

The project scheduling process

Scheduling problems

 Estimating the difficulty of problems and hence the cost of developing a solution is hard.
 Productivity is not proportional to the number of people working on a task.
 Adding people to a late project makes it later because of communication overheads.
 The unexpected always happens. Always allow contingency in planning.

Bar charts and activity networks

 Graphical notations used to illustrate the project schedule.

 Show project breakdown into tasks. Tasks should not be too small. They should take about a
week or two.
 Activity charts show task dependencies and the critical path.
 Bar charts show schedule against calendar time.

Compiled by: Hiranya Bastakoti Page 5

Task durations and dependencies

Note-milestone

An Activity Network

Compiled by: Hiranya Bastakoti Page 6

Activity bar chart(Gantt chart)

Staff allocation vs.Timechart

Compiled by: Hiranya Bastakoti Page 7

Risk management

 Risk management is concerned with identifying risks and drawing up plans to minimise their
effect on a project.
 Risk management is concerned with identifying risks which may affect the project and planning
to ensure that these risks do not develop into major threats
 A risk is a probability that some adverse circumstance will occur
• Project risks affect schedule or resources.eg.loss of experienced designer
• Product risks affect the quality or performance of the software being developed. e.g.
failure of purchased component to perform an expected.
• Business risks affect the organisation developing or procuring the software.e.g,a
competitor introducing a new product is a business risk.
Software risks:

The risks may be affect a project depend on the project and the organizational environment where
software is being developed.

The risk management process:

 Risk identification
• Identify project, product and business risks;
 Risk analysis
• Assess the likelihood and consequences of these risks;
 Risk planning
• Draw up plans to avoid or minimise the effects of the risk;
 Risk monitoring
• Monitor the risks throughout the project;
The risk management process, like other project planning is an iterative process which continues
throughout the project. Once an initial set of plans are drawn up, the situation is monitored. As more

Compiled by: Hiranya Bastakoti Page 8

information about the risks becomes available, the risks have to be reanalyzed and new priorities
established. The risk avoidance and contingency plans may be modified as new risk information
emerges.

Fig: The risk management process

Risk identification:

It is the first stage of risk management. It is concerned with discovering possible risks to the project. Risk
identification may be carried out as a team process using a brainstorming approach or may simply be
based on experience. There are si x types of risk that can arise:

 Technology risks.
 People risks.
 Organisational risks.
 Requirements risks.
 Estimation risks.

Risk analysis

 During risk analysis process, assess probability and seriousness of each risk.
 Probability may be very low, low, moderate, high or very high.
 Risk effects might be catastrophic, serious, tolerable or insignificant.

Compiled by: Hiranya Bastakoti Page 9

Risk planning

 The risk planning process considers each of the key risks that have been identified and identifies
strategies to manage the risk
 Consider each risk and develop a strategy to manage that risk.
 Avoidance strategies
• The probability that the risk will arise is reduced. e.g.: Defective components
 Minimisation strategies
• The impact of the risk on the project or product will be reduced. e.g.: Staff illness

Compiled by: Hiranya Bastakoti Page 10

 Contingency plans
• If the risk arises, contingency plans are plans to deal with that risk. Organizational
financial problems
Risk management strategies:

Risk monitoring

 It involves regular assess each identified risks regularly to decide whether or not it is becoming
less or more probable.
 Also assess whether the effects of the risk have changed.
 Each key risk should be discussed at management progress meetings.
 Risk monitoring should be a continuous process, and, at every management progress review, we
should consider and discuss each of the key risks separately

Compiled by: Hiranya Bastakoti Page 11

Risk indicators

Key points

 Good project management is essential for project success.

 The intangible nature of software causes problems for management.
 Managers have diverse roles but their most significant activities are planning, estimating and
scheduling.
 Planning and estimating are iterative processes which continue throughout the course of a
project.
 A project milestone is a predictable state where a formal report of progress is presented to
management.
 Project scheduling involves preparing various graphical representations showing project
activities, their durations and staffing.
 Risk management is concerned with identifying risks which may affect the project and planning
to ensure that these risks do not develop into major threats

Compiled by: Hiranya Bastakoti Page 12

Planning

A plan is a predetermined course of action. It represents goals ad the activities to achieve these goals.

Planning is an ongoing organizational function that provides the framework for operational activities and
decision making. The organizational mission is translated into operational objectivities through an
organizational hierarchy of planning activities.

Planning focuses the energies and activities of the organization on achievement of its objectives, to
reconcile differences in objectives and plans of subareas and individuals within the organization and to
remove ambiguities about what the organization should do. The formal plan not only guides activities. It
provides a basis for evaluation results. The planning process can result in significant motivation for
individual and organizational achievement but there are also individual and organizational forces
opposed to planning.

Reason for planning system.

1. To offset uncertainty:
Aside from the uncertainty of business operations and the resulting need for better forecasting
information, the special need for a system plan is evident because of advancing computer
technology and its widespread effect on business operations. Both s/w and h/w have become so
complete that the job of selection and utilization is much more difficult. As a result, the majority
of organizations have fallen for short of their potential to use computers for processing the
information necessary to manage the company effectively.
A master plan may not remove the uncertainty, but it will almost surely place the firm in a
better position to deal with the unknowns and to take advantage of development as they occur.
2. To improve economy of operations:
Planning the overall approach to an integrated system is also economical when one job or
function is automated; the need for design and automation of contiguous functions frequently
becomes obvious. Money can be saved and performance improved by an effective linking
together of these neighboring functions through a good plan for integrated system design.
3. To focus on objectives:
A good plan for system development also serves to focus on company and system objectives.
Planning cannot proceed in any area of endeavor until adequate objectives have been first set. It
follows that development of a master system plan forces examination and definition of
objectives.
4. To provide a device for control of operations:
Control: control is the activity which measures deviation from planned performance and
initiates corrective action. System development, implementation and operations are among the
most difficult of activities within the company to control. A major advantage of the development
of system effort under a predetermined plan is that the plan provides a means for subsequent
plan.

Compiled by: Hiranya Bastakoti Page 13

Project plans activities:
The following items should certainly be included in every project plan:
1. Negotiate scopes:
Scope defines the boundaries of a project and included in the statement of work, a narrative description
of the work to be performed as part of a project.
All parties must agree to the project scope before any attempt is made to identify and schedule tasks or
to assign resources (people) to those tasks.
2. Identity tasks:
Tasks identify the work to be done. Typically, this work is defined in a top-down, outline manner. A work
breakdown structure (WBS) is a hierarchical decomposition of the project into tasks and sub-tasks. Some
tasks represent the completion of milestones or the completion of major deliverables during a project.
3. Estimate task duration:
Duration of any tasks is a random variable subject to factors such as the size of team, number of users,
availability of users, aptitudes of users, complexity of the business system, information technology
architecture, experiences of team personal, time committed to other projects, and experiences with
other projects.
4. Given the duration estimates for all tasks, we can begin to develop a project schedule. The project
schedule depends not only on task duration but also on intertask dependencies.
The start or completion of individual tasks may be dependent on the start or completion of other tasks.
These dependencies impact the completion of any project.
There are four types of intertask dependencies:
Finish-to-start (FS) - the finish of one task triggers the start of another task.
Start-to-start (SS) - the start of one task triggers the start of another task.
Finish-to-finish (FF) – two tasks must finish at the same time.
Start-to-finish (SF) – the start of one task signifies the finish of another task.
5. Assign resources:
The following resources may impact a project schedule:
People, services, facilities and equipment, supplies and materials and money.
6. One of the most important dimensions of directing the team effort is the supervision of people.
7. Assess project result and experiences:
This final activity involves soliciting feedback from project team members (including customers)
concerning their project experiences and suggestions aimed at improving the project (and process)
management of the organization.

Planning techniques:
1. Work breakdown structure:
A fundamental concept in project management is the work breakdown structure (WBS). A work
breakdown structure is a hierarchical decomposition of the project into phases, activities, and
tasks.
Or

Compiled by: Hiranya Bastakoti Page 14

-system to subsystem
-subsystem to task
- Task to subtask
-subtask to word package.

Project goal

1 2 3

Phase Phase Phase

2.1 2.2 2.3

Activity Activity Activity

2.2.1 2.2.2 2.2.3

Task Task Task

FIG: A graphical work breakdown structure.

Or
1 Phase 1 of the project
1.1 Activity 1 of the phase 1
1.1.1 Task 1 of the activity 1 in the phase 1
1.1.2 Task 2 of activity 1 in the phase 1.
1.2 Task 2 of phase 1.
2 phase 2 of the project.
Gantt chart:
A Gantt chart depicts an overall picture of events and schedule of each task. It lists activities vertically
downwards on the left most column while the time-periods in months, weeks or days, appear
horizontally in the topmost row.
Compiled by: Hiranya Bastakoti Page 15
ID Task Name may june july aug sept octo nov dece
1 Problem analysis
2 Requirement analysis
3 Logical design
4 Decision analysis
5 Physical design
6 Construction & testing
7 Implementation & testing

Today
Legends
Complete task
Incomplete task

Fig: Gantt chart

Task D

Tue2/20/01 7 days

Tue2/20/01 0 days

Task A Task B Task C Task D Task I

Tue2/5/01 3 days Tue2/7/01 2 days Tue2/3/01 7 days Tue2/13/01 6days Tue2/27/01 5 days

Tue2/5/01 0 days Tue2/7/01 0 days Tue2/3/01 0 days Tue2/20/01 1 day Tue2/27/01 0 days

Task F Task G

Tue2/14/01 3 days Tue2/16/01 2 days

Tue2/16/01 2 days Tue2/20/01 2 days

Task H

Tue2/15/01 1 day

Tue2/10/01 3 days

Compiled by: Hiranya Bastakoti Page 16

Fig: critical analysis path.
Suppose a project consists of the nine primitive tasks as shown in fig. The most likely duration (in days)
for each task is recorded. There are four distinct sequences of tasks in a project. They are:
PATH 1: A →B →C →D →I
PATH 2: A→ B→C →E→I
PATH 3: A→B →C →F →G→I
PATH 4: A→B→ C→ F→ H→ I
The total of likely duration times for each path is calculated as follows:
PATH 1: 3+2+2+7+5=19
PATH 2: 3+2+2+6+5=18
PATH 3: 3+2+2+3+2+5=17
PATH 4: 3+2+2+3+1+5=16

Compiled by: Hiranya Bastakoti Page 17