UNIT 3

TECHNIQUES OF PLANNING, CONTROLLING AND AUTOMATING

SOFTWARE PROCESS

ER. SUSHIL TIMILSINA

Iterative Process Planning
 Like in software development project planning requires an iterative process.
 Plans have an engineering stage during which plan is developed and the production stage
, when the plan is executed.
 Plan must evolve as the understanding evolves of the problem space and the solution
space.
 Planning errors are just like product errors, the sooner in lifecycle they are resoled the less
impact they have on project success.
 Projects can underplan and they can overplan but balance is required.
 The work breakdown structure (WBS) is a architecture of the project plan.
 A Cost and schedule budgets should be estimated using macroanalysis techniques (top-
down project level) and microanalysis techniques (bottom-up task level) to achieve
predictable results.
Iterative Process Planning…
WORK BREAKDOWN STRUCTURE (WBS)
 A good work breakdown structure and its synchronization with the process framework are critical
factors in software project success.
 Development of a work breakdown structure dependent on the project management style,
organizational culture, customer preference, financial constraints, and several other hard to
define, project-specific parameters.
 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
 Successful modern projects and even successful projects developed under the conventional
process tend to have a very well-defined project milestone to transit from research attitude to
production attitude.
Iterative Process Planning…
 Conventional WBS Issues
✓ Conventional work breakdown structures frequently suffer from three fundamental flaws.
• Premature Product-Based Structure: They are often organized around the product's subsystems and components too
early, tying the financial plan to the product design prematurely.
• Inappropriate Level of Detail: Large projects are over-planned with excessive detail, while small projects are under-
planned. This mismatch fails to align the level of detail with the plan's evolving accuracy.
• Lack of Standardization: Project-specific WBS designs hinder cross-project comparisons, making it difficult to analyze plans,
costs, schedules, organizational efficiency, or trends in productivity and quality.
 Evolutionary Work Breakdown Structures
✓ An evolutionary WBS organizes planning around the process framework rather than the product, addressing the flaws
of conventional WBS. Key features include:
1. Structure:
• First-level elements: Workflows (management, environment, requirements, design, implementation, assessment,
deployment).
• Second-level elements: Phases of the project life cycle (inception, elaboration, construction, transition).
• Third-level elements: Activities producing artifacts in each phase.
• This structure (illustrated in Figure 10-2) integrates process elements, enabling cost and schedule estimation, resource
allocation, and expenditure tracking.
Iterative Process Planning…
Evolutionary Work Breakdown Structures…
2. Tailoring Factors:
• Scale: Larger projects require more levels and substructures.
• Organizational Structure: Subcontractors or multiple entities may dictate specific WBS allocations.
• Custom Development: Varying emphasis on requirements, design, or implementation based on project type.
• Business Context: Commercial projects may need elaborate deployment substructures.
• Precedent Experience: Projects often inherit WBS from legacy systems or organizational standards.
3. Planning Fidelity:
• The WBS aligns planning detail with the project’s life-cycle phase and current state (Figure 10-3).
• It supports a range of planning, from rough estimates to detailed activity networks with defined budgets and
continuous tracking.
4. Benefits:
• Provides insight into project attributes, priorities, and structure.
• Ensures planning evolves with the project, avoiding premature or mismatched detail.
• Facilitates adaptability to project-specific needs and constraints.
Iterative Process Planning…
Iterative Process Planning…
Iterative Process Planning…
Iterative Process Planning…
PLANNING GUIDELINES
 Software projects span a broad 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 pe
adopted blindly without being adapted to specific project circumstances.
 Two simple planning guidelines should be considered when a project plan is being initiated or
assessed:
1. Default allocation of costs among the first-level WBS elements (Table 10.1)
2. Distribution of effort and schedule across the lifecycle (Table 10.2)
 Application:
• These guidelines, used with an initial total cost estimate, facilitate the creation of a staffing profile,
resource allocation, top-level schedule, and initial WBS with task budgets and schedules.
• They serve as a foundation for further plan refinement, but adaptation to project-specific circumstances
is critical to avoid misapplication.
Iterative Process Planning…
PLANNING GUIDELINES…
Iterative Process Planning…
THE COST AND SCHEDULE ESTIMATING PROCESS
 Project plans are developed using two complementary approaches:
1. Top-Down Approach (Forward-Looking):
✓ Starts with general requirements and constraints to create a macro-level budget and schedule, then
decomposes into lower-level budgets and milestones.
✓ Steps:
• The project manager (and team) characterizes the project’s size, process, environment, personnel, and quality
needs.
• A macro-level estimate of total effort and schedule is developed using a software cost estimation model.
• Effort is partitioned into a top-level WBS using guidelines (e.g., Table 10-1).
• Subproject managers decompose WBS elements into lower levels, constrained by top-level allocation, staffing
profiles, and major milestones.
✓ Tendency: Exaggerates management biases, leading to overly optimistic plans.
Iterative Process Planning…
THE COST AND SCHEDULE ESTIMATING PROCESS…
2. Bottom-Up Approach (Backward-Looking):
✓ Begins with detailed tasks at the lowest WBS levels, then aggregates into higher-level budgets and milestones.
✓ Steps:
• Lowest-level WBS elements are elaborated into detailed tasks.
• Estimates are combined into higher-level budgets and milestones.
• Results are compared with top-down budgets and schedules.

✓ Tendency: Exaggerates performer biases, resulting in overly pessimistic plans.

 Balancing the Approaches:

✓ Both approaches should be used together throughout the project life cycle.
✓ Engineering Stage: Top-down dominates due to limited understanding and unstable task sequences,
making bottom-up planning less reliable.
✓ Production Stage: Bottom-up dominates as precedent experience and planning fidelity increase.
✓ Tuning: The top-down approach should be adjusted to project-specific parameters and used as a
global assessment tool.
✓ Illustration: Figure 10-4 shows the balance between top-down and bottom-up planning across the
project life cycle.
Iterative Process Planning…
Iterative Process Planning…
THE ITERATION PLANNING PROCESS
 Iteration planning defines the sequence of intermediate results in an evolutionary build plan,
allowing adjustments as project understanding evolves.
 An iteration involves project-wide synchronization and a comprehensive assessment of the
project baseline.
 Iteration Types and Purposes:
1. Inception Iterations:
✓ Focus: Early prototyping to integrate foundation components, creating an executable framework.
✓ Outcomes: Demonstrate candidate architecture, critical use cases, and establish a credible business case, vision,
and software development plan.
✓ Typically one iteration (e.g., architecture prototype).
2. Elaboration Iterations:
✓ Focus: Develop a complete architecture with framework and infrastructure.
✓ Outcomes: Demonstrate critical use cases, including:
✓ Initializing the architecture.
✓ Handling worst-case data processing (e.g., peak transaction throughput or load).
✓ Managing worst-case control flow (e.g., fault-tolerance scenarios).

✓ Typically two iterations (architecture prototype and architecture baseline).

Iterative Process Planning…
THE ITERATION PLANNING PROCESS…
3. Construction Iterations:
✓ Focus: Build the product through major releases.
✓ Outcomes: Typically include an alpha release and a beta release.
✓ Usually two iterations.
4. Transition Iterations:
✓ Focus: Finalize the product from beta to release.
✓ Outcome: Product release.
✓ Typically one iteration.
 General Guidelines:
• Most projects require 4 to 9 iterations: (Based on book, this is not exactly the case in today’s development)
• Typical profile (6 iterations): 1 inception (architecture prototype), 2 elaboration (architecture prototype
and baseline), 2 construction (alpha and beta releases), 1 transition (product release).
• Large/unprecedented projects: May need an additional inception iteration and two extra construction
iterations, totaling up to 9 iterations.
 The evolutionary build plan accommodates changes in build content and schedule as project
understanding improves, with iterations ensuring synchronized progress and assessment across
phases.
Iterative Process Planning…
PRAGMATIC PLANNING
 In an iterative process, planning is dynamic and more accurate, but it requires active
management.
 During iteration N, the project manager:
✓ Monitors and controls against the plan from iteration N-1.
✓ Plans for iteration N+1.
 Good planning involves making trade-offs based on objective results from current and past
iterations.
 Importance of Planning:
• Failures: Inadequate planning, alongside poor architectures and misunderstood requirements, is a
leading cause of project failure.
• Success: Good planning is a key contributor to successful projects.
 Characteristics of a Good Plan:
• Realistic: Reflects achievable goals within constraints.
• Current: Regularly updated to reflect project progress and changes.
• Team-Oriented: Developed collaboratively to foster ownership among team members.
• Understood by Stakeholders: Clear and accessible to all involved parties.
• Actively Used: Guides decision-making and execution.
Project Organization and Responsibilities
 Two type of organizations:
1) Line-Of-Business Organizations
2) Project organizations
 Organizations engaged in software Line-of-Business need to support projects with the
infrastructure necessary to use a common process.
 Project organizations need to allocate artifacts & responsibilities across project team to
ensure a balance of global (architecture) & local (component) concerns.
 The organization must evolve with the WBS & Life cycle concerns.
 Software lines of business & product teams have different motivation.
 Software lines of business are motivated by return of investment (ROI), new business
discriminators, market diversification & profitability.
 Project teams are motivated by the cost, Schedule & quality of specific deliverables
Project Organization and Responsibilities…
Line of Business Organizations:
 The organizational structure is tailored to specific circumstances but designed for a
cohesive line of business with common processes (e.g., embedded vs. office applications).
 Responsibility for process definition & maintenance is specific to a cohesive line of business.
 Responsibility for process automation is an organizational role & is equal in importance to
the process definition role.
 Organizational role may be fulfilled by a single individual or several different teams.

 Key Organizational Roles:

1. Software Engineering Process Authority (SEPA)
2. Project Review Authority (PRA)
3. Software Engineering Environment Authority (SEEA):
Project Organization and Responsibilities…
Project Organization and Responsibilities…
1. Software Engineering Process Authority (SEPA):
✓ Role: Facilitates process guidance, maintains process maturity, and plans improvements.
✓ Responsibilities:
• Exchanges information with project practitioners.
• Assesses and improves organizational processes.
• Captures and disseminates best practices, understanding project context and desired improvements.
✓ Accountability: Reports to the general manager, acts as a competent authority
✓ Scale: Can be an individual, the general manager, or a team, depending on organization size.
2. Project Review Authority (PRA):
• Role: Ensures project compliance with organizational policies, practices, standards, and
contractual obligations.
• Responsibilities:
• Reviews project conformance to contracts (milestones, deliverables, progress, quality, cost, schedule, risk).
• Monitors adherence to organizational policies, financial performance, and other risks/accomplishments.
• Accountability: The project manager reports to the PRA, which oversees both customer and
organizational commitments.
Project Organization and Responsibilities…
3. Software Engineering Environment Authority (SEEA):
✓ Role: Automates processes, maintains the standard environment, trains projects, and manages
reusable assets.
✓ Responsibilities:
• Supports a standard environment to achieve process commonality and ROI on tools.
• Administers tools, techniques, and training, providing an 80% default solution for projects.

✓ Importance: Critical for institutionalizing processes and amortizing tool investments across projects.

 Infrastructure Components:
✓ Purpose: Supports human resources, independent R&D, and capital software engineering assets.
✓ Components:
• Project Administration: Manages time accounting, contracts, pricing, and corporate system integration.
• Engineering Skill Centers: Maintains custom tools, supports bids/proposals, and conducts independent
R&D.
• Professional Development: Manages training, recruitment, skills databases, literature libraries, and technical
publications.
Project Organization and Responsibilities…
PROJECT ORGANIZATIONS
 The following figure shows a default project organization and maps project-level roles and responsibilities.
Project Organization and Responsibilities…
PROJECT ORGANIZATIONS..
 The main features of the project 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 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.
