SVCE TIRUPATI

COURSE MATERIAL

SOFTWARE PROJECT MANAGEMENT

SUBJECT (20A05504a)

UNIT 1

COURSE B.TECH

DEPARTMENT COMPUTER SCIENCE & ENGINEERING

SEMESTER 31

Mrs G T Prasanna Kumari

PREPARED BY
MrsN. Divya
(Faculty Name/s) Assistant Professor

Version V-1

PREPARED / REVISED DATE 29-09-2022

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

TABLE OF CONTENTS – UNIT 1

S. NO CONTENTS PAGE NO.
1 COURSE OBJECTIVES 1
2 PREREQUISITES 1
3 SYLLABUS 1
4 COURSE OUTCOMES 1
5 CO - PO/PSO MAPPING 2
6 LESSON PLAN 2
7 ACTIVITY BASED LEARNING 2
8 LECTURE NOTES 2
1.1 CONVENTIONAL SOFTWARE MANAGEMENT 2

1.2 THE WATERFALL MODEL 3

1.3 CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE 9

1.4 SOFTWARE ECONOMICS 9

1.5 PRAGMATIC SOFTWARE COST ESTIMATION 12

9 PRACTICE QUIZ 14
10 ASSIGNMENTS 15
11 PART A QUESTIONS & ANSWERS (2 MARKS QUESTIONS) 15
12 PART B QUESTIONS 17
13 SUPPORTIVE ONLINE CERTIFICATION COURSES 17
14 REAL TIME APPLICATIONS 17
15 CONTENTS BEYOND THE SYLLABUS 17
16 PRESCRIBED TEXT BOOKS & REFERENCE BOOKS 18
17 MINI PROJECT SUGGESTION 18

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
1. Course Objectives
The objectives of this course is to
1. Understanding the specific roles within a software organization as related to
project and process management
2. Describe the principles, techniques, methods & tools for model-based
management of software projects, assurance of product quality and process
adherence (quality assurance), as well as experience-based creation &
improvement of models (process management).
3. Understanding the basic infrastructure competences (e.g., process modelling
and measurement)
4. Understanding the basic steps of project planning, project management,
quality assurance, and process management and their relationships

2. Prerequisites
Students should have knowledge on
1. Software Engineering

3. Syllabus
UNIT I
Conventional Software Management: The waterfall model, conventional software
Management performance.
Evolution of Software Economics: Software Economics, pragmatic software cost
estimation
Improving Software Economics: Reducing Software product size, improving software
processes, improving team effectiveness, improving automation, Achieving required
quality, peer inspections.

4. Course outcomes
1. Describe and determine the purpose and importance of project management
from the perspectives of planning, tracking and completion of project.
2. Compare and differentiate organization structures and project structures
3. Implement a project to manage project schedule, expenses and resources with
the application of suitable project management tools.

1|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

5. Co-PO / PSO Mapping

Software
Project PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 P10 PO11 PO12 PSO1 PSO2
Management
CO1 3 3 3 2 2 2 2 2 2 2

CO2 3 2 2 2 2 2 2 2

CO3 3 2 2 2 2 2 2

6. Lesson Plan

Lecture No. Weeks Topics to be covered References

1 Conventional software Management T1, R1

2 The waterfall model T1, R1

1
The waterfall model
3 T1, R1

4 Conventional software Management performance T1, R1

5 Evolution of Software Economics T1, R1

6 Software Economics T1, R1

2
7 Software Economics T1, R1

8 pragmatic software cost estimation T1, R1

9 Reducing Software product size T1, R1

10 Improving software processes T1, R1

11 Improving team effectiveness T1, R1

3
12 Improving automation T1, R1

13 Achieving required quality T1, R1

14 Peer inspections T1, R1

16 Discussion of objective type questions & Short answer questions T1, R1

4
17 Discussion of Previous year university questions in question papers T1, R1

7. Activity Based Learning

1. Based on the waterfall model, designing the sample project
2|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
2. Identifying the various software economics for case study project
8. Lecture Notes
1.1 Conventional software management
Conventional software management practices are sound in theory, but practice is still
tied to archaic (outdated) technology and techniques.

Conventional software economics provides a benchmark of performance for

conventional software management principles.

The best thing about software is its flexibility: It can be programmed to do almost
anything.
The worst thing about software is also its flexibility: The "almost anything" characteristic
has made it difficult to plan, monitors, and control software development.

Three important analyses of the state of the software engineering industry are
1.Software development is still highly unpredictable. Only about 10% of software
projects are delivered successfully within initial budget and schedule estimates.
2.Management discipline is more of a discriminator in success or failure than are
technology advances.
3.The level of software scrap and rework is indicative of an immature process.
All three analyses reached the same general conclusion: The success rate for software
projects is very low. The three analyses provide a good introduction to the magnitude of
the software problem and the current norms for conventional software management
performance.

