A ANTHI INSTITUTE OF ENGINEERING& TECHNOLOGY

GUNTHAPALLY (V), ABDULAPURMET (M), R. R (D) – 501512.

Subject Name : SOFTWARE PROCESS & PROJECT MANAGEMENT
Subject Code : CS725PE (Professional Elective - V)
Program/Course : B.Tech
Year/Semester : IV Year B.Tech. I -Sem (R-18)
Branch : CSE
Section : A , B, C
Academic Year : 2024 - 25
Subject Faculty : Dr. N. RAMANA REDDY, Associate Professor & HOD
M.Tech(CSE), MBA, Ph.D
UNIT – II: Software Project Management Renaissance
Software Project Management Renaissance, Conventional Software
Management, Evolution of Software Economics, Improving Software
Economics, The old way and the new way.
Life-Cycle Phases and Process artifacts, Engineering and Production
stages, inception phase, elaboration phase, construction phase, transition
phase, artifact sets, management artifacts, engineering artifacts and
pragmatic artifacts, model-based software architectures.
Concepts:-
 Software Project Management Renaissance (PART-I)

 Conventional Software Management,

 Evolution of Software Economics,

 Improving Software Economics,

 The old way and the new way.

 Life-Cycle Phases and Process Artifacts (PART-II)

 Engineering and Production Stages,

 Inception phase, Elaboration phase, Construction phase, Transition phase,

 Artifact sets, Management artifacts,

 Engineering artifacts and Pragmatic artifacts,

 Model-based Software Architectures.

PART-I: Software Project Management Renaissance:-
Software Project Management (SPM) is a proper way of planning and leading software
projects. It is a part of project management in which software projects are planned,
implemented, monitored, and controlled.

Software is a non-physical product. Software development is a new stream in business

and there is very little experience in building software products. Most of the software
products are made to fit clients’ requirements.
Numerous issues can develop if a Software project manager lacks the necessary
expertise or knowledge. Software Project management has several drawbacks,
including resource loss, scheduling difficulty, data protection concerns, and
interpersonal conflicts between Developers/Engineers/Stakeholders.

Conventional Software Management:-

Conventional software management practices are sound in theory, but
practice is still tied to 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.
 In the mid-1990s, three important analyses were performed on the
software engineering industry.

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.
Software Management Process framework:-

The Waterfall Model:-

Most software engineering text presents the waterfall model as the source of
the "conventional" software process.
1. It is the baseline process for most conventional software projects have
used.
2. We can examine this model in two ways:-
 IN THEORY
 IN PRACTICE

IN THEORY: - In 1970, Winston Royce presented a paper called “Managing the

Development of Large Scale Software Systems” at IEEE WESCON.

Where he made three primary points:-

1. There are two essential steps common to the development of computer
programs:-
 Analysis

 Coding

2. In order to manage and control all of the intellectual freedom associated

with software development one should follow the following steps:
- System requirements definition
- Software requirements definition
- Program design and testing

3. Since the testing phase is at the end of the development cycle in the
waterfall model, it may be risky and invites failure.
Five necessary improvements for waterfall model are:-
There are five improvements to the basic waterfall model that would eliminate most of
the development risks are as follows;

1) Complete program design before analysis and coding begin (Program

design comes first).
2) Maintain current and complete documentation (Document the design).
3) Do the job twice, if possible (Do it twice).
4) Plan, control, and monitor testing.
5) Involve the customer.
IN PRACTICE:-
Some software projects still practice the conventional software management approach.
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.
Adversarial Stakeholder Relationships:
Project Stakeholders:-
 Stakeholders are the people involved in by project activities
 Stakeholders includes
 The project sponsor and project team
 Support staff
 Customers
 Users
 Suppliers
 Opponents to the project
Evolution of Software Economics:-
Most of the 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 nonviable -adding activities (rework, bureaucratic delays, and 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) (Size process)
Project Size as team strength could be:
 Minor Project Size: 1 person
 Small Project Size: 5 people
 Moderate Project Size: 25 people
 Large Project Size: 125 people
 Huge Project Size: 625 people

The more the size, the greater are the costs of management overhead, communication,
synchronizations among various projects or modules, etc.
Requirements Analysis of Project Size:-
 Design
 Review of requirements, design and code
 Test Planning and preparation
 Testing
 Regression testing
 Coding takes around 15% of development cost.
Pragmatic Software Estimation:-
If there are no proper well-documented case studies then it is difficult to
estimate the cost of the software. It is one of the critical problems in
software cost estimation.
 But the cost model vendors claim that their tools are well suitable for estimating.
 Iterative development projects.
 In order to estimate the cost of a project the following three topics should be