Project Organization and Responsibilities..
PROJECT ORGANIZATIONS..
[Link] Management Team:
✓ Role: Balances schedules, costs,
functionality, and quality to deliver win
conditions for stakeholders with differing
goals.
✓ Responsibilities:
• Plans the project, executes the plan, and
adapts it based on evolving requirements
or design insights.
• Manages resources and negotiates trade-
offs daily.
• Ensures the plan is realistic, current,
collaborative, stakeholder-understood,
and actively used.
✓ Focus Over Life Cycle: Figure 11-3
illustrates management activities across
phases, emphasizing continuous planning
and adaptation.
Project Organization and Responsibilities..
PROJECT ORGANIZATIONS..
2. Software Architecture Team:
✓ Role: Designs and maintains the system
architecture, critical for team
communication, system-wide qualities
(e.g., reliability, performance,
maintainability), and application
implementation.
✓ Responsibilities:
• Specifies a complete bill of materials and
makes make/buy trade-offs to ensure
predictable construction costs.
• Resolves multi-component design issues
and ensures system-level quality.
✓ Focus Over Life Cycle: Figure 11-4 shows
architecture team activities, dominant in
inception and elaboration phases,
transitioning to maintenance mode in
construction.
Project Organization and Responsibilities..
PROJECT ORGANIZATIONS..
3. Software Development Team:
✓ Role: Focuses on application-specific component
development, testing, and maintenance.
✓ Responsibilities:
• Develops, tests, and maintains individual
components, ensuring quality at the component
level.
• Builds self-documented, repeatable test software
for automated regression testing.
• Resolves single-component design or
implementation issues.
✓ Subteams: Organized by skill sets, including:
• Commercial component specialists.
• Database specialists.
• Graphical user interface specialists.
• Operating systems and networking specialists.
• Domain application specialists (algorithms, business
rules).
✓ Focus Over Life Cycle: Figure 11-5 highlights
development activities, most active during
construction.
Project Organization and Responsibilities..
PROJECT ORGANIZATIONS..
4. Software Assessment Team:
✓ Role: Ensures independent quality evaluation
and accelerates schedules by preparing tests
in parallel with development.
✓ Responsibilities:
• Exposes quality issues impacting customer
expectations, whether or not captured in
requirements.
• Develops use-case-oriented or capability-based
testing via:
▪ Release Specification: Defines plan and
evaluation criteria for releases.
▪ Release Description: Documents release results.
• Creates self-documenting test scenarios
(software programs) for automated regression
testing, subject to change management.
• Determines which components require formal
testing vs. capability-based testing.
✓ Focus Over Life Cycle: Figure 11-6 shows
assessment activities, active throughout but
critical during construction and transition.
Project Organization and Responsibilities..
EVOLUTION OF ORGANIZATIONS
 The project organization reflects the
team’s architecture and must evolve in
alignment with the work breakdown
structure (WBS) as outlined in the
project plan.
 Figure 11-7 illustrates the shift in the
team’s center of gravity across the
project life cycle, with approximately
50% of staff focused on phase-specific
activities.
Project Organization and Responsibilities..
EVOLUTION OF ORGANIZATIONS..
 Phase-Specific Team Focus:
1. Inception Team:
✓ Emphasis: Planning, with contributions from all teams (management, architecture, development,
assessment).
✓ Goal: Develop plans reflecting a consensus of all perspectives to ensure a feasible foundation.
✓ Structure: Small, planning-centric team with broad input to align on project vision and scope.
2. Elaboration Team:
✓ Emphasis: Architecture development, led by the software architecture team, with support from
development and assessment teams.
✓ Goal: Achieve a stable architecture baseline through design and prototyping.
✓ Structure: Architecture-focused, with secondary roles for development and assessment to validate
the architecture.
Project Organization and Responsibilities..
EVOLUTION OF ORGANIZATIONS..
3. Construction Team:
✓ Emphasis: Balanced effort, primarily in software development and software assessment teams.
✓ Goal: Build and test components, ensuring integration and quality align with the architecture.
✓ Structure: Larger team, with significant resources allocated to coding, testing, and integration.
4. Transition Team:
✓ Emphasis: Customer-focused, driven by usage feedback to guide deployment activities.
✓ Goal: Finalize and deliver the product, ensuring it meets customer expectations.
✓ Structure: Deployment-oriented, with emphasis on customer interaction and product refinement.

 The project organization dynamically aligns with the WBS, with each phase (inception,
elaboration, construction, transition) emphasizing distinct activities and team roles. Stable
WBS planning is critical before detailing sub team structures to ensure efficiency and
adaptability throughout the project life cycle.
Process Automation - Tools and
Environment
 The environment must be the first-class artifact of the process.
 Process automation & change management is critical to an iterative process. If the change
is expensive then the development organization will resist it.
 Round-trip engineering & integrated environments promote change freedom & effective
evolution of technical artifacts.
 Metric automation is crucial to effective project control.
 External stakeholders need access to environment resources to improve interaction with the
development team & add value to the process.
 The three levels of process which requires a certain degree of process automation for the
corresponding process to be carried out efficiently.
✓ Metaprocess (Line of business): The automation support for this level is called an infrastructure.
✓ Macroproces (project): The automation support for a project’s process is called an environment.
✓ Microprocess (iteration): The automation support for generating artifacts is generally called a tool.
Process Automation - Tools and
Environment…
 Three Levels of Process and Automation
