UNIT 4

1 CHECKPOINTS OF THE PROCESS – INTRODUCTION

Need for checkpoints

-- Stakeholders meet face to face.
-- Demonstrate how well the project is going on.
-- Discuss progress and plans.
-- Synchronize stakeholder expectations throughout the life cycle.
-- To achieve concurrence between requirements, design and plan.
-- Synchronize artifacts and check their consistency.
-- Identify important risks and issues.
-- Perform global assessment for whole life cycle.
There are 3 types of joint management reviews conducted through the process –
1. Major Milestones
2. Minor Milestones
3. Status Assessments
-- Milestones must have well-defined expectations and provide tangible results.
-- Milestones and their objectives must be renegotiable as the project’s requirements evolve and
plans change.
-- The number of milestones varies depending upon the project’s context, size of the project,
complexity, user community, risks, cost, schedule etc.
-- The figure below shows typical sequence of checkpoints for a large project.

2 PERIODIC STATUS ASSESSMENTS

 These periodic events provide management with frequent and regular insight into the progress
being made.
 Are management reviews conducted monthly/quarterly/as required.
 To have continuous attention of the software development activities and dynamics.
 It encourages periodic review of project’s progress and quality.
 Provides communication between management and stakeholders.
 To manage risks early and assess health of the project.
 To capture and record project’s history – recording information in standard format encourages
project-to-project comparison, research, forecasting etc.

Objectives
 Openly address, communicate and resolve management, technical and project issues.
 Derive objective data directly from on-going activities and evolving product configurations.

Dr. G. Sunitha, CSE, SVEC 1

  Disseminate process, progress, quality, practices, experience and other information to/from
stakeholders.
Successful Projects include status assessments that are
 Low overhead activities where material is documented as everyday management data.
 Meetings are rarely canceled.

Unsuccessful Projects include status assessments that are

 High overhead activities where status assessment work is separate from everyday work.
 Meetings are frequently canceled.

 These meetings force software project manager to

-- Collect and review the data periodically
-- Disseminate software best practices
-- Outside peer review
-- Follow standard format and metrics
-- Efficiently perform project-to-project comparisons.
 For simpler projects, these meetings may be infrequent (ex: quarterly).

3 MINOR MILESTONES

 Iteration focused events – meetings to review content of iteration in detail.

 Meetings conducted at the end of iteration.
 Iteration represents a cycle of activities for which there is a well-defined intermediate result.
 A minor milestone captures 2 artifacts –
Release Specification – evaluation criteria and plan
Release Description – results of the iteration.
 All iterations are not equal and may take many forms and priorities depending upon where the
iteration is in the life cycle. Early iterations focus on analysis and design. Later iterations focus on
completeness, consistency, risk assessment etc.
 Number of minor milestones depends on the content and length of iteration.
 For simpler projects, very few or no minor milestones may be necessary.
 If iteration is of duration 1 month to 6 months 2 milestones are enough.
Iteration Readiness Review – conducted at the start of each iteration to discuss detailed
plan, evaluation criteria etc for the iteration.
Iteration Assessment Review – conducted at the end of each iteration, to assess
achievements of current iteration, to review results, to determine amount of rework to be
done, objectives of next iteration etc

Dr. G. Sunitha, CSE, SVEC 2

  Large, unprecedented projects may use intermediate walkthroughs along with above 2 meetings.
 Format and content of these minor milestones is dependent on the project.

4 MAJOR MILESTONES

 Conducted at the end of each life-cycle phase.

 Provides insight into system-wide issues.
 To evaluate product against acceptance criteria.
 To support agreement with stakeholders.
 To ensure that requirements understanding, life-cycle plans, product’s form, function, quality are
evolving as expected.
 Support for on-line reviews encourages the process.
 Most projects go with 4 major milestones. May be increased or decreased depending on project.
 A Stakeholder is a person or organization that has a legitimate interest in a project or entity.
A person, group, or organization that has direct or indirect stake in an organization because it can
affect or be affected by the organization's actions, objectives, and policies.
 Different stakeholders have different concerns –

Stakeholders Concerns

Customers Progress, Schedule, Budget, Quality, Risks etc

Users Consistency, Usage, Growth, Compatibility etc

Architects and Requirements changes, Trade-off analyses, Completeness,

System Engineers Consistency, Compatibility, Quality, Risks etc

Sufficiency of requirements and design details, Sufficiency of usage

Developers scenario descriptions, Resolution of development risks, Compatibility,
Development environment etc

Sufficiency of product and maintenance documents,

Maintainers Understandability, Maintenance environment, Interoperability with
existing systems etc

Dr. G. Sunitha, CSE, SVEC 3

 Others Investors, Contractors, Sales Engineers, Servicing Team etc

 Different meetings may be conducted for different stakeholders.

 At the end of each phase 1 major milestone meeting is conducted.

Phase Major Milestone Plans

Definition of stakeholder responsibilities

Inception Life-cycle Objectives Milestone High-fidelity Elaboration Phase Plan
Low-fidelity Construction Phase Plan

High-fidelity Construction Phase Plan

Elaboration Life-cycle Architecture Milestone
Low-fidelity Transition Phase Plan

Initial Operational Capability

Construction High-fidelity Transition Phase Plan
Milestone

Transition Product Release Milestone Next-Generation Product Plan

4.1 LIFE-CYCLE OBJECTIVES MILESTONE

 Conducted at the end of Inception Phase.

 Presents recommendations on
-- How to proceed with design, development etc
-- Estimated cost and schedule
-- Expected benefits, Cost savings
-- Vision Statement, Requirements and Specifications
-- Operational Concept, Use case models
-- Critical Issues, Resolution plans
-- Draft Architecture Document, Prototype Architecture Demonstration
-- Definition of Stakeholder responsibilities
 Successful meeting authorizes to proceed with elaboration phase.

4.2 LIFE-CYCLE ARCHITECTURE MILESTONE

 Conducted at the end of Elaboration Phase.

 Demonstrate executable architecture to all stakeholders.
 Demonstrate -- High-fidelity Construction Phase Plan
-- Low-fidelity Transition Phase Plan
 Demonstrate stable vision and use case model.
 Address critical issues relative to requirements and operational concept.
 Demonstrate Evaluation Criteria for initial operational capability milestone.
