CONTENTS

1 Unit-I : Conventional Software Management Page NO

1.1 Introduction 3
1.2 Unit-I notes 3
1.3 Part A Questions 8

1.4 Part B Questions 10

2 Unit-II : Improving Software Economics
2.1 Introduction 11
2.2 Unit-II notes 11
2.3 Part A Questions 20
2.4 Part B Questions 21
3 Unit-III : Life Cycle Phases
3.1 Introduction 22
3.2 Unit-III notes 22
3.3 Part A Questions 30
3.4 Part B Questions 31
4 Unit-IV : Work Flows of the Process
4.1 Introduction 32
4.2 Unit-IV notes 32
4.3 Part A Questions 42
4.4 Part B Questions 43
5 Unit-V : Project Control and Process instrumentation
5.1 Introduction 45
5.2 Unit-V notes 45
5.3 Part A Questions 52
5.4 Part B Questions 53

1
 SOFTWARE PROJECT MANAGEMENT
1.UNIT – I
1.1 Introduction

1.2 .The water fall model in detail

There are two essential steps common to the development of computer programs:
analysis and coding.

Both involve creative work that directly contributes to the usefulness of the end product.
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. These steps supplement the analysis and coding steps.”

Waterfall model phases

Requirements analysis and
definition System and software
design Implementation and unit
testing Integration and system
testing Operation and
maintenance
The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway
Waterfall model problems
Inflexible partitioning of the project into distinct stages
This makes it difficult to respond to changing customer
requirements Therefore, this model is only appropriate when
the requirements are well-understood
2
 Pros: Cons:

Easiest to understand Does not model the real

world

Easiest to instrument Too much documentation

Enforced discipline

Document and deliverable

driven

Suggested Changes ‘Then’ and ‘Now’ Point 1. “Program design” comes first.
 Program designer looks at storage, timing, data. Very high level…First glimpse.
First concepts…
During analysis: program designer must then impose storage, timing, and
operational constraints to determine consequences.
Begin design process with program designers, not analysts and programmers
Design, define, and allocate data processing modes even if wrong. (allocate
functions, database design, interfacing, processing modes, i/o processing,
operating procedures…. Even if wrong!!)
 Build an overview document – to gain a basic understanding of system for all
stakeholders.
Point 2: Document the Design
Development efforts required huge amounts of documentation – manuals for
everything
User manuals; operation manuals, program maintenance manuals, staff
user manuals, test manuals…
Most of us would like to ‘ignore’ documentation.
Each designer MUST communicate with various stakeholders: interface designers,
managers, customers, testers, developers, …..
Point 3: Do it twice.
History argues that the delivered version is really version #2Version 1, major
problems and alternatives are addressed – the ‘big cookies’ such as
communications, interfacing, data modeling, platforms, operational constraints,
other constraints. Plan to throw first version away sometimes…
Version 2, is a refinement of version 1 where the major requirements are
implemented. Version 1 often austere; Version 2 addressed shortcomings!
3
Point 4: Then: Plan, Control, and Monitor Testing.
 Largest consumer of project resources (manpower, computing time, …) is
the test phase.
Phase of greatest risk – in terms of cost and schedule.
 when alternatives are least available, and expenses are at a
 Occurs last,
maximum.
 phase that is shortchanged the most
 Typically that
 Employ a non-vested team of test specialists – not responsible for original design.
 Employ visual inspections to spot obvious errors (code reviews, other technical
reviews and interfaces)
 Test every logic path
 Employ final checkout on target computer…..

Point 5 – Old: Involve the Customer

Old advice: involve customer in requirements definition, preliminary
software review, preliminary program design (critical design review
briefings…)
Now: Involving the customer and all stakeholders is critical to overall
project success. Demonstrate increments; solicit feedback; embrace
change; cyclic and iterative and evolving software. Address risk early…..

4
1.2.1 Conventional Software Management Performance Or Boehm’s top 10 list about
conventional software management performance?

a. Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the problem in early design phases.
b. You can compress software development schedules 25% of nominal, but no more.
c. For every $1 you spend on development, you will spend $2 on maintenance.
d. Software development and maintenance costs are primarily a function of the
number of source lines of code.
e. Variations among people account for the biggest differences in software productivity.
f. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85;
in 1985, 85:15.
g. Only about 15% of software development effort is devoted to programming.
h. Walkthroughs catch 60% of the errors.
i. 80% of the contribution comes from 20% of contributors

1.2.3 Explain the basic parameters of the software cost models?

 Most software cost models can be abstracted into a function of five basic
parameters:
 Size of the end product which is typically quantified in terms of the number
of source instructions or the function points required to develop the
required functionality
 Process used to produce the end product and to avoid non-value adding
activities like rework, communication overhead.
 Personnel particularly their experience with the computer science issues
and the applications domain issues of the project.
 Environment which is made up of the tools and techniques available to
support efficient software development and to automate process.
 Quality of the product, including its performance, reliability, and adaptability.

The relationship among these parameters and the estimated cost can be
written as follows;:
Effort=(Personnel)(Environment)(quality)(size Process)

The figure following shows three generations of basic technology

5
advancement in topls, components and process. Thre requited levels of quality
and personnel are assumed to be constant. The ordinate of the graph refers to
software unit costs like SLOC,Function Point, and component realized by an
organization.
The three generations of software development are defined as folows:

Conventional: 1960s and 1970s craftmanship. Organization used custom tools,

custom process, and virtually all custom components built in primitive languages.

Transition: 1980s and 1990s, software engineering. Organizations used more-

repeatable process and off-the-shelf tools and mostly >70% custom components
buits in higer level languages. Some of the components <30% were available as
commercial products, including the operating system , database management
system, networking and graphical user interface.

Modern Pracices: 2000 and late, software production. In this mostly 70% off-the-
shelf components perhaps as few as 30% of the components need to be custom
built. With advances in software technology and integrated production
environments, thse components-based systems can be produced very rapidly.

Three generations of software economics:

6
 1.2.4 The predominant cost estimation process?

 A good 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, technologies, environments, quality requirements, and people.
It is defined in enough detail so that its key risk areas are understood and the
probability of success is objectively assessed.

1.3 Part A Questions

1. What is COCOMO model? ( May/June 2016)

Ans) Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number
of Lines of Code. It is a procedural cost estimate model for software projects and often
used as a process of reliably predicting the various parameters associated with making a
Project such as size, effort, cost, time and quality.

2. What is 80/20 principle? ( May/June 2016)

Ans) Using the Pareto Principle in Project Management. The Pareto Principle, also
known as “The 80-20 rule”, states that in many situations, 80% of the effects originate
from 20% of the causes. This rule has been applied to economics, criminology, software
programming, and business.

7
 3. What is requirement analysis? ( May/June 2017)
Ans) Requirements analysis, also called requirements engineering, is the process of determining
User expectations for a new or Modified product. These features, called requirements, must be
Quantifiable, relevant and detailed. In software engineering, such Requirements are often called
Functional specifications. Requirements analysis is an important aspect of project management.

4. Write the relationship between the parameters in software cost model.

( May/June 2017)
Ans) The relationships among these parameters and the estimated cost can be written as
follows Effort = (Personnel)(Environment)(Quality)(SizeProcess).

5. What are the two basic steps to build a program? Explain. (Dec-2016)
Ans) There are two essential steps common to the development of computer programs:
analysis and coding. 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.

6.Explain Boehm’s quotation “walkthroughs catches 60% of the errors”. (Dec-2016)

Ans) Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the problem in early design phases
Software development and maintenance costs are primarily a function of the number of
source lines of code
Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software-system products
Walkthroughs catch 60% of the errors 80% of the contribution comes from 20% of the
contributors.

8
1.4 Part B Questions
1. What are the risks in the waterfall model implemented in traditional way? ( May/June 2016)
2. What are the components of a good cost estimate, in practice? ( May/June 2016)
3. List and explain reasons why conventional software management does not perform
satisfactorily ( May/June 2017)
4. What are the five parameters related to software cost model? What is the
Relationship between these parameters? ( May/June 2017)
5. Describe the improvements done to the basic waterfall process that would eliminate
Most of the Development risks. (Dec-2016)
6. Describe in detail about the three generations of software development. (Dec-2016)

9
 2. UNIT – II
2.1 Introduction
2.2 Improving the software economics
 Five basic parameters of the software cost model:
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
4. Using better environments
5. Trading off or backing off on quality thresholds

