CH1

INTRODUCTION
TO
SW PROJECT
MANAGEMENT
7/1/2019 M. S. Memon, CSE Deptt. QUEST 2

Instructor’s Profile
• (Ph.D.) SWE
QUEST, Nawabshah
• M.E. (Software Engineering)
MUET, Jamshoro
• B.E. (Computer Systems Engineering)
MUET, Jamshoro
M.S. Memon
1 July 2019 CSE Department, QUEST 3
Course Objective
• To learn the techniques required to plan,
organize, monitor and control software
development projects
M.S. Memon
Learning aspects in SPM …
• Managing people, process and problems during a

software project
• Relating software metrics with software projects
• Estimating effort, cost and project duration
• Risk assessment techniques
• Project scheduling
• Project quality management
• Change management during software development
and after delivery to customer
M.S. Memon
Books
– Software Engineering: A Practitioner’s Approach
by Roger Pressman
– Software Project Management
by Bob Hughes
– IT Project Management
by Kathy Schwalbe
M.S. Memon
The beginning…
Introduction
Software Project Management
M.S. Memon
What is Software?
• Software can be considered a product of

engineering just like an airplane, automobile,
television, or an other object that requires a
high degree of skill to turn a raw material into
a usable product.
• But software is developed or engineered, not
manufactured!
M.S. Memon
What is Software? (Contd.)
• Software can be of different types:
– System software
– Application software
– Engg./Scientific software
– Embedded software
– Product-line software
– Web-applications
– Artificial Intelligence software
– etc.
M.S. Memon
What is a Project ?
– It is a temporary endeavor (having specific start and
completion dates) undertaken to create a unique
product or service
M.S. Memon
What is a Project ?
• Temporary
– It means that every project has a definite beginning and
definite end
• End is reached when project’s objectives have been achieved
OR it is clear that objective will not be met. The project is
terminated in such a situation
– The term temporary does not apply to a project’s
product or service (which is a lasting result)
• Unique
– It means that the product or service is different in some
distinguishing way from all similar products or services
M.S. Memon
What is a Project ? (Contd.)
• Projects may involve a single person or thousands
• Projects may be completed in hours, several
months or years
• Examples of projects
– Developing a new product or service
– Designing a new vehicle
– Constructing a building
– Running a campaign for political office
– Implementing a new business procedure or process
– And so on …
M.S. Memon
What is Management?
• It is a set of activities and tasks undertaken by one

or more persons for the purpose of planning &
controlling the activities of others in order to
achieve an objective or complete an activity that
could not be achieved by others acting
independently.
M.S. Memon
What is Management? (Contd.)
• Components of Management:
– Planning
– Organizing
– Staffing
– Directing (Leading)
– Controlling
M.S. Memon
What is Management?
(Contd.)
• Planning
– Pre-determining course of action to achieve the objectives
• Organizing
– Establishing relationship among work units and granting
responsibility and authority to obtain the objectives
• Staffing
– Selecting and training people
• Directing (Leading)
– Creating an atmosphere that will assist & motivate people to
achieve the desired end results
• Controlling
– Establishing, measuring, and evaluating performance of activities
towards planned objectives
M.S. Memon
What is Project Management ?
• It is the discipline of planning, organizing, and

managing resources to bring about the successful
completion of specific project goals and objectives
M.S. Memon
Project Management (Contd.)
• Following are related to Project Management

– Professional Organizations
• Project Management Institute (PMI) (pmi.org)
• Software Engineering Institute (SEI)
• IEEE Software Engineering Group
– Certifications (offered by PMI)
• PMP (Project Management Professional)
• CAPM (Certified Associate in Project Management)
– PMBOK – Project Management Body of Knowledge, published by
PMI
– Tools
• MS Project
• Primavera Project Manager
M.S. Memon
Management
Project
Management
Software
Project
Management
M.S. Memon
• A sub-discipline of project management in
which software projects are planned, monitored
and controlled
M.S. Memon
(Contd.)
• Software development is a complex undertaking