Dr. G. Sunitha, CSE, SVEC 4
  Produce consensus on baseline architecture, design, vision etc.
 Draft user manual.
 Capture baseline architecture in 2 forms -- Human-readable form as well as in the form of
engineering artifacts.
 From contractual point of view, this milestone takes stand in transitioning the project from
engineering stage to production stage. A project ready for this transition exhibits following
 characteristics –
-- Critical use cases defined
-- Stable architecture has been baselined
-- Risk profile is well understood
-- Development plan for construction and transition phases is well defined
 Successful meeting authorizes to proceed with construction phase.

4.3 INITIAL OPERATIONAL CAPABILITY MILESTONE

 Conducted at the end of Construction Phase.

 Demonstrate High-fidelity Transition Phase Plan.
 Assess the readiness of the product for transition.
 Assess the readiness of test environment and test software for acceptance testing.
 Discuss issues regarding installations, versions, user manuals, supporting users etc.
 Review software quality for transition.
 Review the releasable user manual.
 Successful meeting authorizes to proceed with transition phase.
 The initiation of transition phase is not necessarily the completion of the construction phase. These
phases may overlap.

4.4 PRODUCT RELEASE MILESTONE

 Conducted at the end of Transition Phase.

 Assess completion of software to support organizational needs.
 Review results of acceptance testing.
 Review manuals – installation & configuration manuals, user manuals, product manuals,
maintenance manuals, supporting users etc.
 Review software quality for release.
 Review installations at user sites.
 Successful meeting authorizes to proceed with the release of final product to the client or into the
market.

5 ITERATIVE PROCESS PLANNING

 Plan is an intangible piece of intellectual property.
 Engineering Stage – plan is developed, Production Stage – Plan is executed.
 Plans must evolve as the understanding of the problem and solution evolves.
 Planning errors must be resolved early in the life cycle.
 Project plans are highly dependent on numerous parameters.
 Projects must not be under-planned or over-planned. There must be balance in the level of
planning detail.
 WBS
 Planning Guidelines
 Cost and Schedule Estimating Process
 Iteration Planning Process
 Pragmatic Planning

6 WORK BREAKDOWN STRUCTURE

 Activity breakdown and financial tracking mechanism.

 Structure of cost accountability is a serious planning constraint
Dr. G. Sunitha, CSE, SVEC 5
  It is a planning artifact.
 WBS is vehicle for budgeting and collecting costs, to monitor and control project’s financial
performance.
 WBS is architecture for financial plan. It provides a framework for schedule, budget and
expenditure.
 Development of WBS is dependent on management style, customer preference, organizational
culture, financial constraints etc.
 Plan should be loosely coupled with the product and process to let it evolve as the product
matures.
 Parameters that drive decomposition of work into discrete tasks are – Product subsystems, Life-
cycle phases, components, functions, organizational teams etc.
 WBS is simply a hierarchy of elements that decomposes the project plan into 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

6.1 CONVENTIONAL WBS ISSUES

Conventional WBS frequently suffer from 3 fundamental flaws—

1. They are prematurely structured around the product design
2. They are prematurely decomposed, planned and budgeted in either too much or too little detail.
3. They are project-specific and cross-project comparisons are usually difficult or impossible.

1. They are prematurely structured around the product design

Once this structure is ingrained and allocated to responsible managers, they will prepare a
concrete planning foundation for each of the sub tasks. Conventional WBS following the product
hierarchy is as follows --
Management
System requirements and design
Subsystem 1
Component 11
{ Requirements, Design, Code, Test, Documentation, . . . }
Component 1N
{ Requirements, Design, Code, Test, Documentation, . . . }
:
:
:
Subsystem M
Component M1
{ Requirements, Design, Code, Test, Documentation, . . . }
Component MN
{ Requirements, Design, Code, Test, Documentation, . . . }

Integration and test

{ Test Planning, Test procedure preparation, Testing, Test reports }
Other support areas
{ Configuration control, Quality assurance, System administration }
Dr. G. Sunitha, CSE, SVEC 6
 2. They are prematurely decomposed, planned and budgeted in either too much or too
little detail.

Large software projects

– Over planned.
– 6 or more levels of WBS.
– Plans out each element in complete detail with a baseline budget and schedule for
every task.
– Planning with too much detail does not allow plan to evolve with project.
Small software projects
– Under planned.
– May be single level WBS with least or no detailing.
– Coarse tasking, cost and schedule accountability.
– Unsuccessful project.
Balance is needed in WBS

3. They are project-specific and cross-project comparisons are usually difficult or

impossible.
With no standard WBS format, it is difficult to compare plans, schedules, project data, efficiency,
trends, quality etc of multiple projects. For example the following questions which are critical to
process improvement cannot be answered
-- What is the ratio of productive activities to overhead activities?
-- What is the % of effort expended in rework activities?
-- What is the % of cost expended in software capital equipment?
-- What is the ratio of productive testing versus integration?
-- What is the cost of release N?

6.2 EVOLUTIONARY WBS

 Organizes the planning elements around the process framework rather than the product
framework.
 This approach accommodates the expected changes in the evolving plan.
 The basic recommendation for the WBS is to organize the hierarchy as follows –
First level WBS elements -- Workflows
Second level WBS elements -- Life-cycle phases
Third level WBS elements -- Artifacts
 Third level WBS elements may be the lowest level in the hierarchy or they may be further
decomposed into several lower level activities if required.

PROJECT

MANAGEMENT ENVIRONMENT --------- ASSESSMENT DEPLOYMENT

INCEPTION ELABORATION CONSTRUCTION ELABORATION

SDP BUSINESS CASE PLAN

 Above suggested WBS allows planning fidelity inherent in each element to commensurate with
current life-cycle phase and project state.

A Management (1st level)

Dr. G. Sunitha, CSE, SVEC 7
 AA Inception phase management (2nd level)
AAA Business Case Plan (3rd level)
AAB Elaboration Phase Release Specifications
AAC Elaboration Phase WBS development
AAD Software Development Plan

AB Elaboration phase management