1. Reducing Software Product Size

“The most significant way to improve affordability and return on investment
is usually to produce a product that achieves the design goals with the minimum
amount of human-generated source material.”
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.
UFP -Universal Function Points
The basic units of the function points are external user inputs, external
outputs, internal logic 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

10
Reducing Software Product Size: Object Oriented
A ruthless focus on the development of a system that provides a well understood
collection of essential minimal characteristics.
The existence of a culture that is centered on results, encourages communication, but yet
is not afraid to fail.
The effective use of object-oriented
modeling The existence of a strong
architectural vision
The application of a well-managed and incremental development life cycle

Reducing Software Product Size – Reuse

 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.
Reducing Software Product Size – Commercial Components
APPROACH ADVANTAGES DISADVANTAGES

Commercial Predictable license costs Frequent upgrades

components
Broadly used, mature Up-front license fees
technology
Recurring maintenance fees
Available now
Dependency on vendor
Dedicated support
organization Run-time efficiency sacrifices

Hardware/software Functionality constraints

independence Integration not always trivial
Rich in functionality No control over upgrades and maintenance

Unnecessary features that consume extra

resources

Often inadequate reliability and stability

Multiple-vendor incompatibility

11
Custom Complete change freedom Expensive, unpredictable development
development
Smaller, often simpler Unpredictable availability date
implementations
Undefined maintenance model
Often better performance
Often immature and fragile
Control of development and
enhancement Single-platform dependency

Drain on expert resources

2.2.1 Improving Software Processes

Process is an overloaded term. There are three distinct process perspectives.
a. Meta process: An Organization’s policies, procedures and practices
for pursuing a software-intensive line of business
b. Macro Process: a project’s policies, procedures, and practices for
producing a complete software product within certain cost,
schedule, and quality constraints.
c. Micro process: a project team’s policies, procedures, and practices
for achieving an artifact of the software process.

Three levels of processes and their attributes

Attributes Metaprocess Macroprocess Microprocess

Subject Line of business Project Iteration

Objectives Line-of- Project Resource management

business
profitability profitability Risk Risk resolution

Competitiveness management Milestone

budget,
Project budget, schedule,
schedule, quality quality
Audience Acquisition Software project Subproject
authorities,
customers managers Software managers

Organization engineers Software

al

12
 management engineers

Metrics Project predictability On budget, on On budget, on

schedule
Revenue, market schedule Major
Major
share milestone success milestone
progress
Project scrap and rework Release/iteration
scrap and rework

Concerns Bureaucracy Quality vs. Content vs. schedule

vs. financial
standardizatio performance
n
Time scales 6 to 12 months 1 to many years 1 to 6 months

2.2.2 Improving Team Effectiveness

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

In examining how to staff a software project, Boehm offered the

following five staffing principles:

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

 The principle of job matching: Fit the task to the skills an 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
13
 harmonize with one another.
 The principle of phase-out: Keeping a misfit on the team doesn’t benefit anyone.

The following are some attributes of successful software project

managers that deserve much more attention (Important Project Manager
Skills):

 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.
 Customer-interface skill. Avoiding adversarial relationships among stake-
holders 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

2.2.3 Achieving Required Quality

Key practices that improve overall software quality:

 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
14
  Using visual modeling and higher level language that support architectural
control, abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-based
evaluations

2.2.4 Explain The Principles of Conventional Software Engineering?

 Make quality #1. Quality must be quantified and mechanism put into place to
motivate its achievement.
 High-quality software is possible. Techniques that have been demonstrated to
increase quality include involving the customer, prototyping, simplifying design,
conducting inspections, and hiring the best people.
 Give products to customers early. No matter how hard you try to learn users’
needs during the requirements phase, the most effective way to determine real
needs is to give users a product and let them play with it.
 Determine the problem before writing the requirements. When faced with
what they believe is a problem, most engineers rush to offer a solution. Before
you try to solve a problem, be sure to explore all the alternatives and don’t be
blinded by the obvious solution.
 Evaluate design alternatives. After the requirements are agreed upon, you must
examine a variety of architectures and algorithms. You certainly do not want to
use an “architecture” simply because it was used in the requirements
specification.

Use an appropriate process model. Each project must select a process that
makes the most sense for that project on the basis of corporate culture, willingness to take risks,
application area, volatility of requirements, and the extent to which requirements are well
understood.
 Use different languages for different phases. Our industry’s eternal thirst for
simple solutions to complex problems has driven many to declare that the best
development method is one that uses the same notation through-out the life
cycle. Why should software engineers use Ada for requirements, design, and
code unless Ada were optimal for all these phases?
 Minimize intellectual distance. To minimize intellectual distance, the software’s
structure should be as close as possible to the real-world structure.
 Put techniques before tools. An undisciplined software engineer with a tool
becomes a dangerous, undisciplined software engineer.
 Get it right before you make it faster. It is far easier to make a working program
run than it is to make a fast program work. Don’t worry about optimization
15
 during initial coding.
 Inspect code. Inspecting the detailed design and code is a much better way to
find errors than testing.
 Good management is more important than good technology. The best
technology will not compensate for poor management, and a good manager can
produce great results even with meager resources. Good management
motivates people to do their best, but there are no universal “right” styles of
management.
 People are the key to success. Highly skilled people with appropriate
experience, talent, and training are key. The right people with insufficient tools,
languages, and process will succeed. The wrong people with appropriate tools,
languages, and process will probably fail.
 Follow with care. Just because everybody is doing something does not make it
right for you. It may be right, but you must carefully assess its applicability to
your environment. Object orientation, measurement, reuse, process
improvement, CASE, prototyping-all these might increase quality, decrease cost,
and increase user satisfaction. The potential of such techniques is often oversold,
and benefits are by no means guaranteed or universal.
 Take responsibility. When a bridge collapses we ask, “what did the engineers do
wrong?” Even when software fails, we rarely ask this. The fact is that in any
engineering discipline, the best methods can be used to produce awful designs,
and the most antiquated methods to produce elegant design.
 Understand the customer’s priorities. It is possible the customer would tolerate
90% of the functionality delivered late if they could have 10% of it on time.
 The more they see, the more they need. The more functionality (or
performance) you provide a user, the more functionality (or performance) the
user wants.
 Plan to throw one away .One of the most important critical success factors is
whether or not a product is entirely new. Such brand-new applications,
architectures, interfaces, or algorithms rarely work the first time.
 Design for change. The architectures, components, and specification techniques
you use must accommodate change.
 Design without documentation is not design. I have often heard software
engineers say, “I have finished the design. All that is left is the documentation.”
 Use tools, but be realistic. Software tools make their users more efficient.
 Avoid tricks. Many programmers love to create programs with tricks- constructs
that perform a function correctly, but in an obscure way. Show the world how
smart you are by avoiding tricky code.
16
 Encapsulate. Information-hiding is a simple, proven concept that results in
software that is easier to test and much easier to maintain.
 Use coupling and cohesion. Coupling and cohesion are the best ways to
measure software’s inherent maintainability and adaptability.
 Use the McCabe complexity measure. Although there are many metrics
available to report the inherent complexity of software, none is as intuitive and
easy to use as Tom McCabe’s.
 Don’t test your own software. Software developers should never be the
primary testers of their own software.
 Analyze causes for errors. It is far more cost-effective to reduce the effect of an
error by preventing it than it is to find and fix it. One way to do this is to analyze
the causes of errors as they are detected.
 Realize that software’s entropy increases. Any software system that undergoes
continuous change will grow in complexity and become more and more
disorganized.
 People and time are not interchangeable. Measuring a project solely by person-
months makes little sense.
 Expert excellence. Your employees will do much better if you have high
expectations for them.
2.2.5 Explain The Principles of Modern Software Management? Top ten principles:
 Base the process on an architecture-first approach: The architecturally
significant design decisions, and the life cycle plans before the resources are
committed for full scale development.
 Establish an iterative life-cycle process: Today’s sophisticated software systems,
it is not possible to define the entire problem, design the entire solution, build
the software, the test the end product in sequence. An iterative process that
refines the problem understanding, an effective solution, and an effective plan
over several iterations encourages a balanced treatment to all objectives.
 Component based development: A component is a cohesive set of preexisting