1.2 THE WATERFALL MODEL

Most software engineering texts present the waterfall model as the source of the "con-
ventional" software process
1.2.1 IN THEORY
It provides an insightful and concise summary of conventional software management
Three main primary points are
1.There are two essential steps common to the development of computer programs:
analysis and coding.
Waterfall Model part 1: The two basic steps to building a program.

Analysis Analysis and coding both involve creative

work that directly contributes to the
usefulness of the end product.
Coding

2. In order to manage and control all of the intellectual freedom associated with software
development, one must introduce several other "overhead" steps, including system
requirements definition, software requirements definition, program design, and testing.

3|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
These steps supplement the analysis and coding steps. Below Figure illustrates the resulting
project profile and the basic steps in developing a large-scale program.

Requirement

Analysis

Design

Coding

Testing

Operation
3. The basic framework described in the waterfall model is risky and invites failure. The
testing phase that occurs at the end of the development cycle is the first event for which
timing, storage, input/output transfers, etc., are experienced as distinguished from
analyzed. The resulting design changes are likely to be so disruptive that the software
requirements upon which the design is based are likely violated. Either the requirements
must be modified or a substantial design change is warranted.

Five necessary improvements for waterfall model are:-

1. Program design comes first. Insert a preliminary program design phase between
the software requirements generation phase and the analysis phase. By this
technique, the program designer assures that the software will not fail because of
storage, timing, and data flux (continuous change). As analysis proceeds in the
succeeding phase, the program designer must impose on the analyst the storage,
timing, and operational constraints in such a way that he senses the consequences.
If the total resources to be applied are insufficient or if the embryonic(in an early
stage of development) operational design is wrong, it will be recognized at this
early stage and the iteration with requirements and preliminary design can be
redone before final design, coding, and test commences. How is this program
design procedure implemented?

The following steps are required:

Begin the design process with program designers, not analysts or programmers.
Design, define, and allocate the data processing modes even at the risk of being wrong.
Allocate processing functions, design the database, allocate execution time, define
interfaces and processing modes with the operating system, describe input and output
processing, and define preliminary operating procedures.
Write an overview document that is understandable, informative, and current so that
every worker on the project can gain an elemental understanding of the system.

2. Document the design. The amount of documentation required on most software

programs is quite a lot, certainly much more than most programmers, analysts, or
4|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
program designers are willing to do if left to their own devices. Why do we need so
much documentation? (1) Each designer must communicate with interfacing
designers, managers, and possibly customers. (2) During early phases, the
documentation is the design. (3) The real monetary value of documentation is to
support later modifications by a separate test team, a separate maintenance
team, and operations personnel who are not software literate.

3.Do it twice. If a computer program is being developed for the first time, arrange
matters so that the version finally delivered to the customer for operational
deployment is actually the second version insofar as critical design/operations are
concerned. Note that this is simply the entire process done in miniature, to a time
scale that is relatively small with respect to the overall effort. In the first version, the
team must have a special broad competence where they can quickly sense
trouble spots in the design, model them, model alternatives, forget the
straightforward aspects of the design that aren't worth studying at this early point,
and, finally, arrive at an error-free program.

4.Plan, control, and monitor testing. Without question, the biggest user of project
resources-manpower, computer time, and/or management judgment-is the test
phase. This is the phase of greatest risk in terms of cost and schedule. It occurs at
the latest point in the schedule, when backup alternatives are least available, if at
all. The previous three recommendations were all aimed at uncovering and solving
problems before entering the test phase. However, even after doing these things,
there is still a test phase and there are still important things to be done, including: (1)
employ a team of test specialists who were not responsible for the original design;
(2) employ visual inspections to spot the obvious errors like dropped minus signs,
missing factors of two, jumps to wrong addresses (do not use the computer to
detect this kind of thing, it is too expensive); (3) test every logic path; (4) employ the
final checkout on the target computer.

5. Involve the customer. It is important to involve the customer in a formal way so

that he has committed himself at earlier points before final delivery. There are three
points following requirements definition where the insight, judgment, and
commitment of the customer can bolster the development effort. These include a
"preliminary software review" following the preliminary program design step, a
sequence of "critical software design reviews" during program design, and a "final
software acceptance review".

1.2.2 IN PRACTICE
Some software projects still practice the conventional software management approach.

5|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
It is useful to summarize the characteristics of the conventional process as it has typically
been applied, which is not necessarily as it was intended. Projects destined for trouble
frequently exhibit the following symptoms:

Protracted integration and late design breakage.