ABA …………………
ABB …………………
AC Construction phase management
ACA …………………
ACB …………………
AD Construction phase management
.
.
.
G Deployment
GA Inception phase management
GAA …………………
GAB ………………..
.
.
.
GB Elaboration phase management
GBA . . . . . . . . . . .
GBB . . . . . . . . . . .
GC Construction phase management
GCA . . . . . . . . . . .
GCB . . . . . . . . . . .
GD Construction phase management

 Another important attribute of a good WBS is that the planning fidelity inherent in each
element is commensurate with the current life-cycle phase and project state.

 Evolutionary WBS suggested above is merely a starting point. It can be tailored to the specifics of
the project depending upon –
Scale – larger projects will have more WBS levels
Organizational Structure – multiple organizational entities leads to different WBS

Dr. G. Sunitha, CSE, SVEC 8

 Degree of custom development – A project based on existing components would have much
more depth in requirements whereas fully custom development would require fairly deep design
and implementation elements.
Business context – contractual projects need much more elaborated management and
assessment elements where as commercial products require elaboration on deployment element.
Precedent experience – Unprecedented projects require more depth in the WBS.

CONVENTIONAL WBS EVOLUTIONARY WBS

tied to a design that may (will) change, tied to the process, thus facilitates
may even hamper design change change management

project specific, and thus cross-project not project specific, thus facilitates
comparisons are difficult cross-project comparisons

generally either too detailed, too early the fidelity of the WBS increases
or insufficiently detailed throughout commensurate with the project

7 PLANNING GUIDELINES
 Software projects span a broad range of application domains.
 Planning provides a skeleton of the project from which the management people can decide the
starting point of the project.
 In order to plan properly it is necessary to capture the planning guidelines from most expertise
and experience people.
 Risky to make generic and project-independent planning. The guidelines may be adopted blindly
without being adapted to specific project. There is also risk of misinterpretation.
 Variability of project parameters, process, product size, complexity, budget, profit, business
context, application domain, organizational culture etc has to be considered.
 Blind adherence to project-independent planning may lead to unsuccessful project.
 Two simple planning guidelines should be considered when a project plan is initiated.
(1) Allocation of costs among the first-level WBS structures
(2) Allocation of effort & schedule across the life-cycle phases

 The above table provides cost allocation, not effort allocation. To avoid misinterpretation 2
explanations are necessary –
(1) The cost of different labor categories is inherent in these numbers.
(2) The cost of hardware and software assets that support the process automation and
development teams is also included in the environment element.

Dr. G. Sunitha, CSE, SVEC 9

  Given the project’s budget and time, developing a top-level project plan is straight forward.
 The guidelines given, average expectation and serves as the benchmark. But may vary depending
upon the project’s parameters.

8 COST AND SCHEDULE ESTIMATING PROCESS

 Project plans need to be derived from 2 perspectives
(1) Forward-looking, top-down approach
(2) Backward-looking, bottom-up approach

 Forward-looking, top-down approach

(a) The software project manager develops a characterization of the overall size, process,
environment, people and quality required for the project.
(b) A macro-level estimate of the total effort and schedule is developed.
(c) Partition the effort estimates into a top-level WBS using the guidelines. Partition the schedule
estimates into major milestone dates. This gives the project-level plan.
(d) 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.

 Backward-looking, bottom-up approach

(a) The software project manager develops a characterization of
(b) The overall size, process, environment, people and quality required for the project.
(c) The lower level WBS elements are elaborated into detailed tasks, for which budgets and
schedules are estimated by the responsible managers.
(d) Estimates are combined and integrated into higher level budgets and mile-stones.

Top-down estimating tends to exaggerate the project management biases and usually results in an overly
optimistic plan.
 Bottom-up estimating tends to exaggerate the performer biases and usually results in an overly
pessimistic plan.
 Hence, both kinds of estimation should be done. Comparisons are done and adjustments are made
in order to achieve convergence between the top-down and bottom-up estimates.
 Iterations may be necessary thereby evolving the plan and estimates.
 During the engineering stage, top-down approach dominates because there is usually not enough
understanding nor stability in the activities.
 During the production stage, bottom-up approach dominates. By then, the top-down approach
should be well tuned to the project specific parameters, so it should be used more as a global
assessment technique.

Dr. G. Sunitha, CSE, SVEC 10

9 THE ITERATION PLANNING PROCESS

 Defining the actual sequence of intermediate results.

 Planning the content and schedule of the major milestones and their intermediate iterations is the
most tangible form of the overall risk management plan.
 An evolutionary build plan is important because there are always adjustments in the content and
the schedule.
 Iteration is used to mean a complete synchronization across the project, with a well-defined
global assessment of the entire project.
 A generic build progression on the number of iterations in each phase is as follows --

Inception Iterations
 This phase consists of activities to define the foundation components and framework for
elaborating the critical use cases of the system.
 Establishes business case plan, vision and SDP.
 Most projects need only one iteration.
 Large-scale, unprecedented and custom developments may require 2 iterations.

Elaboration Iterations
 This phase results in architecture and a complete framework for execution.
 On the completion of this phase, few critical cases must be demonstrable
o Architecture
o Worst-case data processing flow through the system
o Worst-case control flow through the system
 Most projects must plan 2 iterations to achieve architecture baseline.
 Unprecedented architectures may require additional iterations whereas projects built on well-
established architecture framework can probably finish up in 1 iteration.

Construction Iterations
 Most projects require at least 2 major iterations an alpha release and an beta release
 An alpha release would include executable capability for all the critical use case. It usually
represents only 70% of the total product.
 A beta release typically provides 95% of the total product capability and quality.
 After beta release improvements may be necessary to improve product before final release of
the product.
 More number of iterations may be necessary.

Transition Iterations
 Most projects use a single iteration to transition a beta release into the final product.
 Numerous small-scale iterations may be necessary to resolve the defects and improve the
product.

Dr. G. Sunitha, CSE, SVEC 11

  Because of the overhead involved with a full-scale transition to the user community, most
projects learn to live with a single iteration between beta release and the final product release.

 General Guidelines – 4 to 9 iterations

Typical project would have 6-iteration profile

1 iteration in inception – an architecture prototype
2 iterations in elaboration – architecture prototype and architecture baseline
2 iterations in construction – alpha and beta releases
1 iteration in transition – product release

 Highly precedented projects or very small-scale projects