lines of code, either in source or executable format, with a defined interface and
behavior.
 Change management environment: The dynamic of iterative development,
including concurrent workflows by different teams working on shared artifacts,
necessitates objectively controlled baselines.
 Round trip engineering: it is the environment support necessary to automate
and synchronize engineering information in different formats. Change freedom
a necessity in an iterative process, and establishing an integrated environment is
crucial.
17
 Model based notation: A model based approach supports the evolution of
semantically rich graphical and textual design notations
 Objective quality control: It is the best assessment mechanisms are well defined
measures derived directly from the evolving engineering
 Demonstration based approach: transitioning the current state of the product
artifacts into an executable demonstration of relevant scenarios stimulates
earlier convergence on integration
 Evolving levels of detail: the evolution of project increments and generations
must be commensurate with the current level of understanding f the
requirements and architecture.
 Configurable process: No single process is suitable for all software
developments. A pragmatic process framework must be configurable to a broad

Waterfall Process Iterative Process

Requirements first Architecture first
Custom development Component based development
Change avoidance Change management
Ad hoc tools Round-trip engineering

spectrum of applications.

18
2.3 Part A Questions

1. What is meant by team effectiveness? ( May/June 2016)

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

2. What is meant by risk assessment? ( May/June 2016)

Ans) Risk management means risk containment and mitigation. First, you’ve got to
identify and plan. Then be ready to act when a risk arises, drawing upon the
experience and knowledge of the entire team to minimize the impact to the project.
 Risk management includes the following tasks:
 Identify risks and their triggers
 Classify and prioritize all risks
 Craft a plan that links each risk to a mitigation
 Monitor for risk triggers during the project
 Implement the mitigating action if any risk materializes
 Communicate risk status throughout project

4. What is meant by risk mitigation? (May/June 2017)

Ans) Risk mitigation planning is the process of developing options and actions to
Enhance Opportunities and reduce threats to project objectives . Risk mitigation
implementation is The process of executing risk mitigation actions. Risk mitigation
progress monitoring includes tracking identified risks, identifying new risks, and
evaluating risk process effectiveness Throughout the project.

5. Describe the principle of top talent in team effectiveness. (Dec-2016)

Ans) This talent is fundamental, but it can be applied only so far. There is a "natural" team
size for most jobs, and being grossly over or under this size is bad for team dynamics
because it results in too little or too much pressure on individuals to perform.

19
 6. Analyze the Davis principle “Use different languages for different phases”.
(Dec-2016)
Ans) Our industry’s main aim is to provide simple solutions to complex problems. In
order to Accomplish this goal choose different languages for different modules/phases
if required.

2.4 Part B Questions

1. What are important trends in improving software economics? Explain it briefly.

( May/June 2016)

2. Explain about transitioning to iterative process. ( May/June 2016)

3. Explain how to reduce the software product size (or) complexity. (May/June 2017)

4.Explain how languages help in reducing software product size.(Dec-2016)

5. What are the key practices that improve overall software quality? Explain (Dec-2016)

6. Describe in detail about the ten principles of modern software management.

(Dec-2016)

20
 3. UNIT-III
3.1 Introduction
3.2 The Life cycle phases

The following are the two stages of the life-cycle:

 The engineering stage – driven by smaller teams doing design and synthesis activities

 The production stage – driven by larger teams doing construction, test, and
deployment activities

LIFE-CYCLE ASPECT ENGINEERING STAGE EMPHASIS PRODUCTION STAGE

EMPHASIS

Risk reduction Schedule, technical feasibility Cost

Products Architecture baseline Product release baselines

Activities Analysis, design, planning Implementation, testing

Assessment Demonstration, inspection, Testing

analysis

Economics Resolving diseconomies of scale Exploiting economics of

scale

Management Planning Operations

The 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.
The size of the spiral model corresponds to the inertia of the project with respect to the
breadth and depth of the artifacts that have been developed.

21
In most conventional life cycles, the phases are named after the primary activity within each
phase: requirements analysis, design, coding, unit test, integration test, and system test.
Conventional software development efforts emphasized a mostly sequential process, in which
one activity was required to be complete before the next was begun.

Within an iterative process, each phase includes all the activities, in varying proportions.

Inception Phase:

 Overriding goal of the inception phase is to achieve concurrence among stakeholders on

the life- cycle objectives

 Essential activities :

 Formulating the scope of the project (capturing the requirements and

operational concept in an information repository)

 Synthesizing the architecture (design trade-offs, problem space ambiguities, and

available solution-space assets are evaluated)

 Planning and preparing a business case (alternatives for risk management,

iteration planes, and cost/schedule/profitability trade-offs are evaluated)

Elaboration Phase:

It is easy to argue that the elaboration phase is the most critical of the four phases. At the end
of this phase, the “engineering “is considered complete and the project faces its reckoning.
During the elaboration phase, an executable architecture prototype is built in one or more
iterations, depending on the scope, size, risk and novelty of the project.

 Essential activities :

Elaborating the vision (establishing a high-fidelity understanding of the critical use cases
that drive architectural or planning decisions)

Elaborating the process and infrastructure (establishing the construction process, the
tools and process automation support)

Elaborating the architecture and selecting components (lessons learned from these
activities may result in redesign of the architecture)

Construction Phase:

 During the construction phase :

All remaining components and application features are integrated into the application
All features are thoroughly tested

22
  Essential activities :

 Resource management, control, and process optimization

 Complete component development and testing against evaluation criteria

 Assessment of the product releases against acceptance criteria of the vision

Transition Phase:

 The transition phase is entered when baseline is mature enough to be deployed in the
end-user domain. This phase could include beta testing, conversion of operational
databases, and training of users and maintainers.

 Essential activities :

 Synchronization and integration of concurrent construction into consistent

deployment baselines

 Deployment-specific engineering (commercial packaging and production, field

personnel training)

 Assessment of deployment baselines against the complete vision and acceptance

criteria in the requirements set

Evaluation Criteria:

 Is the user satisfied?

 Are actual resource expenditures versus planned expenditures acceptable?

 Each of the four phases consists of one or more iterations in which some technical
capability is produced in demonstrable form and assessed against a set of the criteria.

 The transition from one phase to the nest maps more to a significant business decision
than to the completion of specific software activity.

3.2.1 Describe the artifacts of the process?

A set represents a complete aspect of the system, an artifact represents cohesive

information that typically is developed and reviewed as a single entity.

Life – cycle software artifacts are organized into five distinct sets that are roughly
partitioned by the underlying language of the set: management, requirements, design,
implementation, and deployment.
Management set:

The Management set captures the artifacts associated with process planning and

23
execution. Management artifacts are evaluated, assessed and measured through a
combination of the following:

a. Relevant stakeholder reviews

b. Analysis of changes between the current version of the artifact and previous versions

c. 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 setk the
implementation set, and the deployment set.

3.2.3 Management artifacts:

The management set includes several artifacts

 Work Breakdown Structure – vehicle for budgeting and collecting

costs. The software project manager must have insight into project costs

and how they are expended. If the WBS is structured improperly, it can drive the
evolving design in the wrong direction.
Business Case – provides all the information necessary to determine whether the project is
24
worth investing in. It details the expected revenue, expected cost, technical and management plans.

Release Specifications

Typical release specification outline :

Two important forms of requirements:

 Vision statement - which captures the contract between the development group and
the buyer.

 Evaluation criteria – defined as management-oriented requirements, which may be

represented by use cases, use case realizations or structured text representations.

 Software Development Plan – the defining document for the project’s process. It must
comply with the contract, comply with the organization standards, evolve along with
the design and requirements.

 Deployment – depending on the project, it could include several document subsets for
transitioning the product into operational status. It could also include computer system
operations manuals, software installation manuals, plans and procedures for cutover
etc.

 Environment – A robust development environment must support automation of the

development process. It should include :

requirements

management visual

modeling

document automation

automated regression testing

25
3.2.4 Engineering Artifacts:
In general review, there are three engineering artifacts :

 Vision document – supports the contract between the funding authority and the development

organization.

It is written from the user’s perspective, focusing on the essential features of the system.

It should contain at least two appendixes – the first appendix should describe the operational concept
using use cases, the second should describe the change risks inherent in the vision statement.

 Architecture Description – it is extracted 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.

Typical architecture description outline :

 Software User Manual – it should include installation procedures, usage procedures