Late risk resolution.
Requirements-driven functional decomposition.
Adversarial (conflict or opposition) stakeholder relationships.
Focus on documents and review meetings.

Protracted Integration and Late Design Breakage

For a typical development project that used a waterfall model management process,
Figure 1-2 illustrates development progress versus time. Progress is defined as percent
coded, that is, demonstrable in its target form.

The following sequence was common:

Early success via paper designs and thorough (often too thorough) briefings.
Commitment to code late in the life cycle.
Integration nightmares (unpleasant experience) due to unforeseen
implementation issues and interface ambiguities.
Heavy budget and schedule pressure to get the system working.
Late shoe-homing of no optimal fixes, with no time for redesign.
A very fragile, unmentionable product delivered late.

6|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

Figure 1-2: Progress profile of a conventional software Project

In the conventional model, the entire system was designed on paper, then implemented
all at once, then integrated. Table 1-1 provides a typical profile of cost expenditures
across the spectrum of software activities.

Table 1-1: Expenditures of by activity for a conventional software project

Late risk resolution A serious issue associated with the waterfall lifecycle was the lack of
early risk resolution. Figure 1.3 illustrates a typical risk profile for conventional waterfall
model projects. It includes four distinct periods of risk exposure, where risk is defined as
the probability of missing a cost, schedule, feature, or quality goal. Early in the life cycle,
as the requirements were being specified, the actual risk exposure was highly
unpredictable.

7|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

Figure 1.3: risk profile

Requirements-Driven Functional Decomposition: This approach depends on specifying

requirements completely and unambiguously before other development activities
begin. It naively treats all requirements as equally important, and depends on those
requirements remaining constant over the software development life cycle. These
conditions rarely occur in the real world. Specification of requirements is a difficult and
important part of the software development process.
Another property of the conventional approach is that the requirements were
typically specified in a functional manner. Built into the classic waterfall process was the
fundamental assumption that the software itself was decomposed into functions;
requirements were then allocated to the resulting components. This decomposition was
often very different from a decomposition based on object-oriented design and the use
of existing components. Figure 1-4 illustrates the result of requirements-driven
approaches: a software structure that is organized around the requirements specifica-
tion structure.

Adversarial Stakeholder Relationships:

8|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
The conventional process tended to result in adversarial stakeholder relationships, in
large part because of the difficulties of requirements specification and the exchange of
information solely through paper documents that captured engineering information in
ad hoc formats.

The following sequence of events was typical for most contractual software efforts:
1. The contractor prepared a draft contract-deliverable document that captured an
intermediate artifact and delivered it to the customer for approval.

2. The customer was expected to provide comments (typically within 15 to 30 days).

3. The contractor incorporated these comments and submitted (typically within 15 to 30

days) a final version for approval.
This one-shot review process encouraged high levels of sensitivity on the part of
customers and contractors.

Focus on Documents and Review Meetings:

The conventional process focused on producing various documents that attempted to
describe the software product, with insufficient focus on producing tangible increments
of the products themselves. Contractors were driven to produce literally tons of paper
to meet milestones and demonstrate progress to stakeholders, rather than spend their
energy on tasks that would reduce risk and produce quality software. Typically,
Presenters and the audience reviewed the simple things that they understood rather
than the complex and important issues. Most design reviews therefore resulted in low
engineering value and high cost in terms of the effort and schedule involved in their
preparation and conduct. They presented merely a facade of progress.

1.3 CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE

Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective

characterization of the state of software development.
1. Finding and fixing a software problem after delivery costs 100 times more than finding
and fixing the problem in early design phases.
2. You can compress software development schedules 25% of nominal, but no more.
3. For every $1 you spend on development, you will spend $2 on maintenance.
4. Software development and maintenance costs are primarily a function of the
number of source lines of code.
5. Variations among people account for the biggest differences in software
productivity.
6. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in
1985, 85:15.
7. Only about 15% of software development effort is devoted to programming.

9|S P M -UNI T-I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
8. Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software-system products (i.e., system of systems) cost 9 times as
much.
9. Walkthroughs catch 60% of the errors
10. 80% of the contribution comes from 20% of the contributors.

Evolution of Software Economics

1.4 SOFTWARE ECONOMICS

Most software cost models can be abstracted into a function of five basic parameters:
size, process, personnel, environment, and required quality.
1.The size of the end product (in human-generated components), which is typically
quantified in terms of the number of source instructions or the number of function
points required to develop the required functionality
2.The process used to produce the end product, in particular the ability of the
process to avoid non-value-adding activities (rework, bureaucratic delays,
communications overhead)
3.The capabilities of software engineering personnel, and particularly their
experience with the computer science issues and the applications domain issues of
the project
4.The environment, which is made up of the tools and techniques available to
support efficient software development and to automate the process
5.The required quality of the product, including its features, performance, reliability,
and adaptability
The relationships among these parameters and the estimated cost can be written as
follows:
Effort = (Personnel) (Environment) (Quality) ( Sizeprocess)