Could get away with a single iteration in a combined inception and elaboration phase and could
product a product efficiently with the overhead of only 4 iterations.
 A very large or unprecedented project may require additional inception iteration and 2
additional iterations in construction, for a total of 9 iterations. The resulting management overhead
may be worth the cost to ensure proper risk management and stakeholder synchronization.

10 PRAGMATIC PLANNING

 Good planning is more dynamic in iterative process.

 It defines how the project requirements will be transformed into a product within the business
constraints.
 Plan must be realistic, achievable and must be used.
 While executing iteration N of any phase, the project manager must be
-- Monitoring and controlling against a plan of iteration N-1
-- Planning for iteration N+1
 Good management plan makes trade-offs in the current and next iteration plans based on the
results of the previous and current iterations.
 This may seem complicated in early phases, but it becomes easy in the later phases of life cycle.
 Inadequate planning is one of the most common reasons for project failures.
 Planning provides a framework and forcing functions for making decisions, ensures buy-in on the
part of stakeholders and performers.
 A planning document is not very useful as an end item, but the act of planning is very important
for a project’s success.
 A project’s plan is a definition of how the requirements will be transformed into a product within
the business constraints.
 A plan must be
-- Realistic, current
-- A team product
-- Well understood by the stakeholders
-- Used
 Bad, closely held plans cause attrition. Good, open plans can shape the cultures and encourage
teamwork.

11 PROCESS ORGANIZATIONS AND RESPONSIBILITIES

 Software lines of business and project development teams have different motivations.
 Software lines of business are motivated by
o ROI, New business discriminators
o Market diversification, Profitability etc
 Project development teams are motivated by
o Cost, Schedule, Quality, Standards
o Reusability, Enhancement flexibility etc
 Organizations must
o Support projects with the necessary infrastructure to use a common process.
Dr. G. Sunitha, CSE, SVEC 12
 o Allocate artifacts and responsibilities clearly across project teams to ensure a balance of
global and local concerns.
o Evolve with the WBS and the life-cycle concerns.

12 LINE-OF-BUSINESS ORGANIZATIONS

Main features of the default organization are as follows –

 Responsibility for process definition and maintenance is specific to a cohesive line of business,
where process commonality makes sense.
 Responsibility for process automation is an organizational role and is equal in importance to the
process definition roles. Projects achieve process commonality primarily through the environment
support of common tools.
 Organizational roles may be fulfilled by a single individual or several different teams depending on
the scale of organization.

12.1 SOFTWARE ENGINEERING PROCESS AUTHORITY –SEPA

 May be single individual or a team or may be a general manager.

 Is a necessary role in any organization. It must be truly competent and powerful.
 Accountable to the organizational general manager.
 SEPA
– Guides the process.
– Responsible for process definition and maintenance.
– Initiates and assesses periodically project processes.
– Captures, disseminates software best practices.
– Understands the project’s context and desired improvement.
– Exchanges information between management, clients, users and development team.
– Maintains current assessment of organizations process maturity.
– Plan for future process improvements.

12.2 PROJECT REVIEW AUTHORITY – PRA

 Is a single individual.
 Reviews customer commitments as well as adherence to
-- organizational policies, deliverables,
-- financial performance and
-- other risks and accomplishments.
Dr. G. Sunitha, CSE, SVEC 13
  Responsible for ensuring that a software project complies with all organizational and business unit
software policies, practices and standards.
 Software Project Manager is responsible to
• Meet the requirements of the contract
• Meet Standards and Practices of the industry
And accountable to the PRA

12.3 SOFTWARE ENGINEERING ENVIRONMENT AUTHORITY (SEEA)

 Is companion group for SEPA.
 responsible for
– Automating the organization’s process,
– Maintaining standard environment,
– Training projects to use the environment
– Maintaining organization-wide reusable assets.
 SEEA role is necessary to achieve ROI for a common process.
 Maintaining a standard environment allows tools, techniques and training to be used effectively
across multiple projects.
 In many cases, the environment may be augmented, customized or modified, but the existence of
an 80% default solution for each project is critical to achieve
– Institutionalization of the organization’s process and
– A good ROI on capital tool investments.

12.4 INFRASTRUCTURE
 An organization’s infrastructure provides
 Human Resources Support
 Project-independent research and development
 Other capital software engineering assets.
 Infrastructure in any organization may range from trivial to highly sophisticated.
 Typical components of the organizational infrastructure are –
Project Administration
 Time accounting system
 Contracts, pricing and Terms and conditions
 Corporate information systems integration
Engineering skill centers
 Custom tools repository and maintenance
 Bid and proposal support, Independent research & development
Professional Development
 Internal training boot camp, Personnel recruiting,
 Personnel skills database maintenance, Literature and assets library, technical publications
 An organizational service center promotes a standard environment. It is funded by the line of
business.
 Software development environments must be treated as any other hardware development
environments. Process improvement and tooling must not be treated as direct project expenses.
They should be treated as capital investments.

Dr. G. Sunitha, CSE, SVEC 14

13 PROJECT ORGANIZATIONS

The main features of the default organization are –

 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 functions.
 The development team owns the component construction and maintenance activities.
 The assessment team is separate from development. This structure fosters an independent quality
perspective and focuses a team on testing and product evaluation activities concurrent with on-
going development.
 Quality is everyone’s job, integrated into all activities and checkpoints. Each team takes
responsibility for a different quality perspective.

13.1 SOFTWARE MANAGEMENT TEAM

 Most projects are over constrained.
 Different stakeholders have differing goals.
 Schedules, costs, functionality and quality expectations are highly interrelated and require
continuous negotiation.
 The Software Management Team
– Carries the burden of delivering win conditions to all stakeholders.

Dr. G. Sunitha, CSE, SVEC 15

 – Is responsible for planning the effort, conducting the plan and adapting the plan to the
changes in the understanding of the requirements and design.
– Hence, this team is responsible for attaining and maintaining a balance among these
aspects. To achieve this, the team takes ownership of
– Resource management and project scope
– Operational priorities across the project life cycle
– All aspects of quality

13.2 SOFTWARE ARCHITECTURE TEAM

 Is responsible for the architecture.
 Responsible for achieving highly predictable construction/assembly costs. Hence, it is responsible