1. Metaprocess:
✓ Definition: Organizational policies, procedures, and practices for managing a software-intensive line of
business.
✓ Automation Support: Infrastructure (inventory of preferred tools, artifact templates, process guidelines,
project performance repository, skill sets database, and library of past project plans/results).
2. Macroprocess:
✓ Definition: Project-specific policies, procedures, and practices for delivering a software product within cost,
schedule, and quality constraints.
✓ Automation Support: Environment (specific tool collection to produce artifacts as governed by the project
plan).
3. Microprocess:
✓ Definition: Project team’s policies, procedures, and practices for creating specific software artifacts.
✓ Automation Support: Tools (e.g., requirements management, visual modeling, compilers, editors,
debuggers, change management, metrics automation, document automation, test automation, cost
estimation, workflow automation).
Process Automation - Tools and
Environment…
Process Automation - Tools and
Environment…
 Each process workflow (management, environment, requirements, design, implementation,
assessment, deployment) requires specific automation support to enhance efficiency and support
iterative development.
 Automation ranges from artifact generation to bookkeeping, with critical concerns tailored to each
workflow.
1. Management Workflow:
✓ Automation Needs:
• Software Cost Estimation Tools and WBS Tools: Generate planning artifacts.
• Workflow Management Tools and Software Project Control Panel: Maintain online status assessments, improving insight
into metrics.
✓ Purpose: Enhances project planning, control, and metrics-driven decision-making.
2. Environment Workflow:
✓ Automation Needs:
• Configuration Management and Version Control: Essential for iterative development, enabling tracking of changes in
artifact baselines.
✓ Purpose: Supports metrics collection and ensures control over evolving software artifacts.
Process Automation - Tools and
Environment…
3. Requirements Workflow:
✓ Automation Needs:
• Integrated Document Automation and Visual Modeling: Supports textual specifications and use case models,
managing changes in both formats for human-readable output (electronic or paper).
• Traceability Automation: Essential between requirements and test artifacts to verify compliance, but tight
traceability to other technical artifacts (e.g., design) is less critical and may compromise design integrity,
especially in component-based architectures.
✓ Purpose: Focuses on evolving the vision and evaluation criteria rather than premature traceability,
balancing requirements and design evolution.
4. Design Workflow:
✓ Automation Needs:
• Visual Modeling Tools: Capture design models, present them in human-readable formats, and translate them
into source code.
✓ Purpose: Focuses on Visual Models and architecture.
Process Automation - Tools and
Environment…
5. Implementation Workflow:
✓ Automation Needs:
• Programming Environment: Includes editor, compiler, debugger, linker, and runtime.
• Integration with Other Tools: Change management, visual modeling, and test automation tools to support
iterative development.
✓ Purpose: Ensures productive iteration through robust tool integration.
6. Assessment and Deployment Workflows:
✓ Automation Needs:
✓ All tools from other workflows, plus:
• Test Automation and Test Management Tools: Enable automated testing and management of test scenarios.
• Defect Tracking Tools: Support change management, metrics automation, and release baseline control.

✓ Purpose:
• Increases change freedom by automating testing and document production.
• Supports deployment by maintaining consistent defect tracking and release management throughout the
life cycle.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT
 The project environment artifacts evolve through three discrete states.
✓ Prototyping Environment.
✓ Development Environment.
✓ Maintenance Environment.
 The Prototype Environment includes an architecture test bed for prototyping project
architecture to evaluate
 trade-offs during inception & elaboration phase of the life cycle.
 The Development environment should include a full suite of development tools needed to
support various process workflows & round-trip engineering to the maximum extent possible.
 The Maintenance Environment should typically coincide with the mature version of the
development.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 There are four important environment disciplines that are critical to management context &
the success of a modern iterative development process.
✓ Round-Trip engineering
✓ Change Management
• Software Change Orders (SCO)
• Configuration baseline
• Configuration Control Board
✓ Infrastructure
• Organization Policy
• Organization Environment
✓ Stakeholder Environment.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Round Trip Engineering
• Round-Trip engineering is the term used to describe this key requirement for environment that support
iterative development.
• Round-trip engineering is the environment support necessary to maintain Consistency among the
engineering artifacts.
• As the software industry moves into maintaining different information sets for the engineering artifacts,
more automation support is needed to ensure efficient & error free transition of data from one
artifacts to another.
• Round-trip engineering ensures that changes in one artifact (e.g., requirements) are reflected
accurately in related artifacts (e.g., design, code, tests), supporting the dynamic evolution of
software in iterative development.
Process Automation - Tools and
Environment…
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Change Management
• Change management must be automated &
enforced to manage multiple iterations & to
enable change freedom.
• Change is the fundamental primitive of iterative
Development.