One important aspect of software economics (as represented within today's

software cost models) is that the relationship between effort and size exhibits a
diseconomy of scale. The diseconomy of scale of software development is a result of the
process exponent being greater than 1.0. Contrary to most manufacturing processes,
the more software you build, the more expensive it is per unit item.
Figure 1-5 shows three generations of basic technology advancement in
tools, components, and processes. The required levels of quality and personnel are
assumed to be constant. The ordinate of the graph refers to software unit costs (pick
your favorite: per SLOC, per function point, per component) realized by an organization.
The three generations of software development are defined as follows:

1) Conventional: 1960s and 1970s, craftsmanship. Organizations used custom tools,

custom processes, and virtually all custom components built in primitive languages.
Project performance was highly predictable in that cost, schedule, and quality
objectives were almost always underachieved.
10 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
2) Transition: 1980s and 1990s, software engineering. Organizations used more-repeatable
processes and off-the-shelf tools, and mostly (>70%) custom components built in higher
level languages. Some of the components (<30%) were available as commercial
products, including the operating system, database management system, networking,
and graphical user interface.
3) Modern practices: 2000 and later, software production. This book's philosophy is rooted
in the use of managed and measured processes, integrated automation
environments, and mostly (70%) off-the-shelf components. Perhaps as few as 30% of
the components need to be custom built

Technologies for environment automation, size reduction, and process improvement are
not independent of one another. In each new era, the key is complementary growth in all
technologies. For example, the process advances could not be used successfully without
new component technologies and increased tool automation.

Figure 1-5: Three generations of software economics leading to the target objective

Organizations are achieving better economies of scale in successive technology eras-

with very large projects (systems of systems), long-lived products, and lines of business
comprising multiple similar projects. Figure 1-6 provides an overview of how a return on

11 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
investment (ROI) profile can be achieved in subsequent efforts across life cycles of
various domains

Figure 1-6: Return on Investment in different domains

1.5 PRAGMATIC SOFTWARE COST ESTIMATION

One critical problem in software cost estimation is a lack of well-documented case

studies of projects that used an iterative development approach. Software industry has
inconsistently defined metrics or atomic units of measure, the data from actual projects
are highly suspect in terms of consistency and comparability. It is hard enough to collect
a homogeneous set of project data within one organization; it is extremely difficult to
homogenize data across different organizations with different processes, languages,
domains, and so on.
There have been many debates among developers and vendors of software cost
estimation models and tools. Three topics of these debates are of particular interest
here:
1.Which cost estimation model to use?
2.Whether to measure software size in source lines of code or function points.
3.What constitutes a good estimate?
There are several popular cost estimation models (such as COCOMO, CHECKPOINT,
ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20), CO
12 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
COMO is also one of the most open and well-documented cost estimation models. The
general accuracy of conventional cost models (such as COCOMO) has been described
as "within 20% of actual, 70% of the time."
Most real-world use of cost models is bottom-up (substantiating a target cost) rather than
top-down (estimating the "should" cost). Figure 2-3 illustrates the predominant practice:
The software project manager defines the target cost of the software, and then
manipulates the parameters and sizing until the target cost can be justified. The rationale
for the target cost maybe to win a proposal, to solicit customer funding, to attain internal
corporate funding, or to achieve some other goal.
The process described in Figure 1-7 is not all bad. In fact, it is absolutely necessary to
analyze the cost risks and understand the sensitivities and trade-offs objectively. It forces
the software project manager to examine the risks associated with achieving the target
costs and to discuss this information with other stakeholders.
A good software cost estimate has the following attributes:
 It is conceived and supported by the project manager, architecture team,
development team, and test team accountable for performing the work.
 It is accepted by all stakeholders as ambitious but realizable.
 It is based on a well-defined software cost model with a credible basis.
 It is based on a database of relevant project experience that includes similar
processes, similar technologies, similar environments, similar quality requirements,
and similar people.
 It is defined in enough detail so that its key risk areas are understood and the
probability of success is objectively assessed.
Extrapolating from a good estimate, an ideal estimate would be derived from a mature
cost model with an experience base that reflects multiple similar projects done by the
same team with the same mature processes and tools.

Figure 1-7: The predominant cost estimation process

1.6 REDUCING SOFTWARE PRODUCT SIZE
The most significant way to improve affordability and return on investment (ROI) is usually
to produce a product that achieves the design goals with the minimum amount of