for the engineering necessary
– to specify a complete bill of materials for the software.
– To make significant make/buy trade-offs.
 It provides framework for facilitating team communications, for achieving system-wide qualities
and for implementing the applications.
 Inception phase is dominated by software management team and Elaboration phase is dominated
by software architecture team.
 By the time the construction phase is initiated, the architecture transitions into a maintenance
mode.
 Is responsible for system level quality, reliability, performance and maintainability.

Dr. G. Sunitha, CSE, SVEC 16

  These attributes span multiple components and represent how well the components integrate to
provide an effective solution. In this regard, the architecture team decides how most multiple-
component design issues are resolved.
 To succeed, the architecture team must include a fairly broad level of expertise, including –
– Domain experience
– Software technology experience

13.3 SOFTWARE DEVELOPMENT TEAM

 Is the most application-specific group.

 Is responsible for quality of individual components including all component development, testing
and maintenance.
 It decides how any issue regarding a single component is resolved.
 Component tests should be built as self-documented, repeatable software that is available for
automated regression testing.
 Software development team comprises several sub-teams dedicated to groups of components that
require a common skill set.
 Typical skill sets include the following --
Commercial Component: specialists with detailed knowledge of commercial components central
to a system’s architecture.
Database: specialists in organization, storage and retrieval of data.
GUI: specialists in display organization, data representation and user interaction.
Operating Systems and Networking: Specialists in the execution of multiple software objects
on a network of hardware resources, synchronization, resource sharing, name space management,
reconfiguration etc.
Domain Applications: Specialists with algorithms, application processing, Business rules etc.

13.4 SOFTWARE ASSESSMENT TEAM

 Having an independent team for software assessment –
PROS
 For ensuring better and independent quality perspective.
 To ensure that developer team biases does not pollute assessment of quality.
 To exploit concurrency of activities.
CONS
 Relieving software development team from quality perspective may let developer to think
that he need not bother about quality.

Dr. G. Sunitha, CSE, SVEC 17

  Schedules can be accelerated by developing the software and preparing for testing in parallel.
 Change management, test planning, test scenario development can be performed in parallel with
design and development.
 Each release may encompass several components.
 A modern process should employ use-case oriented or capability based testing mechanized by 2
artifacts –
– Release Specification (Plan and evaluation criteria for a release)
– Release Description (Results of a release)
 At the end of each iteration release description and specification must be reviewed.
 Each release may encompass several components. Evaluation criteria must be satisfied by each
release. Many components may undergo only informal testing by development team. Formal
testing will then be subsumed in higher level evaluation criteria and release descriptions.
 The final iteration will generally be equivalent to acceptance testing.
 The assessment team is responsible for the quality of baseline releases with respect to the
requirements and customer expectations.
 The test plans, procedures and reports evolve over iterations into artifacts with detailed
completeness and traceability.

14 EVOLUTION OF ORGANIZATIONS
 Project organization represents the architecture of the team and needs to evolve consistent with
the project plan captured in the WBS.
 A different set of activities is emphasized in each phase –
Inception Team
-- Focus on planning with support from other teams to ensure that plans.
-- Software Management Team is mainly involved.
Elaboration Team
-- Focus on architecture and model development supported by development and
assessment teams.
-- Software Architecture Team is mainly involved.
Construction Team
– Focus on development and assessment.
–Software Development and Assessment Teams are mainly involved.
Transition Team
– Focus on customer, usage feedback, deployment
– Software Assessment Team is mainly involved
 It is important to elaborate details sub-teams, responsibilities and work but only after is stable.
Dr. G. Sunitha, CSE, SVEC 18
 FIG – SOFTWARE PROJECT TEAM EVOLUTION OVER LIFE CYCLE

15 NEED FOR PROCESS AUTOMATION

 The environment must be a first class artifact of the process.

 Process Automation and change management are critical to an iterative process.
 Round-trip engineering and integrated environments promote change freedom and effective
evolution of technical artifacts.
 Metrics automation is crucial to effective project control.
 Automating development process includes – tool selection, custom toolsmithing etc.
 Evolving development environment into maintenance environment is also crucial.
 External stakeholders need access to environment resources to improve interaction with the
development team and add value to the process.
 Automation improves predictability of software management.
 Automation improves performance of software lines of business in terms of quality, achieving
deadlines, ROI, productivity etc.
 A significant level of process automation is required in order for modern software development
projects to operate profitably and to perform against development plan with acceptable efficiency.
 Automation needs grow depending on the scale of the effort. The techniques, training, time scales,
acceptance criteria and levels of automation differ significantly at opposite ends of the spectrum.
 There are 3 levels of process. Each level requires a different degree of automation --
Meta Process –
 An organization’s policies, procedures and practices for managing a software-intensive line
of business.
 The automation support for this level is called an infrastructure.
 An infrastructure is an inventory of --
-- tools, artifact templates,
-- micro-process and macro-process guidelines,
-- project performance repository,
-- database of organizational skill sets and
-- library of precedent examples of past project plans and results
Macro Process –
 A project’s policies, procedures and practices for producing a complete software product
within certain cost, schedule and quality constraints.
 The automation support for a project’s process is called an environment.
Dr. G. Sunitha, CSE, SVEC 19
  An environment is a specific collection of tools to produce a specific set of artifacts as
governed by a specific project plan.
Micro Process –
 A project team’s policies, procedures and practices for achieving an artifact of the software
process.
 The automation support for generating an artifact is called a tool.
 Typical tools include --
-- Requirements Management, Visual Modeling
-- Cost Estimation, Workflow Automation
-- Compilers, Debuggers, Editors
-- Change Management, Metrics Automation
-- Document Automation, Test Automation etc

16 TOOLS: AUTOMATION BUILDING BLOCKS

 Many tools are available to automate the software development process.

 Computer-aided software engineering (CASE) is software to support software development and
evolution processes.

 Activity automation
 Graphical editors for system model development;
 Data dictionary to manage design entities;
 Graphical UI builder for user interface construction;
 Debuggers to support program fault finding;
 Automated translators to generate new versions of a program.
 Classification helps us understand the different types of CASE tools and their support for process
activities.
 Functional perspective -- Tools are classified according to their specific function.
 Process perspective -- Tools are classified according to process activities that are