and guidance, operational constraints, and a user interface description.

 It should be written by members of the test team, who are more likely to understand
the user’s perspective than the development team.
 It also provides a necessary basis for test plans and test cases, and for construction of
automated test suites.

3.2.5 Architecture in the management perspective view

26
 From a management perspective, there are three different aspects of architecture:

 An architecture (the intangible design concept) is the design of software system, as

opposed to design of a component.

 An architecture baseline (the tangible artifacts) is a slice of information across the

engineering artifact sets sufficient to satisfy all stakeholders that the vision can be
achieved within the parameters of the business case (cost, profit, time, people).

 An architecture description (a human-readable representation of an architecture) is an

organizes subsets of information extracted from the design set model.

The importance of software architecture can be summarized as follows:

 Achieving a stable software architecture represents a significant project milestone at

which the critical make/buy decisions should have been resolved.
 Architecture representations provide a basis for balancing the trade-offs between the
problem space and the solution space.
 The architecture and process encapsulate many of the important communications
among individuals, teams, organizations, and stakeholders.
 Poor architectures and immature processes are often given as reasons for project failures.
 A mature process, an understanding of the primary requirements, and a demonstrable
architecture are important prerequisites for predictable planning.
 Architecture development and process definition are the intellectual steps that map the
problem to a solution without violating the constraints.
3.2.6 Explain in detail about architecture in the technical perspective view?
An architecture framework is defined in terms of views that are abstractions of the UML
models in the design set. The design model includes the full breadth and depth of
information.

An architecture view is an abstraction of the design model, it contains only the

architecturally significant information.

Most real world systems require four views: design, process, component, and deployment.
The purposes of these views are as follows:
Design: describes architecturally significant structures and functions of the design
model. Process: describes concurrency and control thread relationships among the
design components, and deployment views.
Component: describes the structure of the
implementation set. Deployment: describes the
structure of the deployment set.

27
 The use case view describes how the system’s critical use cases are realized by
elements of the design model. It is modeled statically using case diagrams, and
dynamically using any of the UML behavioral diagrams. The design view addresses the
basic structure and the functionality of the solution.

 The process view addresses the run-time collaboration issues involved in executing the
architecture on a distributed deployment model, including the logical software network
topology, interprocess communicationand state management.

 The component view describes the architecturally significant elements of the

implementation set and addresses the software source code realization of the system
from perspective of the project's integrators and developers.

 The deployment view addresses the executable realization of the system, including the
allocation of logical processes in the distribution view to physical resources of the
deployment network.

Generally an architecture baseline should include the following:

Requirements: critical use cases, system level quality objectives, and
priority relationship among features and qualities

Design: names, attributes, structures, behaviors, groupings and

relationships of significant classes and components
Implementation: source component inventory and bill of materials
(number, name, purpose, cost) of all primitive components

Deployment: executable components sufficient to demonstrate the

critical use cases and the risk associated with achieving the system
qualities
28
3.3 Part A Questions

1. Write a short note on artifact sets. ( May/June 2016)

Ans) To make the development of complete software system manageable, distinct collections
of information are organized into artifact sets. Artifact represents cohesive information that
typically is developed and reviewed as a single entity.
Life-cycle software artifacts are organized into five distinct sets that are roughly
partitioned by the underlying language of the set: management (ad hoc textualformats),
requirements (organized text and models of the problem space), design (models of the
solution space), implementation (human-readable programming language and associated
source files), and deployment (machine-process able languages and associated files).

2. What are minor milestones of a process? ( May/June 2016)

Ans) Minor (or micro) milestones are the monitoring points you as project manager use to
maintain control of day to day activities. They divide the elapsed time between major
milestones into shorter intervals to give you the confidence that the major milestones will be
met. They also give the team a sense of achievement by demonstrating progress on a daily or
weekly basis.

3. What is the necessity of artifact sets? (May/June 2017)

Ans) The term artifact in connection with software development is largely associated with
specific development methods or processes(such as project plans, business cases, and risk
assessments.) To make the development of a complete software system manageable, distinct
collection of information are organized into artifact set.

4. What are checkpoints of the process? (May/June 2017)

Ans) It is always important to have visible milestones in the life cycle where various
stakeholders meet, face to face, to discuss progress and plans. The purpose of these events is
not only to demonstrate how well a project is performing but also to achieve the following:
• Synchronize stakeholder expectations and achieve concurrence on three evolving
perspectives: the requirements, the design, and the plan
• Synchronize related artifacts into a consistent and balanced state
• Identify the important risks, issues, and out-of-tolerance conditions

5. What are the two essential activities of transition phase? List. (Dec-2016)
Ans) Essential activities :

 Synchronization and integration of concurrent construction into consistent

deployment baselines

 Deployment-specific engineering (commercial packaging and production, field

personnel training)
29
  Assessment of deployment baselines against the complete vision and acceptance
criteria in the requirements set

6. List the artifacts of the deployment set. (Dec-2016)

Ans) 1) integrated product baselines
2) Associated runtime files
3) User Mannuals

3.4 Part B Questions

1. Write about Lifecycle phases. (May/June 2016)

2. Differentiate implementation set versus deployment set. (May/June 2016)

3. What are the primary objectives of the four phases of software life cycle? Discuss about them.
(May/June 2017)

4. Explain about pragmatic artefacts (May/June 2017)

5. What are the primary objectives and essential activities of construction phase? Discuss.
(Dec-2016)

6. What is the need of vision document in engineering artifacts? Explain. (Dec-2016)

7. Explain in detail about the various activities in transition phase. (Dec-2016)

8.Differentiate implementation set versus deployment set. (Dec-2016)

30
 4. UNIT-IV
4.1 Introduction

4.2 software process workflows

The term workflow is used to mean a thread of cohesive and mostly sequential
activities. Workflows are mapped to product artifacts. There are seven top level
workflows:
1. Management workflow: Controlling the process and ensuring with conditions for all
stakeholders
2. Environment workflow: automating the process and evolving the
maintenance environment
3. Requirements workflow: analyzing the problem space and evolving the
requirements artifacts.
4. Design workflow: modeling the solution and evolving the architecture and esign artifacts
5. Implementation workflow: programming the components and evolving the
implementation and deployment artifacts
6. Assessment workflow: assessing the trends in process and product quality
7. Deployment workflow: transitioning the end products to the user

Four basic key principles of the modern process frame work:

1. Architecture-first approach: implementing and testing the architecture must precede
full-scale development and testing and must precede the downstream focus on
completeness and quality of the product features.
2. Iterative life-cycle process: the activities and artifacts of any given workflow may
require more than one pass to achieve adequate results.
3. Roundtrip engineering: Raising the environment activities to a first-class workflow is
critical; the environment is the tangible embodiment of the project’s process and
notations for producing the artifacts.
4. Demonstration-based approach: Implementation and assessment activities are
initiated nearly in the life-cycle, reflecting the emphasis on constructing executable
subsets of the involving architecture.

4.2.1 Explain in detail about the iteration workflows of the software process?

Iteration consists of sequential set of activities in various proportions, depending on

where the iteration is located in the development cycle. Each iteration is defined in
terms of a se t of allocated usage scenarios. The components needed to implement all
selected scenarios are developed and integrated with the results of previous iterations.
An individual iteration’s workflow illustrated in the following sequence:

31
 Management: Iteration planning to determine the content of the release and develop
the detailed plan for the iteration, assignment of work packages, or tasks, to the
development team.

Environment: evolving the software change order database to reflect all new baselines
and changes to existing baselines for all product, test and environment components

Requirements: analyzing the baseline plan, the baseline architecture, and the baseline
requirements set artifacts to fully elaborate the use cases to the demonstrated at the
end of the iteration and their evaluation criteria.

Design: Evolving the baseline architecture ad the baseline design set artifacts to
elaborate fully the design model and test model components necessary to demonstrate
against the evolution criteria allocated to this iteration.

Implementation: developing any new components, and enhancing or modifying any

existing components, to demonstrate the evolution criteria allocated to this iteration
Assessment: evaluating the results of the iteration, including compliance with the
allocated evaluation criteria and the quality of the current baselines; indentifying any
rework required and determining whether it should be performed before deployment of
this release or allocated to the next release.
Deployment: transitioning the released either to an external organization or to internal
closure by conducting a post mortem so that lessons learned can be captured and
reflected in the next iteration.
The following is an example of a simple development life cycle, illustrates the difference
between iterations and increments. This example also illustrates a typical build sequence from
the perspective of an abstract layered architecture.