13 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
human-generated source material. Component-based development is introduced as
the general term for reducing the "source" language size to achieve a software solution.

Reuse, object-oriented technology, automatic code production, and higher order

programming languages are all focused on achieving a given system with fewer lines of
human-specified source directives (statements).

size reduction is the primary motivation behind improvements in higher order languages
(such as C++, Ada 95, Java, Visual Basic), automatic code generators (CASE tools, visual
modeling tools, GUI builders), reuse of commercial components (operating systems,
windowing environments, database management systems, middleware, networks), and
object-oriented technologies (Unified Modeling Language, visual modeling tools,
architecture frameworks).
The reduction is defined in terms of human-generated source material. In general, when
size-reducing technologies are used, they reduce the number of human-generated
source lines.

1.6.1 LANGUAGES
Universal function points (UFPs) are useful estimators for language-independent, early
life-cycle estimates. The basic units of function points are external user inputs, external
outputs, internal logical data groups, external data interfaces, and external inquiries.
SLOC metrics are useful estimators for software after a candidate solution is formulated
and an implementation language is known. Substantial data have been documented
relating SLOC to function points. Some of these results are shown in Table 3-2.
Languages expressiveness of some of today’s popular languages
LANGUAGES SLOC per UFP
Assembly 320
C 128
FORTAN77 105
COBOL85 91
Ada83 71
C++ 56
Ada95 55
Java 55
Visual Basic 35
Table 3-2

1.6.2 OBJECT-ORIENTED METHODS AND VISUAL MODELING

Object-oriented technology is not germane to most of the software management topics
discussed here, and books on object-oriented technology abound. Object-oriented
14 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
programming languages appear to benefit both software productivity and software
quality. The fundamental impact of object-oriented technology is in reducing the overall
size of what needs to be developed.
People like drawing pictures to explain something to others or to themselves. When they
do it for software system design, they call these pictures diagrams or diagrammatic
models and the very notation for them a modeling language.

These are interesting examples of the interrelationships among the dimensions of

improving software economics.
1.An object-oriented model of the problem and its solution encourages a common
vocabulary between the end users of a system and its developers, thus creating a
shared understanding of the problem being solved.
2.The use of continuous integration creates opportunities to recognize risk early and
make incremental corrections without destabilizing the entire development effort.
3.An object-oriented architecture provides a clear separation of concerns among
disparate elements of a system, creating firewalls that prevent a change in one
part of the system from rending the fabric of the entire architecture.

Booch also summarized five characteristics of a successful object-oriented project.

1.A ruthless focus on the development of a system that provides a well understood
collection of essential minimal characteristics.
2.The existence of a culture that is centered on results, encourages communication,
and yet is not afraid to fail.
3.The effective use of object-oriented modeling.
4.The existence of a strong architectural vision.
5.The application of a well-managed iterative and incremental development life
cycle.

1.6.3 REUSE
Reusing existing components and building reusable components have been natural
software engineering activities since the earliest improvements in programming lan-
guages. With reuse in order to minimize development costs while achieving all the other
required attributes of performance, feature set, and quality. Try to treat reuse as a
mundane part of achieving a return on investment.
Most truly reusable components of value are transitioned to commercial products
supported by organizations with the following characteristics:
They have an economic motivation for continued support.
They take ownership of improving product quality, adding new features, and
transitioning to new technologies.
They have a sufficiently broad customer base to be profitable.
The cost of developing a reusable component is not trivial. Figure 3-1 examines the
economic trade-offs. The steep initial curve illustrates the economic obstacle to
developing reusable components.
15 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
Reuse is an important discipline that has an impact on the efficiency of all workflows and
the quality of most artifacts.

1.6.4 COMMERCIAL COMPONENTS

A common approach being pursued today in many domains is to maximize integration
of commercial components and off-the-shelf products. While the use of commercial
components is certainly desirable as a means of reducing custom development, it has
not proven to be straightforward in practice. Table 3-3 identifies some of the advantages
and disadvantages of using commercial components.

1.7 IMPROVING SOFTWARE PROCESSES

Process is an overloaded term. Three distinct process perspectives are.
 Metaprocess: an organization's policies, procedures, and practices for pursuing a
software-intensive line of business. The focus of this process is on organizational
economics, long-term strategies, and software ROI.
 Macroprocess: a project's policies, procedures, and practices for producing a
complete software product within certain cost, schedule, and quality constraints.

16 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
The focus of the macro process is on creating an adequate instance of the Meta
process for a specific set of constraints.
 Microprocess: a project team's policies, procedures, and practices for achieving an