supported.

Dr. G. Sunitha, CSE, SVEC 20

  Integration perspective -- Tools are classified according to their organisation into integrated
units.

 Most of the core software development tools map closely to one of the process workflows.
 Each of the process workflows has a distinct need for automation support. In some cases tool is
needed to generate an artifact, whereas in others just for bookkeeping.

16.1 MANAGEMENT
 Tools needed for automating project planning and control activities of the management
workflows.
 Software cost estimation tools and WBS tools for generating the planning artifacts.
 Workflow management tools and software project control panels for managing against
a project plan.
 Tools for maintaining an on-line version of the status assessment of the project.
 Metrics Automation and Reporting tools.

16.2 ENVIRONMENT
 Configuration Management tools
 Version Control and Management tools
 Change Management Tools
 Automated Documentation Tools etc
16.3 DESIGN
 The tools that support requirements, design, implementation and assessment are usually used
together.
 Visual Modeling Tools used for capturing design models, presenting them in human-readable
format and translating them into source code.

16.4 IMPLEMENTATION – tools for supporting programming environment

 Editors, Compilers, Debuggers
 Linkers, Run time Support
 Also visual modeling tools, testing tools, change management tools etc

16.5 ASSESSMENT AND DEPLOYMENT

 All the other tools required for other workflows like Visual Modeling Tools, Testing Tools,
Change Management Tools, Editors, Compilers, and Debuggers etc.
 Test Automation and Test Management Tools.
 Defect Tracking Tools – to automate metrics and control release baselines.

Dr. G. Sunitha, CSE, SVEC 21

 16.6 REQUIREMENTS
 Conventional approach gives equal treatment for all requirements.
 This drains away effort from the driving requirements, and hence wastes all the paperwork,
time associated with less important requirements.
 In a modern process, the system requirements are captured in the vision statement.
 Lower levels of requirements are captured in the form of evaluation criteria by a set of use
cases and other textual documents.
 The vision statement captures the contract between the development group and the buyer.
 This information should be evolving but slowly varying, across the life cycle. It should be
represented in the format understandable by the buyer.
 Requirements must be evolved along with architecture and an evolving set of application
increments. In this way, the customer and the developer have a common understanding of the
priorities and the cost/schedule/performance trade-offs associated with those requirements.
 The ramification of this approach on the environment’s support for requirements management
are twofold –
 The recommended requirements approach is dependent on both textual and model-
based representations. Hence, the environment should provide integrated document
automation and visual modeling. It is necessary to manage and track changes to either
format and present them in human-readable format.
 Traceability between requirements and other artifacts needs to be automated.

17 THE PROJECT ENVIRONMENT

The project environment artifacts evolve though 3 discrete states

The Prototyping Environment

 Includes architecture testbed for prototyping project architectures to evaluate trade-offs during
inception and elaboration phases.
 Tools should support
 Analyzing Requirements, Technical Risk Analyses,
 Performance Trade-offs, Make/Buy Trade-offs,
 Feasibility studies, Fault Tolerance Studies
 Dynamic Reconfiguration Trade-offs
 Development of test scenarios and tools
 Analysis of the risks associated with transitioning to full scale implementation

The Development Environment

 Includes a full suite of development tools needed to support the various process workflows and to
support round-trip engineering.

The Maintenance Environment

 Should typically coincide with a mature version of the development environment. In some cases,
the maintenance environment may be a subset of the development environment.

There are 4 important environment disciplines that are critical to the management context and the
success of a modern iterative development process –
Round-trip engineering – Tools must be integrated to maintain consistency and traceability.
Change Management – Must be automated and enforced to manage multiple iterations and to
enable change freedom.
Organizational Infrastructures – enable project environments to be derived from a common
base of processes and tools.
Stakeholder Environments – Enables further support for paperless exchange of information and
more effective review of engineering artifacts.

Dr. G. Sunitha, CSE, SVEC 22

18 ROUND-TRIP ENGINEERING

 Round-trip engineering is the environment support necessary to maintain consistency among the
engineering artifacts.
 As different information sets have to be maintained for the engineering artifacts, more automation
support is needed to ensure efficient and error-free transition of data from one artifact to another.
 Allows change freedom.
 Automated translation of design models to source code and vice-a-versa.
 Automated translation of design models to process models.
 Automated translation of source code into executable code using compilers and linkers.
 Automated configuration control and build management.
 Automated test case construction.
 Today’s environments do not support automation to the greatest extent possible.
 Not necessary to have bi-directional translations in all cases.
 Translation from one data source to another may not provide 100% completeness.
 Use of heterogeneous architectures, designs, components, platforms etc increases complexity of
building, integrating and maintaining. This further increases need for automation.

19 INFRASTRUCTURES

 Organization’s infrastructure provides the organization’s capital assets including 2 artifacts –

 A policy that captures the standards for project software processes
 An environment that captures an inventory of tools.

19.1 ORGANIZATION POLICY

 Organization policy is the defining document for the organization’s software policies. It is a
tangible artifact that says what you do.
 Handbook that defines the life cycle and the process primitives like major milestones, intermediate
artifacts, metrics, roles and responsibilities etc.
 The handbook provides a general framework for answering --
 What gets done? (activities and artifacts)
 When does it get done? (life-cycle phases and milestones)
 Who does it? (team roles and responsibilities)

Dr. G. Sunitha, CSE, SVEC 23

  How do we know that it is adequate? (checkpoints, metrics, standards of performance)
 From this document, reviewers should be able to question and review projects and personnel and
determine whether the organization does what it says.
 Organization policy should not enforce too much institutionalization not too much standardization.
There should be balance in definition.
 Effective organizational policies
 Are concise and avoid heavy documents.
 Confine the policies to real shalls and then enforce them.
 Avoid using should. Rather than a menu of options (shoulds), policies need a concise set of
mandatory standards (shalls).
 Waivers are the exception, not the rule.
 Appropriate policy is written at the appropriate level.

 There are many different organizational structures throughout the software industry.
 Most software-intensive companies have 3 distinct levels of organization, with a different
policy focus at each level:
Highest organization level – Standards that promote
(1) Strategic and long-term process improvements
(2) General technology insertion and education
(3) Comparability of project and business unit performance
(4) Mandatory quality control