considered.
1) Which cost estimation model to use?

2) Whether to measure software size in SLOC or function point.

3) What constitutes a good estimate?

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.
Improving Software Economics:-
There are many aspects are there in order to improve the software economics they are,
Size, Process, Personnel, Environment and quality. It is not that much easy to improve
the software economics but also difficult to measure and validate.
These parameters (aspects) are not independent they are dependent. For example, tools
enable size reduction and process improvements, size reduction approaches lead to
process changes, and process improvements drive tool requirements.

GUI technology is a good example of tools enabling a new and different process. GUI
builder tools permitted engineering teams to construct an executable user interface
faster and less cost.
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.

REDUCING SOFTWARE PRODUCT SIZE:-

 By choosing the type of the language

 By using Object-Oriented methods and visual modeling

 By reusing the existing components and building reusable components

Improving Software Processes:-
COCOMO model suggests that the combined effects of personnel skill and experience
can have an impact on productivity as much as a factor of four over the unskilled
personnel. It is the responsibility of the project manager to keep track of his teams.
Since teamwork is much more important than the sum of the individuals.

Boehm – staffing principles:-

 The principle of top talent: Use better and fewer people

 The principle of job matching: Fit the tasks to the skills and motivation of the
people available

 The principle of career progression: An organization does best in the long run
by helping its people to self-actualize.

 The principle of team balance: Select people who will complement and
synchronize with one another.

 The principle of phase-out: Keeping a misfit on the team doesn’t benefit

anyone.
In general, staffing is achieved by these common methods:-
 If people are already available with required skill set, just take them

 If people are already available but do not have the required skills, re-train them

 If people are not available, recruit trained people

 If you are not able to recruit skilled people, recruit and train people
Important Project Manager Skills:-
 Hiring skills
 Customer-interface skill
 Decision-making skill
 Team-building skill
 Selling skill.
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. Automation of the design process provides payback in
quality, the ability to estimate costs and schedules, and overall productivity using a
smaller team.
The Old way and the New way:-
 Over the past two decades software development is a re-engineering
process. Now it is replaced by advanced software engineering
technologies.
 This transition is motivated by the unsatisfactory demand for the
software and reduced cost.

The Principles of Conventional Software Engineering:-

Based on many years of software development experience, the software industry
proposed so many principles (nearly 201 by – Davis’s) of which Davis’s top 30
principles are:

1) Make quality #1

2) High-quality software is possible

3) Give products to customers early

4) Determine the problem before writing the requirements

5) Evaluate design alternatives

6) Use different languages for different phases

7) Minimize intellectual distance

8) Put techniques before tools

9) Get it right before you make it faster

10) Follow with care

11) Take responsibility

12) Understand the customer’s priorities

13) Plan to throw one away

14) Design for change

15) Design without documentation is not design

PART-II: Life Cycle Phases and Process Artifacts:-
Life-Cycle Phases:-
Characteristic of a successful software development process is the well-defined
separation between "research and development" activities and "production" activities. If
there is a well defined separation between “research and development” activities and
“production” activities then the software is said to be in successful development
process.

Most unsuccessful projects exhibit one of the following characteristics:

 An overemphasis on research and development
 An overemphasis on production
A modern software development process must be defined to support the following:

 Evolution of the plans, requirements, and architecture, together with well defined
synchronization points.
 Risk management and objective measures of progress and quality.
 Evolution of system capabilities through demonstrations of increasing
functionality.
ENGINEERING AND PRODUCTION STAGES:-
To achieve economies of scale and higher returns on investment, we must move toward
a software manufacturing process driven by technological improvements in process
automation and component-based development. Two stages of the life cycle are:

1. The Engineering stage, driven by less predictable but smaller teams doing design
and synthesis activities.

This stage is decomposed into two distinct phase’s inception and elaboration.
2. The Production stage, driven by more predictable but larger teams doing
construction, test, and deployment activities.

This stage is also decomposed into two distinct phase’s construction and
transition.
These four phases of lifecycle process are loosely mapped to the conceptual framework
of the spiral model is as shown in the following figure.
The transition between engineering and production is a crucial event for the various
stakeholders. The production plan has been agreed upon, and there is a good enough
understanding of the problem and the solution that all stakeholders can make a firm
commitment to go ahead with production.
Engineering stage is decomposed into two distinct phases, inception and elaboration,
and the production stage into construction and transition. These four phases of the life -
cycle process are loosely mapped to the conceptual framework of the spiral model as
shown in Figure 5-1:

1. INCEPTION PHASE:-
The main goal of this phase is to achieve agreement among stakeholders on
the life-cycle objectives for the project.
PRIMARY OBJECTIVES:-
1) Establishing the project’s scope and boundary conditions.