I. Software Change Orders

• The atomic unit of software work that is authorized
to create, modify or obsolesce components
within a
• configuration baseline is called a software
change orders ( SCO )
• The basic fields of the SCO are Title, description,
metrics, resolution, assessment & disposition
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Change Management
II. Configuration Baseline
 A configuration baseline is a named collection of software components &Supporting documentation that is subjected to
change management & is upgraded, maintained, tested, statuses & obsolesced a unit.
 There are generally two classes of baselines
1. External Product Release
2. Internal testing Release
 Three levels of baseline releases are required for most Systems
1. Major release
2. Minor Release
3. Interim (temporary) Release
 Major release represents a new generation of the product or project
 A minor release represents the same basic product but with enhanced features, performance or quality.
 Major & Minor releases are intended to be external product releases that are persistent & supportedfor a period of time.
 An interim release corresponds to a developmental configuration that is intended to be transient.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Change Management
II. Configuration Baseline…
 Once software is placed in a controlled baseline all changes are tracked such that a distinction must
be made for the cause of the change. Change categories are
✓ Type 0: Critical Failures (must be fixed before release)
✓ Type 1: A bug or defect either does not impair (Harm) the usefulness of the system or can be worked
✓ around
✓ Type 2: A change that is an enhancement rather than a response to a defect
✓ Type 3: A change that is necessitated by the update to the environment
✓ Type 4: Changes that are not accommodated by the other categories.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Change Management
II. Configuration Baseline…
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Change Management
III. Configuration Control Board (CCB)
 A CCB is a team of people that functions as the decision authority on the content of configuration baselines
 A CCB includes:
1. Software managers
2. Software Architecture managers
3. Software Development managers
4. Software Assessment managers
5. Other Stakeholders who are integral to the maintenance of the controlled software delivery
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Infrastructure
✓ From a process automation perspective, the organization’s infrastructure provides capital assets
including:
1. Organization Policy: A handbook defining standards for software development processes.
2. Organization Environment: An inventory of tools and automation building blocks to configure project
environments efficiently.

1. Organization Policy
A Policy captures the standards for project software development processes. The organization policy is usually
packaged as a handbook that defines the life cycles & the process primitives such as:
• Major milestones
• Intermediate Artifacts
• Engineering repositories
• Metrics
• Roles & Responsibilities
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Infrastructure
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Infrastructure..
2. Organization Environment
A organization environment provides automation building blocks to answer how tasks are executed and way
maximize process automation efficiency. Typical components of an organization's automation building blocks
are as follows:
• Standardized Tool Selections: Secured through site licenses or vendor discounts to encourage adoption,
promoting common workflows and higher ROI on training.
• Standard Notations: E.g., UML for design models for reliability-critical implementations.
• Tool Adjuncts: Artifact templates (e.g., architecture descriptions, evaluation criteria, release descriptions,
status assessments) and customizations.
• Activity Templates: For iteration planning, major milestones, and configuration control boards.
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Stakeholder Environment
✓ Many large scale projects include people in external organizations that represent other stakeholders
participating in the development process they might include:
• Procurement agency contract monitors
• End-user engineering support personnel
• Third party maintenance contractors
• Independent verification & validation contractors
• Representatives of regulatory agencies & others.
✓ These stakeholder representatives also need to access to development resources so that they can contribute value to overall effort.
✓ An on-line environment accessible by the external stakeholders allow them to participate in the process a follows:
• Accept & use executable increments for the hands-on evaluation.
• Use the same on-line tools, data & reports that the development organization uses to manage & monitor the project
• Avoid excessive travel, paper interchange delays, format translations, paper shipping costs & other overhead cost
Process Automation - Tools and
Environment…
THE PROJECT ENVRONMENT..
 Stakeholder Environment…
Project Control and Process Automation
 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/measured 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.

 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.
Project Control and Process Automation…
 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.
 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 them 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.
 Seven core metrics related to project control:
 Management Indicators