artifact of the software process. The focus of the micro process is on achieving an
intermediate product baseline with adequate quality and adequate functionality
as economically and rapidly as practical.
Although these three levels of process overlap somewhat, they have different
objectives, audiences, metrics, concerns, and time scales as shown in Table 3-4

In a perfect software engineering world with an immaculate problem description, an

obvious solution space, a development team of experienced geniuses, adequate
resources, and stakeholders with common goals, we could execute a software
development process in one iteration with almost no scrap and rework. Because we
work in an imperfect world, however, we need to manage engineering activities so that
scrap and rework profiles do not have an impact on the win conditions of any
stakeholder. This should be the underlying premise for most process improvements.

1.8 IMPROVING TEAM EFFECTIVENESS

Teamwork is much more important than the sum of the individuals. With software teams,
a project manager needs to configure a balance of solid talent with highly skilled
people in the leverage positions. Some maxims of team management include the
following:
 A well-managed project can succeed with a nominal engineering team.
 A mismanaged project will almost never succeed, even with an expert team of
engineers.
 A well-architected system can be built by a nominal team of software builders.
 A poorly architected system will flounder even with an expert team of builders.

Boehm five staffing principles are

1. The principle of top talent: Use better and fewer people
2. The principle of job matching: Fit the tasks to the skills and motivation of the people
available.
17 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
3. The principle of career progression: An organization does best in the long run by
helping its people to self-actualize.
4. The principle of team balance: Select people who will complement and harmonize
with one another
5. The principle of phase-out: Keeping a misfit on the team doesn't benefit anyone

Software project managers need many leadership qualities in order to enhance team
effectiveness. The following are some crucial attributes of successful software project
managers that deserve much more attention:
1.Hiring skills. Few decisions are as important as hiring decisions. Placing the right
person in the right job seems obvious but is surprisingly hard to achieve.
2.Customer-interface skill. Avoiding adversarial relationships among stakeholders is
a prerequisite for success.
Decision-making skill. The jillion books written about management have failed to
provide a clear definition of this attribute. We all know a good leader when we run into
one, and decision-making skill seems obvious despite its intangible definition.
Team-building skill. Teamwork requires that a manager establish trust, motivate progress,
exploit eccentric prima donnas, transition average people into top performers, eliminate
misfits, and consolidate diverse opinions into a team direction.
Selling skill. Successful project managers must sell all stakeholders (including themselves)
on decisions and priorities, sell candidates on job positions, sell changes to the status quo
in the face of resistance, and sell achievements against objectives. In practice, selling
requires continuous negotiation, compromise, and empathy.

1.9 IMPROVING AUTOMATION THROUGH SOFTWARE ENVIRONMENTS

The tools and environment used in the software process generally have a
linear effect on the productivity of the process. Planning tools, requirements
management tools, visual modeling tools, compilers, editors, debuggers, quality
assurance analysis tools, test tools, and user interfaces provide crucial automation
support for evolving the software engineering artifacts. Above all, configuration
management environments provide the foundation for executing and instrument the
process. At first order, the isolated impact of tools and automation generally allows
improvements of 20% to 40% in effort. However, tools and environments must be viewed
as the primary delivery vehicle for process automation and improvement, so their impact
can be much higher.
Automation of the design process provides payback in quality, the ability to estimate
costs and schedules, and overall productivity using a smaller team.
Round-trip engineering describe the key capability of environments that support iterative
development. As we have moved into maintaining different information repositories for
the engineering artifacts, we need automation support to ensure efficient and error-free
transition of data from one artifact to another. Forward engineering is the automation of
one engineering artifact from another, more abstract representation. For example,

18 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
compilers and linkers have provided automated transition of source code into
executable code.
Reverse engineering is the generation or modification of a more abstract representation
from an existing artifact (for example, creating a .visual design model from a source
code representation).
Economic improvements associated with tools and environments. It is common for tool
vendors to make relatively accurate individual assessments of life-cycle activities to
support claims about the potential economic impact of their tools. For example, it is easy
to find statements such as the following from companies in a particular tool.
 Requirements analysis and evolution activities consume 40% of life-cycle costs.
 Software design activities have an impact on more than 50% of the resources.
 Coding and unit testing activities consume about 50% of software development
effort and schedule.
 Test activities can consume as much as 50% of a project's resources.
 Configuration control and change management are critical activities that can
consume as much as 25% of resources on a large-scale project.
 Documentation activities can consume more than 30% of project engineering
resources.
 Project management, business administration, and progress assessment can
consume as much as 30% of project budgets.

1.10 ACHIEVING REQUIRED QUALITY

Software best practices are derived from the development process and technologies.
Table 3-5 summarizes some dimensions of quality improvement.
Key practices that improve overall software quality include the following:
 Focusing on driving requirements and critical use cases early in the life cycle,
