Software

Engineering
 SW PROJECT
MANAGEMENT

05/21/23 2
 4Ps
SW Project Management discusses about 4Ps:
•People-
•Process
•Problem
•Product
These 4Ps are collectively are conducted on
Project

05/21/23 3
 4Ps
Software Project Management focuses on four points: People, Problem, &

Process.
THREE POINTS

PEOPLE

PROBLEM

PROCESSES PRODUCTS

05/21/23 4
 INTRODUCTION:
• PEOPLE:
• The cultivation of motivated, highly skilled software people is very
important.
– SEI has developed “People Management Capability Maturity Model”
(PMCMM) for projecting “People factors”.
– The PMCMM defines the following key practice areas for SW People:
Recruiting, selection, Performance Management, training, compensation,
and career development, Organization of work design & team development.

• PROBLEM:
• Before the project planning, its objectives & scope should be
established, alternative solutions should be considered, technical and
management constraints should be developed.
– W/o above information it is impossible to define reasonable estimate of cost,
risk factor, Management scheduling.
• The software developer & customer must meet the defined project objectives &
scope.
• Once project objectives & scope are understood, alternative solutions are
considered.
• Scope identifies the primary data, functions & behavior that characterize the
problem & more important that attempts to bound these characters in a well
manner.
05/21/23 5
• PROCESS:
• A software process provides the framework from which
comprehensive plan for software development can be established.

– A small no: of ‘framework activities’ are applicable to all

software projects.

– A no: of task sets enable the framework activities to be

adapted for software project and project team.

– Finally ‘Umbrella Activities’ overlay the project model. These

activities are independent of any one-framework activity.

05/21/23 6
 ISSUES OF PM

05/21/23 7
 THE PEOPLE
– Peoples are more important than tools.
– Peoples are important ingredient for a successful
project.
– Good management depends on good peoples.
– From all above description it is very clear about
the testimonial of/ about people.
– Let us discuss some Players who participate in
software process.

05/21/23 8
 PLAYERS:
• Senior manager who defines business issues
• Project manager who plan, motivate, organize & control the work.
• Practitioners who delivers the technical skills
• Customers who specify the requirement
• End users who interact with the software
TEAM LEADERS:
• There are the people who manage the project. The qualities of a good team
leader are:
• MOTIVATION:
• The ability to encourage technical people to give their best ability.
• ORGANIZATION:
• The ability to organize and mold existing processes that will help into final
product.
• IDEAS:
• The ability to encourage people so that they can give creative ideas by
considering the bounds.
• PROBLEM SOLVING:
• The ability to diagnose the technical and organizational issue and solve them.
• MANAGEMENT IDENTITY:
• He must take charge of project & be much confident.
• ACHIEVEMENT:
• He must reward the achievements of the project team.
• TEAM BUILDING:
• Team must be able to read the people & he must remain under control in high stress
situations

05/21/23 9
 – THE SW TEAM:
• Following are options available for applying human
resources to a project that will require ‘n’ people
working for ‘k’ layers.
• ‘n’ individuals are assigned to ‘m’ different functions.
Coordination is the responsibility of SW manager.
• ‘n’ individuals are assigned to different functional tasks
(m<n) adhoc team leader may be appointed.
• ‘n’ individuals are organized into ‘t’ teams and each team
is assigned one or more functions.
• The best team structure depends on the management
style of an organization, the no: of people & overall
problem difficulty.

05/21/23 10
 TYPES OF TEAM
ORGANIZATION
1. DEMOCRATIC DECENTRALIZED (DD):
1. This software team has no permanent leader.
2. Task coordinators are appointed.
3. Group makes decisions on problems & approach.
4. Communication between team is horizontal.
2. CONTROLLED DECENTRALIZED (CD):
1. This software team has a leader who coordinates.
2. Problem solving remains a group activity.
3. But team leaders make decisions.
4. Communication between team is vertical.
3. CONTROLLED CENTRALIZED (CC):
1. A team leader manages top-level problem solving & internal team
coordination.
2. Communication is vertical.