1. Work and Progress
2. Budgeted cost and expenditures
3. Staffing and team dynamics
 Quality Indicators
4. Change traffic and stability
5. Breakage and modularity
6. Rework and adaptability
7. Mean time between failures (MTBF) and maturity
Project Control and Process Automation…
1. 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.
Project Control and Process Automation…
2. Budget and Cost Expenditure
 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.
 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 in making accurate assessments is centered 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.
Project Control and Process Automation…
Project Control and Process Automation…
3. Staffing and Team Dynamics
 The staffing and team dynamics metric tracks personnel changes (additions and
reductions) over time to assess team stability and project health in an iterative development
process.
 Effective management of staffing is critical, as it impacts technical progress, financial status,
and overall project success.
 Impact of Staffing Changes:
✓ Staff Increases: Adding new personnel can slow progress as existing team members spend time
onboarding newcomers, reducing short-term productivity.
✓ Low Attrition: Retaining skilled personnel is a key indicator of project success, reflecting strong
team dynamics and effective management.
 Default Metrics:
 People per Month Added: Tracks the rate of new hires or team expansions.
 People per Month Leaving: Monitors attrition rates, with low attrition of talented staff indicating a
healthy project environment.
Project Control and Process Automation…
Project Control and Process Automation…
4. Change Traffic and stability
 Change Traffic: The number of software change orders (SCOs) opened and closed over the
project life cycle.
 Stability: The relationship between opened and closed SCOs, indicating how well changes
are managed.
 This metric can be collected by change type, by release, across all releases, by term, by
components, by subsystems, etc.
Project Control and Process Automation…
5. Breakage and Modularity
 Breakage: The average extent of change per SCO, measured as the amount of software
baseline requiring rework (e.g., in source lines of code (SLOC), function points, components,
subsystems, or files).
 Modularity: The trend of breakage over time, reflecting how modular the system is.
 This metric measures the average breakage per change over time.
 This metric can be collected by revoke SLOC per change, by change type, by release, by
components and by subsystems.
6. Rework and Adaptability
 This metric measures the average rework per change over time.
 Rework: The average effort (in staff-hours) to analyze, resolve, and retest changes to software
baselines.
 Adaptability: The trend of rework effort over time, indicating how easily the system
accommodates changes.
 This metric can be collected by average hours per change, by change type, by release, by
components and by subsystems.
Project Control and Process Automation…
7. Mean time between failures (MTBF) and maturity
 This metric tracks the rate of defects over time.
 Mean Time Between Failures (MTBF): The average usage time between software faults,
calculated as test hours divided by the number of Type 0 (crash or critical) and Type 1
(major functionality) SCOs.
 Maturity: The trend of MTBF over time, indicating improving reliability.
 Deterministic Errors (Bohr-bugs): Caused by specific stimuli, like coding errors.
 Nondeterministic Errors (Heisen-bugs): Probabilistic, often design-related errors.
 This metric can be collected by failure counts, test hours until failure, by release, by
components and by subsystems.
Project Control and Process Automation…
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.
Project Control and Process Automation…
LIFE CYCLE EXPECTATIONS
Project Control and Process Automation…
PRAGMATIC SOFTWARE METRICES
 The basic characteristics of a good metric are as follows:
1. Meaningful to Stakeholders:
✓ Must be relevant to the customer, manager, and performer. If any stakeholder finds it irrelevant, it will not be used.
✓ Customers trust developers’ expertise and will accept metrics demonstrated as meaningful, even if not initially obvious to them.
2. Quantifiable Correlation to Business Performance:
✓ Must show a clear link between process changes and financial outcomes (e.g., cost reduction, revenue increase, margin
improvement), as these are the core organizational goals.
3. Objective and Unambiguous:
✓ Represented numerically (e.g., numbers, percentages, ratios) rather than subjectively (e.g., excellent, good, poor).
✓ Uses well-defined units (e.g., staff-month, SLOC, change, function point, class, scenario, requirement), which are challenging to
define precisely in software engineering.
4. Displays Trends:
✓ Tracks changes over time, across projects, or releases to provide perspective for iterative development.
✓ Metrics rarely drive actions directly; they provide context for decision-makers to interpret and act upon.
5. Natural By-Product of the Process:
✓ Derived from existing engineering and management workflows without introducing new artifacts or overhead.
6. Supported by Automation:
✓ Most effective when collected and reported by automated tools, which require rigorous data definitions, ensuring consistency
and reducing manual effort.
Project Control and Process Automation…
METRICES AUTOMATION
 Metrics automation enhances project control by integrating and presenting data from multiple sources to provide