Intermediate line-of-business level – Standards that promote

(1) Tactical and Short-term process improvement
(2) Domain-specific technology insertion and training
(3) Reuse of components, processes, training, tools and personnel experience
(4) Compliance with organizational standards
Lowest Project level – Standards that promote
(1) Efficiency in achieving quality, schedule and cost targets
(2) Project specific training
(3) Compliance with customer requirements
(4) Compliance with organizational business unit standards

Dr. G. Sunitha, CSE, SVEC 24

  Standardization should generally focus on line-of-business units, not on the top level
organization or the projects.
 Leverage from standardization is generally most effective at the business unit level, where there is
the most commonality and reuse across projects, processes and tools.
 Standardization of software development techniques and tools across lines of business has proven
to be difficult, because the process priorities, tools, techniques, methods and stakeholder cultures
can be very different.
 Standardizing at too high level or too low level is problematic.

19.2 ORGANIZATION ENVIRONMENT

 The organization environment for automating the default process will provide many of the answers
to how things get done as well as the tools and techniques to automate the process as much as
practical.
 Some of the typical components of an organization’s automation building blocks are as follows –
 Standardized tool selections which promote common workflows and a higher ROI.
 Standard notations for artifacts, such as UML for all design models or Ada 95 for all custom-
development etc
 Tool adjuncts such as existing artifact templates or customizations (architecture
description, evaluation criteria, status assessments etc)
 Activity templates (iteration planning, major milestone activities etc)

 Other indirectly useful components of an organization’s infrastructure are as follows –

 A reference library of precedent experience for planning, assessing and improving process
performance parameters.
 Existing case studies, including objective benchmarks of performance for successful
projects that followed the organizational process.
 A library of project artifact examples such as software development plans, architecture
descriptions and status assessment histories.
 Mock audits and compliance traceability for external process assessment frameworks such
as the Software Engineering Institute’s Capability Maturity Model (SEI CMM).

20 STAKEHOLDER ENVIRONMENTS

 Automation should not be restricted to the development team. Many large-scale contractual
projects include people in external organizations in the development process.
 Ex: Clients, Users, Contractors, Marketing Personnel, Third Party Maintenance Contractors etc
 These external stakeholders also need to access the development environment resources so that
they can contribute value to the overall effort.
 If the stakeholders do not have the resources for reviewing resources on-line, then paper is the
only way for exchanging information.
 Exchange of information through papers has many disadvantages.
 There are several reasons for extending development environment resources into external
stakeholder domains –
 Technical artifacts are not just paper. Electronic artifacts in rigorous notations such as
visual models and source code are viewed best by using tools and smart browsers.
 Independent assessments of the evolving artifacts are encouraged by e-access to on-line
data. Reviews, inspections, metric analyses etc can be performed independent of the
development team.

Dr. G. Sunitha, CSE, SVEC 25

  Even paper documents should be delivered electronically to reduce production costs and
turnaround time.

 An on-line review by external stakeholders allows them to participate in the process as follows
(advantages of on-line review)–
 Accept and use executable increments for hands-on evaluation.
 Use the same on-line tools, data, and reports that the software development organization
uses to manage and monitor the project.
 Avoid excessive travel, paper interchange delays, format translations, paper and shipping
costs, and other overhead costs.
 Once environment is accessible by stakeholders through on-line, continuous and expedient
feedback is much more efficient, tangible and useful.
 To create such an environment –
 Development teams must create an open environment and provide adequate resources to
stakeholders.
 Stakeholders should avoid abusing this access, learn using on-line environment, has to
participate by adding-value and avoid interrupting development.
 Internet and Intranet technologies are making paperless environments economical.
 Extending development environment into external stakeholder domains raises many issues such as
 How much access freedom must be supported?
 Who funds the environment and tool investments?
 How secure is the information exchange?
 How is change management synchronized? etc

21 CHANGE MANAGEMENT
 Change Management is as critical to iterative processes as planning.
 Tracking changes in the technical artifacts is crucial in understanding
 True technical progress
 Quality trends
 In conventional process, change management for technical artifacts is a late life cycle activity.
Whereas in modern process, change management is fundamental to all phases and all activities.
 Software Change Orders
Dr. G. Sunitha, CSE, SVEC 26
  Configuration Baseline
 Configuration Control Board

21.1 SOFTWARE CHANGE ORDER

 SCO is the atomic unit of software work that is authorized to create, modify or obsolesce
components within a configuration baseline.
 SCO are key mechanism for partitioning, allocating, and scheduling software work against an
established software baseline and for assessing progress and quality.
 By maintaining change records on-line, the change management metrics reporting activities can
also be automated.
 Level at which an SCO should be written raises issues such as –
 What is a discrete change?
 Is it a change to a program unit/component/file/subsystem?
 Is it a new feature/defect resolution/performance enhancement?
 In general, SCO should be written for each component individually. If conflict needs two people on
two different teams, two SCO’s must be written.
 The basic fields of SCO are –

Title – The title is suggested by the originator and is finalized upon acceptance by the CCB. This
field should include a reference to an external software problem report if the change was initiated
by an external person.

Description – This includes the -- Name of the originator

-- Date of origination
-- CCB-assigned SCO identifier
-- Relevant version identifiers
The textual description should include as much detail as possible along with attached code
excerpts, display snapshots, error messages and any other data needed.

Metrics – The metrics collected for each SCO are important for planning, scheduling and assessing
quality. Change categories are –
Type 0 (critical bug)
Type 1 (bug)
Type 2 (enhancement)
Type 3 (new feature)
Type 4 (other)
Upon acceptance of SCO initial estimates are made --
Breakage – quantifies the volume of change
Rework – quantifies the complexity of change
Analysis – Identifies the number of staff hours expended in understanding the required
change.
Implement -- Identifies the number of staff hours expended in designing and
implementing the change.
Test – Identifies the number of staff hours expended in testing the resolution.
Document – Identifies the number of staff hours expended in updating the user manuals
and other documentations.
The name of the person responsible for implementing the change, components changed, actual
metrics and a description of the change.

Assessment-- This field describes the assessment technique as inspection, analysis,