2) Distinguishing the critical use cases of the system and the primary scenarios of
operation.
3) Demonstrating at least one candidate architecture against some of the primary
scenarios.
4) Estimating cost and schedule for the entire project.

5) Estimating potential risks.

ESSENTIAL ACTIVITIES:-
1) Formulating the scope of the project

2) Synthesizing the architecture

3) Planning and preparing a business case

2. ELABORATION PHASE:-
At most of the time the process may accommodate changes, the elaboration phase
activities must ensure that the architecture, requirements, and plans are stable. And also
the cost and schedule for the completion of the development can be predicted within an
acceptable range.

PRIMARY OBJECTIVES:-
1) Base lining the architecture as rapidly as practical

2) Base lining the vision

3) Base lining a high-reliability plan for the construction phase

4) Demonstrating that the baseline architecture will support the vision at a reasonable
cost in a reasonable time.
ESSENTIAL ACTIVITIES:-
1) Elaborating the vision
2) Elaborating the process and infrastructure
3) Elaborating the architecture and selecting components

3. CONSTRUCTION PHASE:-
During this phase all the remaining components and application features are developed
software is integrated where ever required. If it is a big project then parallel
construction increments are generated.
PRIMARY OBJECTIVES:-
1) Minimizing development costs.
2) Achieving adequate quality as rapidly as practical.
3) Achieving useful version (alpha, beta, and other releases) as rapidly as practical.
ESSENTIAL ACTIVITIES:-
1) Resource management, control, and process optimization
2) Complete component development and testing evaluation criteria
3) Assessment of product release criteria of the vision

4. TRANSITION PHASE:-
The transition phase is entered when a baseline is mature enough to be deployed in the
end-user domain. This typically requires that a usable subset of the system has been
achieved with acceptable quality levels and user documentation so that transition to the
user will provide positive results.

This phase could include any of the following activities:-

1. Beta testing to validate the new system against user expectations
2. Beta testing and parallel operation relative to a legacy system it is replacing
3. Conversion of operational databases
4. Training of users and maintainers
PRIMARY OBJECTIVES:-
1) Achieving user self-supportability
2) Achieving stakeholder concurrence
3) Achieving final product baseline as rapidly and cost-effectively as practical

ESSENTIAL ACTIVITIES:-
1) Synchronization and integration of concurrent construction increments into
consistent deployment baselines.
2) Deployment-specific engineering.
3) Assessment of deployment baselines against the complete vision and acceptance
criteria in the requirement set.

Artifacts of the Process:-

The Artifact Sets:-
In order to manage the development of a complete software system, we need to gather
distinct collections of information and is organized into Artifact Sets. A Set represents
a complete aspect of the system where as artifact represents interrelated information
that is developed and reviewed as a single entity.

The artifacts of the process are organized into five sets:

1) Management 2) Requirements 3) Design
4) Implementation 5) Deployment
The Management Sets:-
It captures the artifacts associated with process planning and execution. These artifacts
use ad hoc notation including text, graphics, or whatever representation is required to
capture the “contracts” among,
The management set captures the artifacts associated with process planning and
execution. These artifacts use ad hoc notations, including text, graphics, or whatever
representation is required to capture the "contracts" among project personnel (project
management, architects, developers, testers, marketers, administrators), among
stakeholders (funding authority, user, software project manager, organization manager,
regulatory agency), and between project personnel and stakeholders.

Management set artifacts are evaluated, assessed, and measured through a combination
of the following:

 Relevant stakeholder review

 Analysis of changes between the current version of the artifact and previous
versions.
 Major milestone demonstrations of the balance among all artifacts and, in
particular, the accuracy of the business case and vision artifacts.
The Engineering Sets:-
The engineering sets consist of the requirements set, the design set, the implementation
set, and the deployment set.

1) Requirement Set:-
Requirements artifacts are evaluated, assessed, and measured through a combination of
the following:
1) Analysis of consistency with the release specifications of the management set

2) Analysis of consistency between the vision and the requirements models

3) Subjective review of other dimensions of quality

2) Design Set:-
UML notation is used to engineer the design models for the solution. The design set
contains varying levels of abstraction that represent the components of the solution
space (their identities, attributes, static relationships, dynamic interactions).
The design set is evaluated, assessed, and measured through a combination of the
following:
1) Analysis of the internal consistency and quality of the design model
2) Analysis of consistency with the requirements models
3) Analysis of changes between the current versions of the design model
4) Translation into implementation and deployment sets and notations
5) Subjective review of other dimensions of quality

3) Implementation Set:-
The implementation set includes source code (programming language notations) that
represents the tangible implementations of components (their form, interface, and
dependency relationships).