real-time insights into project status.
 The Software Project Control Panel (SPCP) is a key tool for managing against a plan, automating the collection,
organization, and reporting of metrics and trends derived from evolving engineering artifacts. (It is like a dashboard
for project monitoring)
 Purpose of SPCP:
✓ Provides a centralized interface to monitor project health through customizable metrics displays.
✓ Supports standard features and allows detailed situation analysis to track technical progress, financial status, and other
dimensions.
 Components of a Complete SPCP:
1. Metrics Primitives: Trends, comparisons, and progressions to analyze data over time.
2. Graphical User Interface (GUI): Displays metrics in user-friendly formats (e.g., dials, bar charts).
3. Metrics Collection Agents: Automatically gather data from engineering artifacts.
4. Metrics Data Management Server: Stores and manages collected metrics.
5. Metrics Definitions: Specific presentations for progress in requirements, implementation, assessment, design, and other
dimensions.
6. Actors:
a. Monitor: Defines panel layouts, graphical objects, and data linkages. Roles include software project managers, development team lead s,
architects, and customers.
b. Administrator: Installs the system, defines new mechanisms, graphical objects, and linkages.
Project Control and Process Automation…
METRICES AUTOMATION
 Basic Operation of SPCP (Top-Level Use Case):
1. Start the SPCP.
2. Select a panel preference (customized layout).
3. Select a value or graph metric.(value or graph).
4. Select to superimpose controls.(e.g., thresholds).
5. Drill down to view trends.
6. Drill down to a specific point in time.
7. Drill down to lower levels of information (e.g., subsystem or component details).
8. Drill down to lower-level indicators for deeper analysis.
Process Customization
 A process framework must be tailored to a project’s specific characteristics, with team size
(scale) as the primary driver, alongside stakeholder relationships, process flexibility, process
maturity, architectural risk, and domain experience.
 While process implementations vary, the underlying principles remain consistent, delivering
value across project types (e.g., commercial vs. high-stakes systems).
PROCESS DISCRIMINANTS
 Two Dimensions: Technical complexity and management complexity
Process Customization…
PROCESS DISCRIMINANTS..
 Key Factors:
1. Scale: Team size drives process configuration (e.g., trivial: 1 person, small: 5, moderate: 25, large:
125, huge: 625). Larger teams require more management overhead, formal milestones, and
integrated environments to manage communication and diseconomies of scale/
Process Customization…
PROCESS DISCRIMINANTS..
 Key Factors:
2. Stakeholder Cohesion: Ranges from cohesive (common goals, close communication) to
adversarial (conflicting goals, poor communication), impacting process definition (Table 14-2).
Process Customization…
PROCESS DISCRIMINANTS..
 Key Factors:
3. Process Maturity: Mature organizations with established methods and tools simplify tailoring, unlike
immature ones
Process Customization…
PROCESS DISCRIMINANTS..
 Key Factors:
4. Architectural Risk: High risks (e.g., performance, reliability) require more prototyping before
production.
Process Customization…
PROCESS DISCRIMINANTS..
 Key Factors:
5. Domain Experience: Experienced organizations converge on architectures faster, needing fewer
iterations.
Process Customization…
EXAMPLE: SMALL-SCALE PROJECT VERSUS LARGE-SCALE PROJECT
 Schedule Distribution
✓ Small projects (e.g., 50,000 SLOC, 5 people) have shorter phases (1-month inception, 2-
month elaboration, 5-month construction, 2-month transition; 30/70 engineering/production
split).
✓ Large projects (e.g., 300,000 SLOC, 40 people) need longer phases (8-month inception, 14-
month elaboration, 20-month construction, 8-month transition; 45/55 split).
Process Customization…
EXAMPLE: SMALL-SCALE PROJECT VERSUS LARGE-SCALE PROJECT
 Process Component Importance (Table 14-8):
• Design: Critical for both, ensuring market differentiation (small) or cost-efficient construction
(large).
• Management: Vital for large projects to avoid catastrophic errors; less critical for small teams with
fewer communication risks.
• Deployment: More significant for small commercial projects (diverse user base) than large, single-
site projects with static objectives.