32
 Iteration emphasis across the life cycle

4.2.2 Define check points of the process? Explain in detail?

It is important to have visible milestones in the life cycle , where various stakeholders meet to
discuss progress and planes. The purpose of this events is to:
 Synchronize stakeholder expectations and achieve concurrence on the requirements, the
design, and the plan.
 Synchronize related artifacts into a consistent and balanced state.
 Synchronize related artifacts into a consistent and balanced state Identify the important risks,
issues, and out-of-tolerance conditions.
 Perform a global assessment for the whole life-cycle.

Three types of joint management reviews are conducted throughout the process:

1. Major milestones –provide visibility to system wide issues, synchronize the management and
engineering perspectives and verify that the aims of the phase have been achieved.
2. Minor milestones – iteration-focused events, conducted to review the content of iteration in
detail and to authorize continued work.
3. Status assessments – periodic events provide management with frequent and regular insight
into the progress being made.

33
 MAJOR MILESTONES:

The four major milestones occur at the transition points between life-cycle phases. They can be
used in many different process models, including the conventional waterfall model. In an
iterative model, the major milestones are used to achieve concurrence among all stakeholders
on the current state of the project. Different stakeholders have very different concerns:

Customers: schedule and budget estimates, feasibility , risk assessment, requirements

understanding, progress, product line compatibility
Users: consistency with requirements and usage scenarios, potential for accommodating
growth, quality attributes.
Architectures and systems engineers: product line compatibility, requirements changes,
tradeoff analyses, completeness and consistency, balance among risk, quality, and
usability.
Developers: sufficiency of requirements detail and usuage scenario descriptions,
frameworks for component selection of development, resolution of development risk,
sufficiency of the development environment
Maintainers: sufficiency of product and documentation artifacts, understandability,
interoperability with existing systems, sufficiency of maintenance environment.
Others: possibly many other perspectives by stakeholders such as regulatory agencies,
independent verification and validation contractors, venture capital investors,
subcontractors, associate contractors, and sales and marketing teams.
The milestones may be conducted as one continuous meeting of all concerned parties or incrementally
through mostly on-line review of the various artifacts. There are considerable differences in the levels
of ceremony for these events depending on several factors.
The essence of each major milestone is to ensure that the requirements understanding, the life-cycle
plans, and the product’s form, function, and quality are evolving in balanced levels of detail and to
ensure consistency among the various artifacts. The following table summarizes the balance of
information across the major milestones.

34
MINOR MILESTONES:

All iterations are not created equal. An iteration can take on very different forms and priorities,
depending on where the project is in the life cycle. Early iterations focus on analysis and design with
substantial elements of discovery, experimentation, and risk assessment. Later iterations focus much
more on completeness, consistency, usability, and change management.

35
 Iteration readiness review: this informal milestone is conducted at the start of each iteration to
review the detailed iteration plan the evolution criteria that have been allocated to this
iteration.

Iteration Assessment review: this informal milestone is conducted at the end of each iteration
to assess the degree of which the iteration achieved its objectives and satisfied its evaluation
criteria, to review iteration achieved its objectives and satisfied its evaluation criteria, to review
iteration results, to review qualification test results, to determine the amount of rework to be
done, and to review the impact of the iteration results on the plan for subsequent iterations.

PERIODIC STATUS ASSESSMENTS:

Periodic stats assessments are management reviews conducted at regular intervals to address
progress and quality indicators, ensure continuous attention to project dynamics, and maintain open
communications among all stakeholders.

Status assessments provide the following:

A mechanism for openly addressing, communicating, and resolving management issues,

technical issues, and project risks

Objective data directly from on-going activities and evolving product configurations

A mechanism for disseminating process, progress quality trends, practices and experience
information to and from all stakeholders in an open forum.

The default content of periodic status assessments should include the topics indentified in the
following table.
28
29
 4.2.3 Define WBS and explain in detail?

 A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete
work tasks. A WBS provides the following information structure:

 A delineation of all significant work

 A clear task decomposition for assignment of responsibilities

 A framework for scheduling, budgeting, and expenditure tracking.

 The development of a work breakdown structure is dependent on the project management

style, organizational culture, customer preference, financial constraints and several other hard-
to-define parameters.

I. Conventional WBS Issues:

Conventional WBS frequently suffer from three fundamental flaws:

1. Conventional WBS are prematurely structured around the product design:

The figure following shows the typical conventional WBS that has been
structured primarily around subsystems of its product architecture, the further
decomposed into the components of each subsystem.

Once this structure is ingrained in the WBS and then allocated to responsible
managers with budgets, schedules and expected deliverables, a concrete planning
foundation has been set that is difficult and expensive to change.

(SCAN FIG1)

2. Conventional WBS are prematurely decomposed, planned, and budgeted in wither too much or
too little detail:

Large software projects tend to be over planned and small projects tend to be under
planned. The WBS shown in the above figure is overly simplistic for most large scale systems,
where size or more levels of WBS elements are commonplace.

3. Conventional WBS are project-specific, and cross-project comparisons are usually difficult or
impossible:

30
 Most organizations allow individual projects to define their own project-specific structure
tailored to the project manager’s style, the customer’s demands, or other project-specific
preferences.

It is extremely difficult to compare plans, financial data, schedule data, organizational

efficiencies, cost trends, productivity tends, or quality tends across multiple projects.

Some of the following simple questions, which are critical to any organizational process
improvement program, cannot be answered by most project teams that use conventional WBS.

o What is the ratio of productive activities to overhead activities?

o What is the percentage of effort expanded in rework activities?

o What is the percentage of cost expended in software capital equipment

o What is the ration of productive testing versus integration?

o What is the cost of release?

II. Evolutionary Work Breakdown Structures:

An evolutionary WBS should organize the planning elements around the process framework
rather than the product framework. The basic recommendation for the WBS is to organize the
hierarchy as follows:

 First level WBS elements are the workflows(Management, environment, requirement, design,
implementation, assessment, and deployment)

 Second level elements are defined for each phase of the life cycle(inceptions, elaboration,
construction and transition)

 Third level elements are defined for the focus of activities that produce the artifacts of each
phase.

A default WBS consistent with the process framework (phases, workflows, and artifacts)
is shown in the following figure

The structure shown is intended to be merely a starting point. It needs to be tailored to

the specifics of a project in many ways.

Scale: Larger projects will have more levels and substructures.

31
 Organizational structure: projects that include subcontractors or span multiple
organizational entities may introduce constraints that necessitate different WBS
allocations.

Degree of custom development: depending on the character of the project there

can be very different emphases in the requirements, design, and implementation
workflows. A business process re-engineering project based primarily on existing
components would have much more depth in the requirements elements and a
fairly shallow design and implementation element.

Business context: contractual projects require much more elaborate

management and assessment elements. Projects developing commercial
products for delivery to a board customer base may require much more
elaborate substructures for the deployment element.

Precedent experience: very few projects start with a clean state. Most of them
are developed as new generations of a legacy system or in the context of existing
organizational standards. It is important to accommodate these constraints to
ensure that new projects exploit the existing experience base and benchmarks of
project performance.

4.2.4 Write short notes on planning guidelines?

Software projects span a board range of application domains. It is valuable but risky to make
specific planning recommendations independent of project context.
Project independent planning advice is also risky. There is the risk that the guidelines may be
adopted blindly without being adapted to specific project circumstances. There is also the risk of
misinterpretation.
Two simple planning guidelines should be considered when a project plan is being initiated or
assessed.
 The first guideline prescribes a default allocation of costs among the first-level WBS
elements.
 The second guideline prescribes the allocation of effort and schedule across the life
cycle phases.
Given an initial estimate of total project cost and these two tables, developing a staffing
profile, and allocation of staff resources to reams, a top-level project schedule, and an initial
WBS with task budgets and schedules is relatively straightforward.

32
 FIRST-LEVEL DEFAULT
WBS ELEMENT BUDGET

Management 10%

Environment 10%

Requirements 10%

Design 15%

Implementation 25%

Assessment 25%

Deployment 5%

Total 100%

The first guideline prescribes a default allocation of costs among the first-level WBS elements