05/21/23 11
 FACTORS FOR PLANNING A SWE
TEAMS
1. The difficulty of the problem to be solved.
2. The size of the program in lines of code or function
points.
3. The time, the team will stay together (Team life time).
4. The degree to which the problem can be modularized.
5. The required quality & reliability of the system to be
built.
6. The rigidity of the delivery date.
7. The degree of communication required for project.

05/21/23 12
 ORGANIZATIONAL
PARADIGMS
1. A ‘closed Paradigm’ structures same as cc. such teams works well
to built software which is similar to past efforts, but less innovative
when working in closed paradigms.

2. A ‘Random Paradigm’ structures team loosely and depend an

individual effort. They fail when break through is required but
succeeded when ‘Orderly performance’ is required.

3. An ‘Open Paradigm’ has the qualities of both closed & random

paradigm. Work is performed with heavy communication &
decision making as collectively. this paradigm is well known to
solve a complex problem.

4. A ‘Synchronous Paradigm’ relies on natural compartmentalization

of problem & organizes team to work on pieces of problem with
little communication between them.

05/21/23 13
 Factors considered while planning the structure of Software
Engineering Teams

• When planning the structure of software engineering teams, the

following project factors should be considered:
•
• The difficulty of the problem to be solved
• The time that the team will be needed to stay together
• The size of the resultant program(s) in lines of code or function
points.
• The degree to which the problem can be broken up into
modules
• The expected reliability and quality of the system to be built
• The expected amount of communication required for the
project
• The rigidity of the delivery date

05/21/23 14
 What structure can be used and when?
• For solving simple problems
– A centralized structure is more suitable since it completes faster than a
decentralized one.
• For solving difficult problems
– A decentralized structure is suitable since decentralized teams generate
more and better solutions than individuals.
• For large projects
– Since the performance of a team is inversely proportional to the
amount of communication that must be conducted, very large projects
can be addressed by teams with a CC or CD structure where sub-
grouping can be easily accommodated.
• For high morale and job satisfaction
– The DD team structure results in high morale and job satisfaction and
are therefore good for teams that will be together for a long time.

05/21/23 15
 What structure can be used and when?

• For solving problems with low modularity

– The DD team structure is best applied to problems with relatively low
modularity because of the higher volume of communication needed.
When high modularity is possible (and people can do their own thing),
the CC or CD structure will work well.
• CC and CD teams have been found to produce fewer defects
than DD teams, but these data have much to do with the
specific quality assurance activities that are applied by the
team.
• Decentralized teams generally require more time to complete a
project than a centralized structure and at the same time are
best when high sociability is required.

05/21/23 16
 THE PROBLEM
• A detailed analysis of SW requirement would provide for
better estimate. Therefore we must examine the problem at the
very beginning of the project. At minimum the scope of the
problem must be bounded.

05/21/23 17
 PROBLEM DECOMPOSITION
• It is some times called Partitioning.
• It is the activity, which sits at the core of SW requirement.
• Decomposition is applied in two major areas:
• The functionality that must be delivered.
• The process that will be used to deliver it.
• Complex problem is partitioned into smaller problems that
are more manageable.
• Because both cost & schedule estimates are
functionally oriented, some degree of
decomposition is often useful

05/21/23 18
• UNDERSTANDING THE PROBLEM
– In understanding the problem that What Output, What Issues, What
Constrains, What Environment, What Special Performance issues,
• After that final set of questions focus on the effectiveness of the
melting called “Meta Questions” are asked:
– Are the person answering the questions in authorize.
– Were there too many questions to boor?
– Is there any other person to give more information to questions?
– Any other additional thing by customer.
• PLANNING: (START HIGH LEVEL PLANNING BY):
– Knowing the capabilities of existing software & staff.
– Join Leans of customer and develop / Analysts.
– Check list of items to cover.
• ORGANIZATION OF INFORMATION: (MANAGE WORK AS IT
AS):
– Get every thing down with diagram.
– Create and save transcripts of meetings.
– Possibly use web.
• :