focusing on requirements completeness and traceability late in the life cycle, and
focusing throughout the life cycle on a balance between requirements evolution,
design evolution, and plan evolution
 Using metrics and indicators to measure the progress and quality of an architecture
as it evolves from a high-level prototype into a fully compliant product
 Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods, document
automation, and regression test automation
 Using visual modeling and higher level languages that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-based
evaluations

19 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

Conventional development processes stressed early sizing and timing estimates of

computer program resource utilization. However, the typical chronology of events in
performance assessment was as follows
 Project inception. The proposed design was asserted to be low risk with adequate
performance margin.
 Initial design review. Optimistic assessments of adequate design margin were based
mostly on paper analysis or rough simulation of the critical threads. In most cases,
the actual application algorithms and database sizes were fairly well understood.
 Mid-life-cycle design review. The assessments started whittling away at the margin,
as early benchmarks and initial tests began exposing the optimism inherent in
earlier estimates.
 Integration and test. Serious performance problems were uncovered, necessitating
fundamental changes in the architecture. The underlying infrastructure was usually
the scapegoat, but the real culprit was immature use of the infrastructure,
immature architectural solutions, or poorly understood early design trade-offs.

1.11 PEER INSPECTIONS: A PRAGMATIC VIEW

Peer inspections are frequently over hyped as the key aspect of a quality system. In my
experience, peer reviews are valuable as secondary mechanisms, but they are rarely
significant contributors to quality compared with the following primary quality
mechanisms and indicators, which should be emphasized in the management process:
 Transitioning engineering information from one artifact set to another, thereby
assessing the consistency, feasibility, understandability, and technology constraints
inherent in the engineering artifacts
 Major milestone demonstrations that force the artifacts to be assessed against
tangible criteria in the context of relevant use cases
 Environment tools (compilers, debuggers, analyzers, automated test suites) that
ensure representation rigor, consistency, completeness, and change control
 Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria,
and requirements compliance

20 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
 Change management metrics for objective insight into multiple-perspective
change trends and convergence or divergence from quality and progress goals
Inspections are also a good vehicle for holding authors accountable for quality
products. All authors of software and documentation should have their products
scrutinized as a natural by-product of the process. Therefore, the coverage of inspec-
tions should be across all authors rather than across all components.

Improving Software Economics

Five basic parameters of the software cost model are
1. Reducing the size or complexity of what needs to be developed.
2. Improving the development process.
3. Using more-skilled personnel and better teams (not necessarily the same thing).
4. Using better environments (tools to automate the process).
5. Trading off or backing off on quality thresholds.
These parameters are given in priority order for most software domains. Table 3-1 lists
some of the technology developments, process improvement efforts, and management
approaches targeted at improving the economics of software development and
integration.

9. Practice Quiz
1. Essential steps common to the development of computer programs
21 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
a) Analysis
b) Coding
c) Both (a) and (b)
d) None of the above
2. For every $1 you spent on development, you will spend _________ on maintenance
a) $3
b) $1
c)$2
d) $4
3. Software development and maintenance costs are primarily a function of
a) Quality
b) Environment
c) SLOC
d) Personnel
4.______ technology is a good example of tools enabling a new and different process
a) CUI
b)GUI
c) Both (a) and (b)
d) None of the above
5. Test activities can consume______of a project resources.
a) 15%
b) 50%
c) 35%
d) 40%
6. Meta process time scale will be
a) 1 to 6 months
b) 6 to 12 months
c) 1 to many years
d) <1 month
7. Which reduction is the primary motivation behind improvements in higher order
languages?
a) Quality
b) Size
c) Environment
d) Personnel
8. Which are useful estimators for language-independent, early life-cycle estimates?
a) UFP
b) Size
c) Quality
d) None of the above

9. Micro process time scale will be

a) 1 to 6 months
22 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
b) 6 to 12 months
c) 1 to many years
d) <1 month
10. Number of parameters in software economics
a) 2
b) 3
c) 4
d) 5

10. Assignments

S.No Question BL CO
1 With the help of neat diagram, explain the Water fall model 2 1
List and explain the conventional software management
2 2 1
performance
3 Illustrate the pragmatic for software cost estimation 2 1
Explain Boehm’s top 10 quotations for the conventional software
4 2 1
management performance

11. Part A- Question & Answers

S.No Question & Answers BL CO

1 List out any five metrics of conventional software management
performance?

Ans. 1.Finding and fixing a software problem after delivery costs

100 times more than finding and fixing the problem in early
design phases
2.You can compress software development schedules 25%
1 1
of nominal, but no more
3. For every $1 you spend on development, you will spend
$2 on maintenance.
4. Walkthroughs catch 60% of the errors
5. 80% of the contribution comes from 20% of the
contributors