The above table provides default allocations for budgeted costs of each first-level WBS
element. While these values are certain to vary across projects, this allocation provides a good
benchmark for assessing the plan by understanding the rationale for deviations from these guidelines.
An important point here is that this is cost allocation, not effort allocation. To avoid misinterpretation
two explanations are necessary

 The cost of different labor categories is inherent in these numbers

 The cost of hardware and software assets that support the process automation
and development teams is also included in the environment element.

DOMAIN INCEPTION ELABORATION CONSTRUCTION TRANSITION

Effort 5% 20% 65% 10%

Schedule 10% 30% 50% 10%

33
The second guideline prescribes the allocation of effort and schedule across the life-cycle phases

The above table provides guidelines for allocating effort and schedule across the life cycle
phases. Although these values can also vary widely depending on the specific constraints of an
application, they provide an average expectation across a spectrum of application domains.

4.2.5 Explain the cost and schedule estimating process?

Project plans need to be derived from two perspectives.

The first is a forward-looking top-down approach. It starts with as understanding of the general
requirements and constraints, derives a macro –level budgets and intermediate milestones .

Forward-looking:

 The software project manager develops a characterization of the overall

size, process, environment, people, and quality required for the project

 A macro-level estimate of the total effort and schedule is developed using

a software cost estimation model

 The software project manager partitions the estimate for the effort into a
top-level WBS, also partitions the schedule into major milestone dates
and partitions the effort into a staffing profile

 At this point, subproject managers are given the responsibility for

decomposing each of the WBS elements into lower levels using their top-
level allocation, staffing profile, and major milestone dates as constraints.

The second perspective is a backward-looking, bottom-up approach. We start

with the end in mind, analyze the micro-level budgets and schedules, the sum all these
elements into the higher level budgets and intermediate milestones.

Backward-looking:

1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets
and schedules are estimated by the responsible WBS element manager.

2. Estimates are combined and integrated into higher level budgets and milestones.

34
 3. Comparisons are made with the top-down budgets and schedule milestones. Gross
differences are assessed and adjustments are made in order to converge on agreement
between the top-down and the bottom-up estimates.

These two planning approaches should be used together, in balance, throughout the life
cycle of the project. During the engineering stage, the top-down perspective will dominate.
During the production stage, these should be enough precedent experience and planning
fidelity that the bottom up planning perspective will dominate.

By then, the top-down approach should be well tuned to the project specific
parameters, so is should be used more as a global assessment technique. The following figure
shows this life cycle planning balance.

4.2.6 What are the types of responsibilities does the project organizations have? Line of

Business Organizations:

Maps roles and responsibilities to a default line-of-business organization. This structure

can be tailored to specific circumstances.

The main features of the default organization are as follows:

o Responsibility for process definition and maintenance is specific toa cohensive line
of business where process commonality makes sense. For example the process of
developing avionics software is different from the process used to develop office
applications.

35
 o Responsibility for process automation, is an organizational role and its equal in
importance to the process definition role.

o Organizational role may be fulfilled by a single individual or several different

teams, depending on the scale of the organization.

Software Engineering Process Authority:

The Software Engineering Process Authority (SEPA) facilitates the exchange of

information and process guidance both to and from project practitioners. The SEBA must help
initiate and periodically assess project process. The SEBA is necessary role in any organization.
The SEBA could be a single individual, the general manager, or even a team of representatives.
The SEBA must truly be an authority, competent and powerful.

Project Review Authority:

The project review authority (PRA) is the single individual responsible for ensuring that a
software project complies with all organizational and business unit software policies, practices,
and standards. The PRA reviews both the project’s conformance to contractual obligations and
the project’s organizational policy obligations. The customer monitors contract requirements,
contract milestones, contract deliverable, monthly management reviews, progress, quality,
cost, schedule and risk. The PRA reviews customer commitments as well as adherence to
organizational policies, organizational deliverables, and financial performance and other risks
and accomplishments.

Software Engineering Environment Authority:

The Software Engineering Environment Authority (SEEA) is responsible for automating

the organizations process, maintaining the organizations standard environment, training

36
project to use environment, and maintain organization-wide reusable assets. The SEEA rule is
necessary to achieve significant return on investment for a common process.

Infrastructure:

An organization infrastructure provides human resource support, project-independent

research and development, and other capital software engineering assets. The typical
components of the organizational infrastructure are as follows

 Project Administration:

Time accounting system; contracts, pricing, terms and condition; corporate

information system integration.

 Engineering Skill Centers:

Custom tools repository and maintenance, bid and proposal support,

ind3ependent research and development.

 Professional Development:

Internal training boot camp, personnel recruiting, personnel skills database

maintenance, literature and assets library, technical publications.

4.2.7 Explain in detail about Project Organizations and how it handle their teams?

A default project organization and maps project-level roles and responsibilities. The structure
can be tailored to the size and circumstances of the specific project organization. The main
features of the default organization are as follows.

 The project management team is an active participant, responsible for producing as well
as managing.

 The architecture team is responsible for real artifacts and for the integration of
components, not just for staff function.

 The development team owns the component construction and maintenance activities.

 Quality is everyone job, integrated into all activities and check points. Each team take
responsibility for a different quality perspective.

37
Software Management Team:

Most project are over constrained. Schedules, cost, functionality and quality
expectations are highly inter related and require continuous negotiation among multiple stake
holders who have different goals. The software management team carries the burden of
delivering with condition to all stake holders. The software management team takes ownership
of all aspects of quality.

Software Architecture Team:

The software architecture team is responsible for the architecture. This responsibility
encompasses the engineering necessary to specify a complete bill of materials for the software
and the engineering necessary to make significant make/ buy trade-offs so that all custom
components are elaborated to the extent that construction/assembly costs are highly
predictable.

In most projects, the inception and elaboration phases will be dominated by two distinct
teams: the software management team and the software architecture team. To succeed, the
architecture must include a fairly broad level of expertise, including the following:

 Domain experience to produce an acceptable design view ( architecturally significant

element s of the design model) and use case view (architecturally significant element s
of the use case model).

 Software technology experience to produce an acceptable process view(concurrency

and control thread relationships among the design, component, and deployment
models), component view (structure of the implementation set), and deployment
view(structure of the deployment set).

38
Software development team:

The software development team is the most application specific group. In general, the
software development team comprise several sub teams dedicated to groups of components
that require a common skill set. The typical skill set include the following:
 Commercial component:
Specialists with detail knowledge of commercial components central to a
system’s architecture
 Database: specialists with experience in the organization, storage, and retrieval of data
 Graphical user interfaces: specialists with experience in the display organization, data
presentation, and user interaction.
 Operating systems and networking: specialist with experience in the execution of
multiple software objects on a network of hardware resources.
 Domain applications: specialists with experience in the algorithms, application
processing.

39
 The software development team is responsible for the quality of individual components,
including all component development, testing, and maintenance. Components tests
should be built as self-documented.

Software Assessment Team:

There are two reasons for using an independent team for software assessment. It
has to do with ensuring an independent quality perspective. A more important reason
for using an independent test team is to exploit the concurrency of activities.

A modern process should employ use-case-oriented or capability –based testing

(which may span many components). Organized as a sequence of builds and
mechanized via two artifacts.

 Release specification (the plan and evaluation criteria for a release)

 Release description( the results of a release)

4.2.8 Explain in detail about the evaluation of organizations?

The project organization represents the architecture of the team and needs to evolve
consistent with the project plan captured in the work breakdown structure. The following
figure illustrates how the team’s centre of gravity shifts over the life cycle, with about 50% of
the staff assigned to one set of activities in each phase

A different set of activities is emphasized in each phase, as follows:

40
 Inception team: an organization focused on planning, with enough support from the
other teams to ensure that the plans represent a consensus of all perspectives.

 Elaboration team: an architecture focused organization in which the driving forces of

the project reside in the software architecture team and are supported by the
software development software assessment teams has necessary to achieve a stable
architecture baseline

 Construction team: a fairly balanced organization in which most of the activity resides
in the software development and software assessment teams

 Transition team: a customer focus organization in which usage feedback drives

the deployment activities.

4.2.9 What are all the automation tools available for building blocks in software
process?

Many tools are available to automate the software development process. Most
of the core software development tools map closely to one of the process
workflows, as illustrated in the following figure. Each of the process workflows
has a distinct for automation support.