Implementation sets are human-readable formats that are evaluated, assessed, and
measured through a combination of the following:
1) Analysis of consistency with the design models
2) Translation into deployment set notations
3) Translation into implementation and deployment sets and notations
4) Subjective review of other dimensions of quality
4) Deployment Set:-
The deployment set includes user deliverables and machine language notations,
executable software, and the build scripts, installation scripts, and executable target
specific data necessary to use the product in its target environment.

Deployment sets are evaluated, assessed, and measured through a combination of the
following:
1) Testing against the usage scenarios and quality attributes.
2) Testing the partitioning, replication, and allocation strategies in mapping components.
3) Testing against the defined usage scenarios in the user manual.
4) Analysis of changes between the current version of the deployment set.

ARTIFACT EVOLUTION OVER THE LIFE CYCLE:-

Each state of development represents a certain amount of precision in the final system
description. Early in the life cycle, precision is low and the representation is generally
high. At the end of each phase, the overall system state will have progressed on all sets,
as illustrated in Figure 6-3.
MANAGEMENT ARTIFACTS:-
The management set includes several artifacts that capture intermediate results and
ancillary information necessary to document the product/process legacy, maintain the
product, improve the product, and improve the process.

Development of Work breakdown structure (WBS) is dependent on product

management style, organizational culture, custom performance, financial constraints
and several project specific parameters.

The WBS is the architecture of project plan. It encapsulates change and evolves with
appropriate level of details. A WBS is simply a hierarchy of elements that decomposes
the project plan into discrete work task.
 Business Case
 Software Development Plan
 Work Breakdown Structure
 Software Change Order Database
 Release Specifications
 Release Descriptions
 Status Assessments
 Work Environment
 Management Artifact Sequences
ENGINEERING ARTIFACTS:-
Most of the engineering artifacts are captured in rigorous engineering notations such as
UML, programming languages, or executable machine codes. Three engineering
artifacts are:
1). Vision Document.
2). Architecture Description.
3). S/W User Manual.
Vision Document:-
The vision document provides a complete vision for the software system under
development and. supports the contract between the funding authority and the
development organization. A project vision is meant to be changeable as understanding
evolves of the requirements, architecture, plans, and technology. A good vision
document should change slowly. Figure 6-9 provides a default outline for a vision
document.
Architecture Description:-
The architecture description provides an organized view of the software architecture
under development. It is extracted largely from the design model and includes views of
the design, implementation, and deployment sets sufficient to understand how the
operational concept of the requirements set will be achieved. Figure 6-10 provides a
default outline for an architecture description.

Pragmatic Artifacts:-
Pragmatic Artifacts is the conventional document-driven approach that generally
squandered unbelievable amounts of engineering time simply given on development,
polish, format, review, update, modify and distribute documents. It is an approach that
redirects this effort of documentation to simply improve rigor and easily
understanding of source of data or information.

 Pragmatic Meaning is dealing with things sensibly and realistically in a way that is
based on practical rather than theoretical considerations.

 People want to review information but don’t understand the language of the artifact.
  People want to review the information but don’t have access to the tools.

 Human readable engineering artifacts should use rigorous notations that are complete,
consistent and used in a self documenting manner.
 Useful documentation is self defining: It is documentation that gets used.
 Paper is tangible (perceptible by touch): electronic artifacts are too easy to change.

Model-based Software Architectures:-

Software architecture is the central design problem of a complex software system in the
same way architecture is the software system design.
 The ultimate goal of the engineering stage is to converge on a stable architecture
baseline.
 Architecture is not a paper document. It is a collection of information across all
the engineering sets.
 Architectures are described by extracting the essential information from the
design models.
 A model is a relatively independent abstraction of a system.
 A view is a subset of a model that abstracts a specific, relevant perspective.

ARCHITECTURE: A MANAGEMENT PERSPECTIVE:-

If a software development team is to be successful, the inter project communications, as
captured in software architecture, must be accurate and precise.

From the management point of view, three different aspects of architecture:

1. An Architecture

2. An Architecture baseline

3. An Architectural description

ARCHITECTURE: A TECHNICAL PERSPECTIVE:-

An architecture baseline is defined as a balanced subset of information across all sets,
where as architecture description is completely encapsulated within the design set.
Most real-world systems require four types of views:
1) Design
2) Process
3) Component
4) Deployment
Generally architecture base line includes:-
1) Requirements 2) Design
3) Implementation 4) Deployment

Prepared by,
Dr. N. RAMANA REDDY
M.Tech(CSE), MBA, Ph.D
Associate Professor & HOD
Ph. No: 9640 789 300