2 What are the various cost estimation models?

Ans. There are several popular cost estimation models such as
1 1
COCOMO, CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S,
ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20. COCOMO is one
23 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
of the most open and well-documented cost estimation models
3 Give brief description on essential steps for the development of
software program
1 1
Ans. There are two essential steps common to the development
of computer programs: analysis and coding
4 What are the crucial attributes for successful software
managers?
Ans. The following are some crucial attributes of successful
software project managers that deserve much more
attention:
1 1
 Hiring skills
 Customer-interface skill
 Decision-making skill
 Team-building skill
 Selling skill
5 What is team cohesion? Why we need it?
Ans. Team cohesion is the strength and extent of interpersonal
connection existing among the members of a group
1 1
Successful teams are cohesive, and cohesive teams are
successful. Successful teams and cohesive teams share
common objectives and priorities
6 What is COCOMO model?
Ans. The COCOMO (Constructive Cost Model) is one of the
most popularly used software cost estimation models i.e. it
estimates or predicts the effort required for the project,
1 1
total project cost and scheduled time for the project. This
model depends on the number of lines of code for
software product development. It was developed by a
software engineer Barry Boehm in 1981
7 What is 80/20 principle?
1 1
Ans. 80% of the contribution comes from 20% of the contributors
8 What is meant by team effectiveness?
Ans. Team effectiveness (also referred to as group
effectiveness) is the capacity a team has to accomplish 1 1
the goals or objectives administered by an authorized
personnel or the organization.

12. Part B- Questions

24 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI

S.No Question BL CO
1 Explain the evolution of waterfall in detail 2 1
2 List and explain the different parameters used in software cost 2 1
models
3 What is Conventional Software Management? Explain 10 2 1
principles.
4 Explain how software process improvement will reduce its cost 2 1

13. Supportive Online Certification Courses

1. Software Project Management by Prof. Rajib Mall & Prof. Durga Prasad
Mohapatra conducted by IIT Kharagpur – 12 weeks
2. Software Engineering by Prof. Rajib conducted by IIT Kharagpur – 12 weeks.

14. Real Time Applications

S.No Application CO
1 Implementation of Scoro 1
Scoro is a comprehensive solution that combines all the features you
might need in project management software: projects & tasks, contact
management, quotes, team collaboration, billing, and reporting.

15. Contents Beyond the Syllabus

1. A study of software management: The state of practice in the United States and
Japan
The purpose of the study reported here was to increase our understanding of
the problems in managing software development and the situations in which
these problems occurred — all from the perspective of software managers. The
qualitative research method used during this study was based on grounded
theory, a user-based approach from the social sciences that facilitates the
discovery and definition of generalizations and themes about a complex
subject, such as software development. Thirty-two managers from 14
companies in the United States and Japan were interviewed. The results of the
analysis of the data collected suggest that many interacting technical and
nontechnical factors come into play. Two major differences between the
development contexts of the managers in the United States and Japan were
related to development personnel and constraints placed on the projects.
Similar hardware, software tools, and software processes were applied to their
development efforts. Examination of the technological aspects of software
development showed few distinguishing characteristics between the practices
of the two countries. In contrast, examination of management and sociological

25 | S P M - U N I T - I

BTECH_CSE-SEM 3 1
SVCE TIRUPATI
issues provides insight into the differences, specifically those related to roles
managers played with their people, subcontractors, and customers.

2. The COCOMO cost estimation model.

COCOMO is a procedural software cost estimation model proposed by Barry W.
Boehm in 1981. This cost estimation model is extensively used in predicting the
effort, development time, average team size and effort required to develop a
software project. The distinctiveness of this strategy is that COCOMO estimates
the cost based on the number of lines of source code and sets of subjective
assessment (cost drivers) of product, hardware, personnel and project
attributes. This provides transparency to the model which allows software
managers to understand why the model gives the estimates it does. Moreover,
the baseline COCOMO originally underlies a waterfall model lifecycle

16. Prescribed Text Books & Reference Books

Text Book
1. Software Project Management, Walker Royce, Pearson Education
2. Software Project Management, Bob Hughes & Mike Cotterell, fourth edition,
Tata Mc-Graw Hill
References:
1. Applied Software Project Management, Andrew Stellman & Jennifer Greene,
O‟Reilly, 2006
2. Head First PMP, Jennifer Greene & Andrew Stellman, O‟Reilly,2007

17. Mini Project Suggestion

1. Completion of mini project by forming group
Form a group with persons of different skills& academic percentage for doing a
task that will be useful

26 | S P M - U N I T - I

BTECH_CSE-SEM 3 1