Management: there are many opportunities for automating the project planning
and control activities of the management work flows. Software cost estimating
tools and WBS tools are usual for generating the planning artifacts.

Environment: configuration management and version control are essential in a

modern interactive development process
41
 Requirements: conventional approaches decomposed system requirements into
subsystems requirements, subsystem requirements into component requirement
and component requirements into unit requirements. In a modern project the
system requirements are captured in the vision statement. Lower levels of
requirements are driven the process organized by iteration rather than by lower
level component.

Design: the primary support required for the design work flow is visual modeling,
which is used for capturing design models, presenting them in human readable
format, and translating them into source code. An architecture first and
demonstration based process is enabled by existing architecture components and
middle ware.

Implementation: the implementation work flow relies primarily on a

programming environment but must also include substantial integration with the
change management tools, visual modeling tools, and test automation tools to
support productive iteration.

Assessment and deployment: the assessment workflows require all the tools just
discussed as well as additional capabilities to support test automation and test
management. Defect tracking is another important that supports assessment.

How can we making scale between small scales project Vs large scale projects?

The lists elaborate some of the key differences in discriminators of success. None of
these process components is unimportant although some of them are more
important than others. ‘

Design is key in both domains. Good design of a commercial product is a key

differentiator in the market place and is the foundation for efficient new
product releases.

Management is paramount in large projects where the consequences of

planning errors , resource allocation errors, inconsistent stake holder
expectation, and other out of banlaned factors we can have catastrophic
consequences for the overall team dynamics

Deployment plays a far greater role for a small commercial product because
there is a broad user base of diverse individuals and environments

42
 Rank Large Complex Small
Project Commercial
Project

1 Management Design

2 Design Implementation

3 Requirements Deployment

4 Assessment Requirements

5 Environment Assessments

6 Implementation Management

7 Deployment Environment
Differences in workflow priorities between small and large projects

4.3 Part A Questions

1. Define backup plan. ( May/June 2016)
Ans) A contingency plan is essentially a “Plan B.” It's a backup plan in place for when things go
Differently than expected. In other words, a contingency plan in project management is a
defined, actionable plan that is to be enacted if an identified risk becomes a reality.

2. Define peer inspections. (May/June 2016)

Ans) Inspection in software engineering refers to peer review of any work product by
trained individuals who look for defects using a well defined process. An inspection might
also be referred to as a Fagan inspection after Michael Fagan, the creator of a very popular
software inspection process.

3. Define earned value analysis. (May/June 2017)

Ans)
 Earned Value Analysis is an objective method to measure project performance in
terms of scope, time and cost.
 EVA metrics are used to measure project health and project performance.
 Earned Value Analysis is a quantitative technique for assessing progress as the
software project team moves through the work tasks, allocated to the Project
Schedule.
 EVA provides a common value scale for every project task.
 Total hours to complete the project are estimated and every task is given an Earned
Value, based on its estimated (%) of the total.
43
 Earned Value is a measure of ‘Progress’ to assess ‘Percentage of Completeness’
 4. Define project environment. (May/June 2017)
Ans) Project environment represents a connection, where the project is processed. It
impacts the project and is, therefore, conditioned. Such an interaction is provided by
numerous factors as operational, physical, ecological, social, cultural, economic,
psychological, financial, organizational etc.

5. Define minor milestone. (Dec-2016)

Ans) Minor (or micro) milestones are the monitoring points you as project
manager use to maintain control of day to day activities. They divide the elapsed
time between major milestones into shorter intervals to give you the confidence
that the major milestones will be met.

4.4 Part B Questions

1. Briefly explain how iteration emphasis across the lifecycle. ( May/June 2016)
2. What are the four component teams in a default line of business organization and their
Responsibilities? (May/June 2016)
3. Briefly explain about iteration workflows (May/June 2017)
4. What are the sources of change? Why should change be made in a controlled?
Way? (May/June 2017)
5. Define workflow. Explain in detail about the seven top level software process
Workflows. (Dec-2016)
6.Explain briefly about the four major milestones that occur at the transition points between life
Cycle phases. (Dec-2016)

44
 5. UNIT-V
5.1Introduction

5.2 PROJECT CONTROL & PROCESS INSTRUMENTATION

INTERODUCTION: Software metrics are used to implement the activities and products
of the software development process. Hence, the quality of the software products and
the achievements in the development process can be determined using the software
metrics.

Need for Software Metrics:

 Software metrics are needed for calculating the cost and schedule of a software
product with great accuracy.
 Software metrics are required for making an accurate estimation of the progress.
 The metrics are also required for understanding the quality of the software product.

5.2.1 INDICATORS:
An indicator is a metric or a group of metrics that provides an understanding of the
software process or software product or a software project. A software engineer
assembles measures and produce metrics from which the indicators can be derived.
Two types of indicators are:
(i) Management indicators.
(ii) Quality indicators.

Management Indicators
The management indicators i.e., technical progress, financial status and staffing progress are
used to determine whether a project is on budget and on schedule. The management
indicators that indicate financial status are based on earned value system.
Quality Indicators
The quality indicators are based on the measurement of the changes occurred in software.

SEVEN CORE METRICS OF SOFTWARE PROJECT

Software metrics instrument the activities and products of the software
development/integration process. Metrics values provide an important perspective for
managing the process. The most useful metrics are extracted directly from the evolving
artifacts.
There are seven core metrics that are used in managing a modern process.

45
Seven core metrics related to project control:

Management Indicators Quality Indicators

Work and Progress Change traffic and stability
Budgeted cost and expenditures Breakage and modularity
Staffing and team dynamics Rework and adaptability
Mean time between failures (MTBF) and maturity
5.2.2 MANAGEMENT INDICATORS:
Work and progress
This metric measure the work performed over time. Work is the effort to be accomplished
to complete a certain set of tasks. The various activities of an iterative development
project can be measured by defining a planned estimate of the work in an objective
measure, then tracking progress (work completed overtime) against that plan.
The default perspectives of this metric are:
Software architecture team: - Use cases demonstrated.
Software development team: - SLOC under baseline change management, SCOs closed
Software assessment team: - SCOs opened, test hours executed and evaluation criteria
meet. Software management team: - milestones completed.

The below figure shows expected progress for a typical project with three major
releases
Fig: work and progress
Budgeted cost and expenditures
This metric measures cost incurred over time. Budgeted cost is the planned expenditure profile
over the life cycle of the project. To maintain management control, measuring cost expenditures
over the project life cycle is always necessary. Tracking financial progress takes on an
organization - specific format. Financial performance can be measured by the use of an earned
value system, which provides highly detailed cost and schedule insight. The basic parameters of
an earned value system, expressed in units of dollars, are as follows:
Expenditure Plan - It is the planned spending profile for a project over its planned schedule.
Actual progress - It is the technical accomplishment relative to the planned progress underlying
the spending profile.
Actual cost: It is the actual spending profile for a project over its actual
schedule. Earned value: It is the value that represents the planned
cost of the actual progress. Cost variance: It is the difference between
the actual cost and the earned value.
Schedule variance: It is the difference between the planned cost and the earned value. Of all
parameters in an earned value system, actual progress is the most subjective
Assessment: Because most managers know exactly how much cost they have incurred and how
much schedule they have used, the variability 46 in making accurate assessments is centred in the
actual progress assessment. The default perspectives of this metric are cost per month, full-time
staff per month and percentage of budget expended.
Staffing and team dynamics
This metric measures the personnel changes over time, which involves staffing additions and
reductions over time. An iterative development should start with a small team until the risks in
the requirements and architecture have been suitably resolved. Depending on the overlap of
iterations and other project specific circumstances, staffing can vary. Increase in staff can slow
overall project progress as new people consume the productive team of existing people in
coming up to speed. Low attrition of good people is a sign of success. The default perspectives of

this metric are people per month added and people per month leaving. These three
management indicators are responsible for technical progress, financial status and staffing
progress.

Budgeted cost and expenditures