particularly when it involves many people working over
a relatively long time.
• Hence software development projects need to be
managed.
• Everyone involved “manages” to some extent, but the
scope of management activities varies for every person.
M.S. Memon
Managerial Skills
• Robert L. Katz identified three kinds of skills for
administrators*. The fourth may be added to it.
– Technical skills
– Human skills
– Conceptual skills
– Design skills
M.S. Memon
Managerial Skills (Contd.)
• Technical skills
– Knowledge of & proficiency in activities involving methods,
processes & procedures.
– Working with tools & specific techniques.
• Human skills
– Ability to work with people.
– Cooperative effort, team work.
– Creating a conducive environment for people/ workers.
M.S. Memon
Managerial Skills (Contd.)
• Conceptual skills
– Ability to see the “big picture”.
– Ability to recognize significant elements in a situation &
to understand the relationship among them.
• Design skills
– Ability to solve problems that will eventually benefit the
enterprise.
– The skill to design effective & practical solutions to
problems rather than becoming “problem watcher” only.
– Important for upper level managers.
M.S. Memon
Skills Vs. Management Levels in
Organizational Hierarchy
Conceptual &
Top Management
Design Skills
Middle Management
Human Skills
Supervisors
Technical Skills
M.S. Memon
Project Management Skills
• Project Management Skills (in simple words)
– Leadership
– Communications
– Problem Solving
– Negotiating
– Influencing the Organization
– Mentoring
– Process and technical expertise
M.S. Memon
SOFTWARE PROJECT
MANAGEMENT
• “The SW Project Management Process
begins with a set of activities that are
collectively called “Project Planning”.
M.S. Memon
7/1/2019 CSE Deptt., QUEST 27
ESTIMATING/ ESTIMATION
• 1st activity of Project Planning is Estimation.
• Whenever estimates are made we look at future & accept
some degree of uncertainty as a matter of course.
• A leading executive is that who know that what will go
wrong before it actually does & the courage to estimate
when the future is cloudy.
• Estimation pr resources cost & schedule for a
SW development effort requires experience,
access to good historical information
M.S. Memon
• PROJECT COMPLEXITY:
• Project complexity has a strong effect on uncertainty that is
inherent in planning. A no: of quantitative measure have been
proposed, such measures are proposed to be applied at SW
planning.
• PROJECT SIZE:
• Project Size is another factor that can affect the accuracy of
estimates. As size increase, the interdependency among various
elements of the SW grows rapidly.
• PROBLEM DECOMPOSITION:
• Problem Decomposition is an important approach to do
estimating but can be formidable (dangerous).
M.S. Memon
• DEGREE OF STRUCTURAL UNCERTAINTY:
• Degree of Structural Uncertainty also has an effect on estimation Risk,
Structure refers to the degree to which requirements have been solidified.
• The availability of historical information also determines estimation risk.
• Risk is measured by the degree of uncertainty in the quantitative estimates
established for resources, cost & schedule.
• The planner & more important customer should recognize that
availability in SW requirements means instability in cost & schedule.
• Finally a Project Manager should not become obsessive about
Estimation; Modern SWE approaches take an iterative view of
development because in these approaches it is possible to
revise the estimate & change made according to customers’
choice
M.S. Memon
SOFTWARE SCOPE
• The first activity in software project planning is the
determination of software scope. Function and performance
allocated to software should be assessed to establish a software
scope.
• Software scope describes Function, Performance, Constraints,
and Interfaces.
• FUNCTIONS:
– Function refers to all activities and function performed
by system.
• PERFORMANCE:
– Performance refers to processing and response time
requirements.
M.S. Memon
• CONSTRAINS:
– Constraints identify the limits placed on the software by external
hardware, available memory or other existing system.
• For scope it is necessary to obtains information, and the most common technique
into get communication between customer and developer to start the process
conducting meeting and interview as often no needed.
• Try to understand his/her goals and requirements or constrains not only in this
way that what they think but what they need.
• Government often provides procurement after in detail written specification on
what they want.
• For communication these must be set of context free questions focus on the
customer as:
• OVERALL GOALS:
• Overall goals are defined that Who’s Request, What Benefit, Who else
has solution.
M.S. Memon
• 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.
• :
M.S. Memon
PROJECT PLANNING
OBJECTIVES
• The objectives of software project planning are frame
work that enables the mangers to make responsible
estimate of source, cost, and schedule.
• Those estimates are made with limited time frame at the
beginning of the software project and should be updated
regularly as the project progress.
• In conditions estimates should be attempted to
define ‘Best Case’ and ‘Worst Case’ sceneries so
that project outcomes can be bounded
M.S. Memon
THE COCOMO MODEL
• Barry Boehm introduces a hierarchy if software estimation models
bearing the name COCOMO (Constructive Cost Model).
• Barry Boehm’s hierarchy of model takes the following form.
• MODEL-01:
• The basic COCOMO model computes software development effort
and cost as a faction of program size estimated lines of codes
• MODEL-02:
• The intermediate COCOMO model computes software development
effort as a function of program size and a set of ‘Cost Drivers’ that
includes subjective assessments of product, hardware, personal and
project attribute.
M.S. Memon
• MODEL-03:
• The advance COCOMO model incorporates all characteristics of the
intermediate versions with the an assessment of the cost drivers
impact on each step (Analysis, Design. Etc) of the software purpose.
• The COCOMO models are defined for three classes of Software
Projects.
• ORGANIC MODEL:
• This for relatively small, simple projects in which small teams with
good application experience work to a set of less than rigid
requirements.
• SEMI-DETACHED MODEL:
• This for intermediate (In Size & Complexity) software projects in
which team with mixed experience level must meet a mix rigid and
less than rigid requirements.
M.S. Memon
• EMBEDED MODEL
• This is a software project the must be developed within a set of tight hardware, software and
operational constraints.
• The basic COCOMO equation take the form:
• E= a b KLOC b b
• D=CbEd b
• Where: E is effort applied in person-month
• D is development time in months
• KLOC is Estimated no. of delivered lines of code
• a b & c b are coefficients and b b & d b are exponents.
• The basic model is extended to consider a set of ‘Cost Driver Attributes’ that can be grouped
into four categories:
• Product Attributes
• Hardware Attribute
• Personnel Attributes
• Project attributes
M.S. Memon
• PP is an approach to provide a frame work that enables the manager to make
reasonable estimates of resources, cot, and schedule.
– ESTIMATION:
• Estimation is a process of getting brief knowledge about resources cot and schedule.
Estimation is made within a limited time frame at a beginning of a software project
and should be update regularly as the project progresses.
– FACTOR EFFECTING THE ESTIMATION
• PROJECT COMPLEXITY:
• Project complexity has a strong effect on the uncertainty inherit in planning
complexity is a relative measure that is effected by past experience.
• PROJECT SIZE:
• As the project size increase the interdependency among various element of the SW
grows rapidly. Problem decomposition an important approach to estimating becomes
more difficult b/c decomposed elements may still be formidable.
• DEGREE OF STRUCTURAL UNCERTAINTY:
• The degree to which requirements are have been solidified and the hierarchical nature
of the information that must be processed.
M.S. Memon
• OBTAINING INFROMATION NECESSARY FOR SCOPE
• Obtaining information necessary for scope:
• The most commonly used technique to bridge the communicating gap b/w the
customer and develop and to get the communication process started is to conduct a
preliminary meeting or interview.
• Analyst start by asking context free question
• First set of context free questions:
• Who is behind the request for this work
• Who will use the solution
• What will be the economic benefit of a successful solution?
• Is their source for the solution?
• The next set of questions enables the analyst to gain a better understanding of the
problem.
– How would you characterized good output
– What problem will this solution address
– Can you show me the environment in which solution will be used.
– Will any special performance issue or constraints affect the way the solution is
approached?
M.S. Memon
•
• Final set of questions
– Are you the right person to answer these questions or answers official.
– Are my questions relevant to the problem that you have.
– Am I asking too many questions
– Can any one else provide additional information.
• FEASIBILITY
• Communication with the customer loads to definition of data.
• Function that must be implemented.
• Performance and constraints that bound the system.
• Related information
• Once scope has been identified, it is reasonable to ask
– Can we build the software to meet this scope?
– Is this project is feasible?
M.S. Memon
– RESOURCES:
• The second SW planning task is estimation of
the resources required to an accomplished the
SW development effort the above figure
illustrate the resources as a pyramid.
M.S. Memon
HARDWARE AND S/W TOOLS:
• These determine the development environment. The environment that
support the SW projects, after called SWE environment incorporates
hardware & SW. Hardware provides a platform that support the tools,
software) required to produce the work products that are in outcome good
software engineering practice. A project planner must describes the time
window required for hardware and software verify that these resources will
available.
REUSEABLE SOFTWARE COMPONENTS:
• Reusable software of the components that must be cataloged for easy
reference standardized for easy integration.
• Types of reusable software
M.S. Memon
OFF-THE-SHELF COMPONENTS:
• Existing SW that can be acquired from the third party or that has been
developed for a past project.
FULL EXPERIENCE COMPONENTS:
• Existing specifications, design, code or test data developed for past project
that are similar to the SW to be build for the current project. Member of the
current S/W team have had full experience in the application are represented
by these components.
PARTIAL EXPERIENCE COMPONENTS:
• Existing specification, designers, code or test data developed for past project
hat are related to the software to be build for the current project hat will
required go modification.
• Member of the SW have only limited experience in the application area
represented by these components.
M.S. Memon
– PEOPLE
• After evaluating scope the skills required to complete development must be
evaluated. These include following.
• Organizational position (Managers SW)
• Specialty (Telecommunication , database, client server)
• For small project a signal individual can perform SWE task consulting with
specialist as required.
• The no. of people required for the SW project can be determined only after
an estimation of development effort is made.
– DECOMPOSITION:
• Software project estimation is a form of problem solving & the most cases
the problem to be solve ( that is developing cost of effort, estimate for a SW
project is too complex to be consider in one piece for this reason we
decompose the problem dividing it as a set of smaller (Hopefully most
manageable) problems.
M.S. Memon
– COMPOSITION TECHNOLOGIES:
• SOFTWARE SIZING:
• Sizing represents the project planner 1st major challenge. In the context of project
planning size refers to a quantifiable outcome of the SW project.
APPROACH TO THE SIZING PROBLEM:

• FIZZY LOGIC SIZING:
• To apply this approach, the planner must identify the type of application, establish, its
magnitude on the qualitative scale, and then refine the magnitude within the original
range. Although personal experience can be used, the planner should also have access
to a historical database of the project.
M.S. Memon
STANDARD COMPONENTS SIZING:
• Software composed of a no. of different standards components that all
generic to a particular application area for example. The standard components
for an information system or subsystem, module, screen, reports, interactive
programs, and files. The project planner estimates the no. of occurrence of
each standard component and then uses historical project data to determine
the delivered size per standard components.
CHANGE SIZING:
• This approach is used when a project used existing software that must be
modified in some way as part of a project.
• The planner estimates the no. and type for example (reuse adding code,
changing code, and deleting code) of modifications that must be
accomplished.
M.S. Memon
4Ps
SW Project Management discusses about 4Ps:

• People
• Process
• Problem
• Product
These 4Ps are collectively are conducted on
Project

4Ps
Software Project Management focuses on four points: People, Problem, &
Process.
THREE POINTS
PEOPLE
PROBLEM
PROCESSES PRODUCTS

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.

• 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.

ISSUES OF PM

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.

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

– 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.

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.

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.

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.

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 (covered in detail in the later session)
• 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

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.

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.

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.

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

• 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.
• :
M.S. Memon
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.

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.

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.

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.

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
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.

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.

Software Project Estimation
• Precise estimation is difficult. So, make three

estimates: optimistic, most likely, and
pessimistic. Then combine as:
EV=(Sopt + 4Sm + Spess)/6
72
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
73

CH1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CH1

Hochgeladen von

Copyright:

Verfügbare Formate

INTRODUCTION

7/1/2019 M. S. Memon, CSE Deptt. QUEST 2

• Managing people, process and problems during a

Software Project Management

• Software can be considered a product of

• It is a set of activities and tasks undertaken by one

• It is the discipline of planning, organizing, and

• Following are related to Project Management

• Software development is a complex undertaking

APPROACH TO THE SIZING PROBLEM:

SW Project Management discusses about 4Ps:

7/1/2019 M. S. Memon, CSE Deptt. QUEST 47

7/1/2019 M. S. Memon, CSE Deptt. QUEST 49

7/1/2019 M. S. Memon, CSE Deptt. QUEST 50

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

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

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

7/1/2019 M. S. Memon, CSE Deptt. QUEST 51

7/1/2019 M. S. Memon, CSE Deptt. QUEST 52

7/1/2019 M. S. Memon, CSE Deptt. QUEST 53

7/1/2019 M. S. Memon, CSE Deptt. QUEST 54

7/1/2019 M. S. Memon, CSE Deptt. QUEST 55

7/1/2019 M. S. Memon, CSE Deptt. QUEST 56

7/1/2019 M. S. Memon, CSE Deptt. QUEST 57

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

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

4. A ‘Synchronous Paradigm’ relies on natural compartmentalization of

7/1/2019 M. S. Memon, CSE Deptt. QUEST 58

• When planning the structure of software engineering teams, the

7/1/2019 M. S. Memon, CSE Deptt. QUEST 59

7/1/2019 M. S. Memon, CSE Deptt. QUEST 60

• For solving problems with low modularity

7/1/2019 M. S. Memon, CSE Deptt. QUEST 61

7/1/2019 M. S. Memon, CSE Deptt. QUEST 62

7/1/2019 M. S. Memon, CSE Deptt. QUEST 63

7/1/2019 M. S. Memon, CSE Deptt. QUEST 65

7/1/2019 M. S. Memon, CSE Deptt. QUEST 66

7/1/2019 M. S. Memon, CSE Deptt. QUEST 67

7/1/2019 M. S. Memon, CSE Deptt. QUEST 68

7/1/2019 M. S. Memon, CSE Deptt. QUEST 70

• 90 – 90 Rule: “The first 90% of the system absorb 90% of the

7/1/2019 M. S. Memon, CSE Deptt. QUEST 71

• Precise estimation is difficult. So, make three

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

• Develop specification for desired software

 Select candidate applications that come closest to meeting specifications.

 Select reusable components that could assist constructing the required

 Develop comparison matrix that compares key functions and costs.

Das könnte Ihnen auch gefallen