demonstration or test. It should reference –
-- all existing test cases and new test cases executed,
-- all test configurations such as platforms, topologies etc

Dr. G. Sunitha, CSE, SVEC 27

 R
e
s
o
l
u
t
i
o
n

-
-

T
h
i
s

f
i
e
l
d

i
n
c
l
u
d
e
s

Disposition -- The SCO is assigned one of the following states by the CCB:
Proposed – written, pending CCB review
Accepted – CCB-approved for resolution
Rejected – closed because it is not a problem, duplicate, obsolete change etc.
Archived – accepted but postponed until a later release
In Progress – change is being implemented
In assessment – change is implemented and is being tested.
Closed – Change is completed

A priority and release identifier can also be assigned by the CCB.

21.2 CONFIGURATION BASELINE

 A Configuration Baseline is a named collection of software components and supporting
documentation that is subject to change management and is upgraded, tested and maintained as a
unit.
 There are 2 classes of baselines –
 External Product Releases
 Internal Testing Releases

Dr. G. Sunitha, CSE, SVEC 28

  It is controlled formally because it is a packaged of exchange between groups.
Ex: Configuration baseline may be releases to the organization itself for testing.
It may be released to the user community for beta testing.
 3 levels of baseline releases are required for most systems – major, minor, interim.

 Each level corresponds to a numbered identifier such as N.M.X.

 N is the major release number – represents a new generation of the product
M is the minor release number – same basic product but with enhanced features
X is the interim release identifier.
 Major and minor releases are intended to be external product releases.
 Once software is placed in a controlled baseline, all changes and their causes are tracked.

 Change categories are as follows –

Type 0 – critical failures – defects that are almost always fixed before any external release

Dr. G. Sunitha, CSE, SVEC 29

 Type 1 – a bug or defect that does not impair the usefulness of the system. These are
problems in critical use cases, serious defects in secondary use case that have a low
probability of occurrence
Type 2 – a change that is an enhancement rather than a response to a defect
Type 3 – a change that is necessitated by an update to the requirements
Type 4 – changes that are not accommodated by the other categories
 The following table shows examples of these changes in the context of 2 different project
domains

21.3 CONFIGURATION CONTROL BOARD

 A CCB is a team of people that functions as the decision authority on the content of configuration
baselines.
 It includes software project manager, software architecture manager, software development
manager, software assessment manager and other stakeholders.
 It takes action through meetings, on-line distribution, concurrence etc.
 The iterative development process must include change management for the evolving baselines.
The fundamental process for controlling software development and maintenance activities is
described using a sequence of states traversed by an SCO –
 Proposed – written, pending CCB review
 Accepted – CCB approved for resolution
 Rejected – closed because it is not a problem, duplicate, obsolete change etc.
 Archived – accepted but postponed until a later release
 In Progress – change is being implemented
 In assessment – change is implemented and is being tested.
 Closed – Change is completed

22 (a) What are the steps in identifying project roles? Name any 5 project
roles and the skills needed for them.
(b) What are the benefits of matching people to roles?

Within the project environment, a clear definition of the roles and responsibilities will be critical to the
success of the project. Individuals must understand the roles they play to know what responsibilities they
have in making decisions, taking actions, reporting, and reviewing.
Matching people to roles benefits the project by:
 Bringing order to the chaos of a normal project
 Allowing the team to reach ―perform‖ stage of development faster
 Keeping people from performing redundant activities
 Creating a ―job description‖
 Predetermining decision-making responsibility
 Identifying responsible persons for success of the assignments
 Reducing confusion about who does what and when
 Provide each individual with a clear understanding of the authority given and responsibility
necessary for the successful accomplishment of the activities.
To facilitate smooth team interactions and clear lines of authority and responsibility, every
person on the team should identify which role he or she is filling when giving direction, making
decisions, calling meetings, or reviewing artifacts.

Steps in identifying project roles

A project role is an assignment on the project team. It’s similar to a job description. A team member can
have one or more roles at the same time. A person’s role may be temporary or last for the life of the
project.
While identifying roles, consider number and types of tasks, and the skills required for them.
1. List the major software engineering tasks needed to complete the project.
2. Group the tasks that fit under each role.

Dr. G. Sunitha, CSE, SVEC 30

 3. Assess the magnitude of work, tools involved and the importance of each role.
4. Identify the software engineering and personality skills needed in each role.
5. Review the roles to make sure they fit together and are manageable.

Steps in matching people to roles

1. Review skills of each team member
2. Assign supporting roles

Role is the part played by somebody in a given project defined by the s/w engineering tasks and
influenced by the social part the person plays.
Responsibilities are actions, tasks or products that a person is held accountable for.

23 WHAT ARE THE SOURCES OF CHANGE? WHY SHOULD CHANGE BE MADE IN A CONTROLLED
WAY?
Change management is 'the coordination of a structured period of transition from situation A to situation
B in order to achieve lasting change within an organization.
When issues are found while project work is going on, change requests are issued which may modify
policies, procedures, scope, cost, schedule, requirements, design, code etc. The most effective project
plan will be wasted if some method of controlling change is not implemented.

Change control is not easy. The change control process establishes the stability to manage changes that
affect the project throughout its life cycle. If left unchecked, changes to the project plan cause
significant imbalance regarding scope, schedule and budget. As changes occur, their overall impact on the
project must be gauged and should react accordingly.

Sources of change are associated with one or more sides of the

triangle: scope, schedule or budget.

Scope
 Other projects are added due to consolidation
 The client changes the requirements
 Market conditions shift
 Problems encountered by engineering
Schedule
 Delivery date accelerated
 Competition pressures
 Client requests early delivery
Budget
 Management pulls 20% of the project budget
 Tools and off-the shelf component costs escalate
 Project work requires addition of manpower.

Advantages of effective change management --

 Employees have a solid understanding of why change is happening. Employees engage in both the
solution and the change.
 Training is used to build knowledge after employees have made the personal decision to support
the change.
 Resistance is identified and dealt with early in the process.
 Momentum is built throughout different areas and levels within the organization.
 Changes are less painful to the organization and to the employees.
 Probability of meeting project objectives is increased.
 The organization begins to build a history of successful change, creating a better 'backdrop' for the
next change initiative.

Dr. G. Sunitha, CSE, SVEC 31