This metric measures cost incurred over time. Budgeted cost is the planned expenditure profile
over the life cycle of the project. To maintain management control, measuring cost expenditures
over the project life cycle is always necessary. Tracking financial progress takes on an
organization - specific format. Financial performance can be measured by the use of an earned
value system, which provides highly detailed cost and schedule insight. The basic parameters of
an earned value system, expressed in units of dollars, are as follows:
Expenditure Plan - It is the planned spending profile for a project over its planned schedule.
Actual progress - It is the technical accomplishment relative to the planned progress underlying
the spending profile.
Actual cost: It is the actual spending profile for a project over its actual schedule. Earned
value: It is the value that represents the planned cost of the actual progress. Cost variance: It is
the difference between the actual cost and the earned value.
Schedule variance: It is the difference between the planned cost and the earned value. Of all
parameters in an earned value system, actual progress is the most subjective
Assessment: Because most managers know exactly how much cost they have incurred and how
much schedule they have used, the variability 47 in making accurate assessments is centred in the
actual progress assessment. The default perspectives of this metric are cost per month, full-time
 staff per month and percentage of budget expended.
Staffing and team dynamics
This metric measures the personnel changes over time, which involves staffing additions and reductions
over time. An iterative development should start with a small team until the risks in the requirements
and architecture have been suitably resolved. Depending on the overlap of iterations and other project
specific circumstances, staffing can vary. Increase in staff can slow overall project progress as new
people consume the productive team of existing people in coming up to speed. Low attrition of good
people is a sign of success. The default perspectives of this metric are people per month added and
people per month leaving. These three management indicators are responsible for technical progress,
financial status and staffing progres

Fig: staffing and Team dynamics

5.2.3 QUALITY INDICATORS:

Change traffic and stability:

This metric measures the change traffic over time. The number of software change orders
opened and closed over the life cycle is called change traffic. Stability specifies the relationship
between opened versus closed software change orders. This metric can be collected by change
type, by release, across all releases, by term, by components, by subsystems, etc.

48
 The below figure shows stability expectation over a healthy project’s life cycle

Fig: Change traffic and stability

Breakage and modularity

This metric measures the average breakage per change over time. Breakage is defined as the
average extent of change, which is the amount of software baseline that needs rework and
measured in source lines of code, function points, components, subsystems, files or other units.
Modularity is the average breakage trend over time. This metric can be collected by revoke SLOC
per change, by change type, by release, by components and by subsystems.
Rework and adaptability:
This metric measures the average rework per change over time. Rework is defined as the
average cost of change which is the effort to analyse, resolve and retest all changes to software
baselines. Adaptability is defined as the rework trend over time. This metric provides insight into
rework measurement. All changes are not created equal. Some changes can be made in a staff-
hour, while others take staff-weeks. This metric can be collected by average hours per change,
by change type, by release, by components and by subsystems.
MTBF and Maturity: 49
This metric measures defect rather over time. MTBF (Mean Time Between Failures) is the
average usage time between software faults. It is computed by dividing the test hours by the
number of type 0 and type 1 SCOs. Maturity is defined as the MTBF trend over time. Software
errors can be categorized into two types deterministic and nondeterministic. Deterministic
errors are also known as Bohr-bugs and nondeterministic errors are also called as Heisen-bugs.
Bohr-bugs are a class of errors caused when the software is stimulated in a certain way such as
coding errors. Heisen-bugs are software faults that are coincidental with a certain probabilistic
occurrence of a given situation, such as design errors. This metric can be collected by failure
counts, test hours until failure, by release, by components and by subsystems. These four quality
indicators are based primarily on the measurement of software change across evolving baselines
of engineering data.

5.2.4 LIFE -CYCLE EXPECTATIONS:

There is no mathematical or formal derivation for using seven core metrics properly. However,
there were specific reasons for selecting them:
The quality indicators are derived from the evolving product rather than the artifacts.They
provide inside into the waste generated by the process. Scrap and rework metrics are a standard
measurement perspective of most manufacturing processes. They recognize the inherently
dynamic nature of an iterative development process. Rather than focus on the value, they
explicitly concentrate on the trends or changes with respect to time.The combination of insight
from the current and the current trend provides tangible indicators for management action.
Table 13-3. the default pattern of life cycle evolution

Metric Inception Elaboration Construction Transition

Progress 5% 25% 90% 100%

Architecture 30% 90% 100% 100%

Applications <5% 20% 85% 100%

Expenditures Low Moderate High High

Effort 5% 25% 90% 100%

Schedule 10% 40% 90% 100%

Staffing Small team Ramp up Steady Varying

50
Stability Volatile Moderate Moderate Stable
 Architecture Volatile Moderate Stable Stable

Applications Volatile Volatile Moderate Stable

Modularity 50%-100% 25%-50% <25% 5%-10%

Architecture >50% >50% <15% <5%

>80% >80% <25% <10%

Applications

5.2.5 METRICS AUTOMATION:

Many opportunities are available to automate the project control activities of a software project.
A Software Project Control Panel (SPCP) is essential for managing against a plan. This panel
integrates data from multiple sources to show the current status of some aspect of the project.
The panel can support standard features and provide extensive capability for detailed situation
analysis. SPCP is one example of metrics automation approach that collects, organizes and
reports values and trends extracted directly from the evolving engineering artifacts.

SPCP:
To implement a complete SPCP, the following are necessary.
 Metrics primitives - trends, comparisons and progressions
 A graphical user interface.
 Metrics collection agents
 Metrics data management server
 Metrics definitions - actual metrics presentations for requirements progress,
implementation progress, assessment progress, design progress and other progress
dimensions.
 Actors - monitor and administrator.

Monitor defines panel layouts, graphical objects and linkages to project data. Specific monitors
called roles include software project managers, software development team leads, software
architects and customers. Administrator installs the system, defines new mechanisms, graphical
objects and linkages. The whole display is called a panel. Within a panel are graphical objects,
which are types of layouts such as dials and bar charts for information. Each graphical object
displays a metric. A panel contains a number of graphical objects positioned in a particular
geometric layout. A metric shown in a graphical object is labelled with the metric type, summary
level and insurance name (line of code, subsystem, server1). Metrics can be displayed in two
modes – value, referring to a given point in time and graph referring to multiple and consecutive
points in time. Metrics can be displayed with51 or without control values. A control value is an
existing expectation either absolute or relative that is used for comparison with a dynamically
 changing metric. Thresholds are examples of control values.

The basic fundamental metrics classes are trend, comparison and progress.

The format and content of any project panel are configurable to the software project manager's
preference for tracking metrics of top-level interest. The basic operation of an SPCP can be described by

the following top - level use case.

i. Start the SPCP
ii. Select a panel preference
iii. Select a value or graph metric
iv. Select to superimpose controls
v. Drill down to trend
vi. Drill down to point in time.
vii. Drill down to lower levels of information
viii. Drill down to lower level of indicators.

5.3 Part A Questions:

1. What is meant by configuration baseline?(may/june -2016)

Ans) In configuration management, a "baseline" is an agreed description of the attributes of a
product, at a point in time, which serves as a basis for defining change. ... Generally, a baseline
may be a single work product, or set of work products that can be used as a logical basis for
comparison.

52
 2.What are included in architecture baselines?(may/june-2017)
Ans) This service provides the organization an initial Enterprise Architecture (EA) Baseline.
An architecture baseline is the “as is” or “current” architecture. The architecture baseline
includes architecture assets from all architecture domains. ... Business policies, business
practices, and business processes.

3. Define stakeholder environment.(may/june-2017)

Ans) A project stakeholder is any individual or an organization that is actively involved in a
project, or whose interest might be affected (positively or negatively) as a result of project
execution or completion. Software project management is the integration of management
techniques to software development.

4. Define breakage and modularity(may/june-2017)

Ans) Stability is defined as the relationship between opened versus closed SCOs. BREAKAGE
AND MODULARITY. Breakage is defined as the average extent of change, which is the
amount of software baseline that needs rework. Modularity is the average breakage trend
over time.

5.Explain process maturity level.(may/june-2017)

Ans) The Capability Maturity Model (CMM) is a methodology used to develop and refine an
organization's software development process. The model describes a five-level
evolutionary path of increasingly organized and systematically more mature processes.

Define stakeholder environment

5.4 part B Questions:

1.What are seven core metrics related to project control?
What are included in ar
2.Define the SEI-CMM maturity levels of organizations. How do processes differ because of process
flexibility and process maturity?(may/june-2016)

3.Explain about quality and management indicators.(may/june-2017)

4.Describe in detail about the basic characteristics of good matrices.(may/june-2017)

53
5.Explain how modern process profiles resolve the issues of continuous integration
(may/june-2017)

6. What are the seven core metrics used for all software projects? Explain
(may/june-2017).

54