05/21/23 19
 Example:
• Consider a project of building a new word Processor. Features
of product are voice & keyboard I/P. Automatic Copy Edit
features are project layout, capability automatic indexing &
table of contents.

05/21/23 20
 Solution
• The project manager first establish statement of scope that
bounds above features & plus more related features such as
editing, file management document production etc. He also
decides that if continuous voice I/P is required then product
must be ‘trained’ by the ‘user’.
• After that project team may talk to customers & find that
with all above features the following other facilities may be
included as spell checking, grammar check, reference check
for large documents, bibliography check, chapter & section
reference for large documents, etc.
• Each of these features represents a sub function to
be implemented in software. Each in turn can be
further refined.

05/21/23 21
 THE PROCESS
• Project planning begins with melding of the problem & the
process. Each function to be engineered by the software team must
pass through following framework activities:
• Customer-Communication.
• Planning.
• Risk Analysis.
• Engineering.
• Construction & Release.
• Customer Evaluation.
• Now consider the example of word processing. The team members
develop a matrix as in fig 3.2, in which major problem functions
are listed & framework activities are given at top.

05/21/23 22
 PROCESS DECOMPOSITION
• Software team should have flexibility in choosing SWE
paradigm.
• Small projects similar to past efforts might be chosen.
• The problem must be heavily compartmentalized.
• For this, RAD model is the right choice, because if
deadline is tight then incremental strategy is good to
adopt.
• After the selection of model CPF (Common Process
Framework) is adopted, b/c it will work linear models.
• After that all the above activities must be adopted.

05/21/23 23
 WORK TASKS FOR CUSTOMER
COMMUNICATION
• Develop list of clarification issues.
• Meet with customer to address clarification
issues.
• Jointly develop a statement of scope.
• Review the state of scope with all concerned.
• Modify the statement of scope as required.
• These events might occur over period of less
than 48 hours
05/21/23 24
 CUSTOMER COMMUNICATION
ACTIVITIES
• Review the customer request.
• Plan & Schedule a formal facilitated meeting with
customers.
• Conduct research to define proposed solutions and
approaches.
• Prepare working document & Agenda for meetings.
• Conduct a meeting.
• Develop mini-spees that reflects the characters of software.
• Review mini-spees to avoid ambiguity.
• Assemble mini-spees into document.
• Review of spee-document with all concerns.
• Modify the spee-document if required.

05/21/23 25
 THE PROJECT
• 90 – 90 Rule: “The first 90% of the system absorb 90% of
the allotted effort & time. The last 10% takes the other 90%
of allotted effort & time.
– The reasons about the state of a project that gets into trouble:
– The manner in which progress is assessed is flawed.
– There is no way calibrating progress because quantitative
matrices are unavailable.
– The project plan has not been designed to accommodate
resources required at the end of project.
– Risk has not been considered explicitly & plan for mitigating,
monitoring and managing them has not been created.
– The schedule is (1) unrealistic or (2) flawed.
• To overcome on these problems the must be spend at the
beginning of the project to establish realistic plan during the
project to monitor the plan & throughout the project to
control the quality & change.

05/21/23 26
 Software Project Estimation

• Precise estimation is difficult. So, make three estimates:

optimistic, most likely, and pessimistic. Then combine as:

EV=(Sopt + 4Sm + Spess)/6

27
 Resources - Make-Buy Decision

• Develop specification for desired software

 Estimate cost to develop internally and estimate delivery date
 Select candidate applications that come closest to meeting specifications.

 Select reusable components that could assist constructing the required

application

 Develop comparison matrix that compares key functions and costs.

Possibly conduct benchmark tests

28