The document discusses software management disciplines including iterative process planning, project organizations and responsibilities, and process automation. It focuses on work breakdown structures (WBS) in iterative process planning. It describes how a conventional WBS can have issues but an evolutionary WBS organized around workflows rather than product frameworks can address those issues. It also discusses planning guidelines, cost and schedule estimating processes, iteration planning processes, and pragmatic planning approaches. Finally, it outlines typical project organizations, roles, and responsibilities including for line-of-business organizations and project teams.

1. Software Management Disciplines
• Iterative Process Planning
 Work Breakdown Structures
 Planning Guidelines
 The Cost and Schedule Estimating Process
 The Iteration Planning Process
 Pragmatic Planning
• Project Organizations and Responsibilities
 Line-of-Business organizations
 Project Organizations
 Evolution Organizations
• Process Automation
 Tools: Automation Building Blocks
 The Project Environment

2. Work Breakdown Structures in Iterative Process Planning
• The development of WBS is dependent on the project management style,
organizational culture, customer preference, financial constraints and several other
hard-to-define 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.
CONVENTIONAL WBS ISSUES:
1. They are prematurely structured around the product design. - Allocated to
responsible managers with budgets, schedules, and expected deliverables, a concrete
planning foundation.
2. They are prematurely decomposed, planned, and budgeted in either too much or
too little detail - team plans out each element completely and creates a baseline
budget and schedule for every task at the same level of detail. On the other hand, most
small-scale or in-house developments elaborate their WBSs to a single level only,
without supporting detail.
3. They are project-specific, and cross-project comparisons are usually difficult or
impossible - With no standard WBS structure, it is extremely difficult to compare
plans, financial data, schedule data, organizational efficiencies, cost trends,
productivity trends, or quality trends across multiple projects. Each project organizes
the work differently and uses different units of measure

3. Hierarchy of Conventional WBS

4. Evolutionary of Work Breakdown Structures
An evolutionary WBS should organize the planning elements around the process
framework rather than the product framework.
• First-level WBS elements are the workflows (management, environment,
requirements, design, implementation, assessment, and deployment). These
elements are usually allocated to a single team and constitute the anatomy of a
project for the purposes of planning and comparison with other projects.
• Second-level elements are defined for each phase of the life cycle (inception,
elaboration, construction, and transition). These elements allow the fidelity of the
plan to evolve more naturally with the level of understanding of the requirements
and architecture, and the risks therein.
• Third-level elements are defined for the focus of activities that produce the
artifacts of each phase. These elements may be the lowest level in the hierarchy
that collects the cost of a discrete artifact for a given phase, or they may be
decomposed further into several lower level activities that, taken together,
produce a single artifact.

5. Evolutionary of Work Breakdown Structures
• Scale - Larger projects will have more levels and substructures.
• Organizational structure - Projects that include subcontractors or span multiple
organizational entities may introduce constraints that necessitate different WBS
allocations.
• Degree of custom development - Depending on the character of the project, there can be
very different emphases in the requirements, design, and implementation workflows. A
business process re-engineering project based primarily on existing components.

6. Evolutionary of Work Breakdown Structures
Situation-Complication-Question (SCQ)

7. Evolutionary of Work Breakdown Structures

8. Planning guidelines in iterative process planning
• It is valuable because most people in management positions are looking for a starting
point, a skeleton they can flesh out with project-specific details. They know that initial
planning guidelines capture the expertise and experience of many other people that instill
some confidence in the stakeholders.
Evolution of planning fidelity in the WBS over the life cycle

9. Planning guidelines in iterative process planning
• Two simple planning guidelines should be considered when a project
plan is being initiated or assessed.
The first guideline prescribes a default
allocation of costs among the first-level
WBS elements
The second guideline prescribes the allocation
of effort and schedule across the life-cycle phases
FIRST-LEVEL
WBS ELEMENT
DEFAULT
BUDGET
Management 10%
Environment 10%
Requirements 10%
Design 15%
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%
DOMA
IN
INCEPT
ION
ELABORA
TION
CONSTRUC
TION
TRANSI
TION
Effort 5% 20% 65% 10%
Sched
ule
10% 30% 50% 10%

10. Planning guidelines in iterative process planning
1. The cost of different labor categories is inherent in these numbers. For example,
the management, requirements, and design elements tend to use more personnel
who are senior and more highly paid than the other elements use.
If requirements and design together consume 25% of the budget (employing people
with an average salary of $100/hour), this sum may represent half as many staff
hours as the assessment element, which also accounts for 25% of the budget but
employs personnel with an average salary of $50/hour.
2. The cost of hardware and software assets that support the process automation and
development teams is also included in the environment element.

11. The Cost and Schedule Estimating Process in Iterative Process
Planning
• Project plans need to be derived from two perspectives. 1. forward-looking, 2. top-down
approach.
 Forward-looking:
1. The software project manager develops a characterization of the overall size, process,
environment, people, and quality required for the project
2. A macro-level estimate of the total effort and schedule is developed using a software
cost estimation model
3. The software project manager partitions the estimate for the effort into a top-level
WBS, also partitions the schedule into major milestone dates and partitions the effort
into a staffing profile
4. At this point, subproject managers are given the responsibility for decomposing each
of the WBS elements into lower levels using their top-level allocation, staffing profile,
and major milestone dates as constraints.

12. The Cost and Schedule Estimating Process in Iterative Process
Planning
 Backward-looking:
1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets
and schedules are estimated by the responsible WBS element manager.
2. Estimates are combined and integrated into higher level budgets and milestones.
Comparisons are made with the top-down budgets and schedule milestones. Gross
differences are assessed and adjustments are made in order to converge on agreement
between the top-down and the bottom-up estimates.
• These two planning approaches should be used together, in balance, throughout the
life cycle of the project.
• During the engineering stage, the top-down perspective will dominate because there
is usually not enough depth of understanding nor stability in the detailed task
sequences to perform credible bottom-up planning.
• During the production stage, there should be enough precedent experience and
planning fidelity that the bottom-up planning perspective will dominate.
• By then, the top-down approach should be well tuned to the project-specific
parameters, so it should be used more as a global assessment technique.

13. Iteration Planning Process
Engineering Stage Production Stage
Inception Elaboration Construction Transition
Feasibility iterations Architecture iterations Usable iterations Product releases
Iteration is used to mean a complete synchronization across the project, with a well-
orchestrated global assessment of the entire project baseline. Other micro-iterations, such as
monthly, weekly, or daily builds, are performed enroute to these project-level synchronization
points.

14. Iteration Planning Process
Engineering stage planning
emphasis:
 Macro-level task estimation for
production-stage artifacts
 Micro-level task estimation for
engineering artifacts
 Stakeholder concurrence
 Coarse-grained variance analysis of
actual vs. planned expenditures
 Tuning the top-down project-
independent planning guidelines into
project-specific planning guidelines.
Production stage planning
emphasis:
 Micro-level task estimation for
production-stage artifacts
 Macro-level task estimation for
engineering artifacts
 Stakeholder concurrence
 Fine-grained variance analysis
of actual vs. planned
expenditures

15. Iteration Planning Process
Inception iterations. Integrate the foundation components of a candidate architecture and
provide an executable framework for elaborating phase. It includes existing components,
commercial components, and custom prototypes sufficient to demonstrate a candidate
architecture and sufficient requirements understanding to establish a credible business case,
vision, and software development plan.
Elaboration iterations. These iterations result in an architecture, including a complete
framework and infrastructure for execution. Upon completion of the architecture iteration, a
few critical use cases should be demonstrable:
(1) initializing the architecture, (2) injecting a scenario to drive the worst-case data processing
flow through the system (3) injecting a scenario to drive the worst-case control flow through
the system.
Construction iterations. Require at least two major construction iterations: an alpha release
and a beta release. An alpha release would include executable capability for all the critical use
cases. It usually represents only about 70% of the total product performance and reliability.
Beta release provides 95% of the total quality attributes.
Transition iterations. Single iteration to transition a beta release into the final product. Small-
scale iterations may be necessary to resolve all the defects, incorporate beta feedback,
incorporate performance improvements.

16. PRAGMATIC PLANNING
• Good planning is more dynamic. While executing iteration N of any phase, the software
project manager must be monitoring and controlling against a plan that was initiated in
iteration N - 1 and must be planning iteration N + 1. The art of good project management is
to make trade-offs in the current iteration plan and the next iteration plan based on objective
results in the current iteration and previous iterations. It overwhelming in early phases or in
projects that are pioneering iterative development.
• Aside from bad architectures and misunderstood requirements, inadequate planning are
most common reasons for project failures. Conversely, the success of every successful
project can be attributed in part to good planning. Three essential perspectives are:
planning, requirements, and architecture. The end products associated with these
perspectives (software development plan, requirements specifications, and architecture
description document) are not emphasized. Project's plan defines how the project
requirements will be transformed into a product within the business constraints. It must be
realistic, current, team product, understood by the stakeholders, and used.
• Plans are not just for managers. The more open and visible planning process and results,
more ownership among the team members who need to execute it. Good, open plans can
shape cultures and encourage teamwork.

17. Project Organizations and Responsibilities
• Software lines of business are motivated by return on investment, new business
discriminators, market diversification, and profitability.
• Project teams are motivated by the cost, schedule, and quality of specific deliverables.
LINE-Of-BUSINESS ORGANIZATIONS
Main features of the default organization:
• Responsibility for process definition and maintenance is specific to a cohesive line of
business, where process commonality makes sense. For example, the process for
developing avionics software is different from the process used to develop office
applications.
• Responsibility for process automation is an organizational role and is equal in importance
to the process definition role. 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 the organization. A 20-person software product company may
require only a single person to fulfill all the roles, while a 10,000-person
telecommunications company may require 100 people to achieve the work.

18. Line-of-Business Organizations
Default roles in a software line-of-business organizations
Project A
Manager
Project B
Manager
Project N
Manager
Organization
Manager
Software Engineering
Process Authority
Software Engineering
Environment Authority
Project Review
Authority
Infrastructure
• Process definition
• Process improvement
• Process automation
• Project compliance
• Periodic risk assessment
• Project administration
• Engineering skill centers
• Professional development

19. Line-of-Business Organizations Roles
Software Engineering Process Authority
• The Software Engineering Process Authority (SEPA) facilitates the exchange of
information and process guidance both to and from project practitioners. The
organization general manager for maintaining a current assessment of the organization's
process maturity and its plan for future process improvements.
• The SEPA must help initiate and periodically assess project processes. Catalyzing the
capture and dissemination of software best practices can be accomplished only when the
SEPA understands both the desired improvement and the project context. SEPA takes on
responsibility and accountability for the process definition and its maintenance
(modification, improvement, technology insertion). The SEPA could be a single individual,
the general manager, or even a team of representatives. The SEPA must truly be an
authority, competent and powerful.
Project Review Authority
• The Project Review Authority (PRA) is the single individual responsible for ensuring that a
organizational and business unit software policies, practices, and standards.
• A software project manager is responsible for meeting the requirements of a contract or
some other project compliance standards. The PRA reviews both the project's conformance
to contractual obligations and the project's organizational policy obligations.
• The customer monitors contract requirements, contract milestones, contract deliverables,
monthly management reviews, progress, quality, cost, schedule, and risk.
• The PRA reviews customer commitments as well as adherence to organizational policies,
organizational deliverables, financial performance, and other risks and accomplishments.

20. Line-of-Business Organizations Roles
Software Engineering Environment Authority
• The Software Engineering Environment Authority (SEEA) is responsible for automating the
organization's process, maintaining the organization's standard environment, training
projects to use the environment, and maintaining organization-wide reusable assets.
• The SEEA role is necessary to achieve a significant return on investment for a common
process. Tools, techniques, and training can be amortized 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 achieving
institutionalization of the organization's process and a good RoI on capital tool investments.
Infrastructure
• An organization's infrastructure provides human resources support, project-independent
research and development, and other capital software engineering assets.
• The typical components of the organizational infrastructure are as follows:
• Project administration: time accounting system; contracts, pricing, terms and
conditions; corporate information systems integration
• Engineering skill centers: custom tools repository and maintenance, bid and proposal
support, independent research and development
• Professional development: internal training boot camp, personnel recruiting,
personnel skills database maintenance, literature and assets library, technical
publications

21. Project Organizations
The main features of the default organization are as follows:
• The project management team is an active participant, responsible for
producing as well as managing. Project management is not a spectator sport.
• 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.

23. Project Organizations
Software Management Team
Inception Elaboration Construction Transition
Elaboration phase planning
Team formulating
Contract baselining
Architecture costs
Construction phase planning
Full staff recruitment
Risk resolution
Product acceptance criteria
Construction costs
Transition phase planning
Construction plan
optimization
Risk management
Customer satisfaction
Contract closure
Sales support
Next-generation planning
Artifacts
 Business case
 Vision
 Software development plan
 Work breakdown structure
 Status assessments
 Requirements set
 Systems Engineering
 Financial Administration
 Quality Assurance
Responsibilities
 Resource commitments
 Personnel assignments
 Plans, priorities,
 Stakeholder satisfaction
 Scope definition
 Risk management
 Project control
Life-Cycle Focus

24. Software Management Team
• Most projects are over constrained. Schedules, costs, functionality, and quality
expectations are highly interrelated and require continuous negotiation among multiple
stakeholders who have differing goals.
• The software management team carries the burden of delivering win conditions to all
stakeholders.
• In this regard, the software project manager spends every day worrying about balance.
Figure shows the software management team activities over the project life cycle.
• The software management team is responsible for planning the effort, conducting the plan,
and adapting the plan to changes in the understanding of the requirements or the design.
• Toward this end, the team takes ownership of resource management and project scope, and
sets operational priorities across the project life cycle.
• At an abstract level, these activities correspond to managing the expectations of all
stakeholders throughout the project life cycle.
• The software management team takes ownership of all aspects of quality. In particular, it
is responsible for attaining and maintaining a balance among these aspects so that the
overall solution is adequate for all stakeholders and optimal for as many of them as
possible.

25. Project Organizations Roles
Software Architecture Team
Inception Elaboration Construction Transition
Architecture prototyping
Make/buy trade-offs
Primary scenario definition
Architecture evaluation
criteria definition
Architecture base lining
Primary scenario
demonstration
Make/buy trade-offs base
lining
Architecture maintenance
Multiple-component issue
resolution
Performance tuning
Quality improvements
Architecture maintenance
Multiple-component issue
resolution
Performance tuning
Quality improvements
Artifacts
 Architecture description
 Requirements set
 Design set
 Release specifications
 Demonstrations
 Use-case modelers
 Design modelers
 Performance analysts Responsibilities
 Requirements trade-offs
 Design trade-offs
 Component selection
 Initial integration
 Technical risk solution
Life-Cycle Focus

26. Software Architecture Team
• The software architecture team is responsible for the architecture. This responsibility
encompasses the engineering necessary to specify a complete bill of materials for the
software and the engineering necessary to make significant make/buy trade-offs.
• So that all custom components are elaborated to the extent that construction/assembly
costs are highly predictable.
• For any project, the skill of the software architecture team is crucial. It provides the
framework for facilitating team communications, for achieving system-wide qualities, and
for implementing the applications.
• With a good architecture team, an average development team can succeed. If the
architecture is weak, even an expert development team of superstar programmers will
probably not succeed.
To succeed, the architecture team must includes
o Domain experience to produce an acceptable design view and use case view
o Software technology experience to produce an acceptable process view, component view
and deployment view.

27. Project Organizations Roles
Software Development Team
Inception Elaboration Construction Transition
Prototyping support
Make/buy trade-offs
Critical component design
Critical component
implementation and test
Critical component base line
Component design
Component implementation
Component stand-alone test
Component maintenance
Component maintenance
Component documentation
Artifacts
 Design set
 Implementation set
 Deployment set
 Component teams
Responsibilities
 Component design
 Component implementation
 Component stand-alone test
 Component maintenance
 Component documentation
Life-Cycle Focus

28. Software Development Team
Typical skill sets includes:
• Commercial component: specialists with detailed knowledge of commercial
components central to a system's architecture
• Database: specialists with experience in the organization, storage, and retrieval
of data
• Graphical user interfaces: specialists with experience in the display
organization, data presentation, and user interaction necessary to support human
input, output, and control needs
• Operating systems and networking: specialists with experience in the
execution of multiple software objects on a network of hardware resources,
including all the typical control issues associated with initialization,
synchronization, resource sharing, name space management, reconfiguration,
termination, and inter object communications
• Domain applications: specialists with experience in the algorithms, application
processing, or business rules specific to the system

29. Project Organizations Roles
Software Assessment Team
Inception Elaboration Construction Transition
Infrastructure planning
Primary scenario
prototyping
Infrastructure base lining
Architecture release testing
Change management
Initial user manual
Infrastructure upgrades
Release testing
Change management
User manual base line
Requirements verification
Infrastructure maintenance
Release base lining
Change management
Deployment to users
Requirements verification
Artifacts
 Deployment set
 SCO database
 User manual
 Environment
 Release specifications
 Release descriptions
 Deployment documents
 Release testing
 Change management
 Deployment
 Environment support Responsibilities
 Project infrastructure
 Independent testing
 Requirements verification
 Metrics analysis
 Configuration control
 Change management
 User deployment
Life-Cycle Focus

30. Software Assessment Team
There are two reasons for using an independent team for software assessment.
• The first is ensuring an independent quality perspective.
• It has pros such as ensuring that the ownership biases of developers do not pollute the
assessment of quality and cons such as relieving the software development team of
ownership in quality, to some extent.
• A more important reason for using an independent test team is to exploit the concurrency
of activities.
• Schedules can be accelerated by developing the software and preparing for testing in
parallel with development activities.
• Change management, test planning, and test scenario development can be performed in
parallel with design and development.
A modern process should employ use-case-oriented or capability-based testing organized as a
sequence of builds and mechanized via two artifacts:
1. Release specification (the plan and evaluation criteria for a release)
2. Release description (the results of a release)

31. Evolution of Organizations
Software
management
50%
Software
assessment
10%
Software
development
20%
Software
architecture
20%
Software
management
10%
Software
assessment
20%
Software
development
20%
Software
architecture
50%
Software
management
10%
Software
assessment
50%
Software
development
35%
Software
architecture
5%
Software
management
10%
Software
assessment
30%
Software
development
50%
Software
architecture
10%
Inception Elaboration
Transition Construction
Staff Allotment

32. Evolution of Organizations
• The project organization represents the architecture of the team and needs to evolve
consistent with the project plan captured in the work breakdown structure.
• The team's center of gravity shifts over the life cycle, with about 50% of the staff assigned
to one set of activities in each phase.
A different set of activities is emphasized in each phase, as follows:
• Inception team: an organization focused on planning, with enough support from the other
teams to ensure that the plans represent a consensus of all perspectives.
• Elaboration team: an architecture-focused organization in which the driving forces of the
project reside in the software architecture team and supported by the software
development and software assessment teams as necessary to achieve a stable architecture
baseline.
• Construction team: a fairly balanced organization in which most of the activity resides in
the software development and software assessment teams Transition team: a customer-
focused organization in which usage feedback drives the deployment activities
• It is equally important to elaborate the details of sub teams, responsibilities, and work
packages, but not until the planning details in the WBS are stable. Defining all the details
of lower level team structures prematurely can result in serious downstream inefficiencies.

33. Process Automation
• Automation needs to improve the predictability of software
management and performance of their software lines of business (in
terms of product quality, time to market, return on investment, and
productivity).
• Most software organizations are confronted with the task of integrating
their own environment and infrastructure for software development.
• This process typically results in the selection of more or less
incompatible tools that have different information repositories, are
supplied by different vendors, work on different platforms.
• Integrating such an infrastructure has proven to be much more
problematic than expected.
• To avoid the issues automation is required in software development.

34. Three levels of process
Metaprocess, Macroprocess, and Microprocess
Each level requires a certain degree of process automation for efficient process:
1. Metaprocess:
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 that includes tools, artifact templates, microprocess guidelines,
macroprocess guidelines, project performance repository, database of
organizational skill sets, and library of precedent examples of past project plans
and results.
2. Macroprocess:
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.
An environment is a specific collection of tools to produce a specific set of
artifacts as governed by a specific project plan.

35. Three levels of process
3. Microprocess:
A project team's policies, procedures, and practices for achieving an artifact of
the software process.
The automation support for generating an artifact is generally called a tool.
Typical tools include requirements management, visual modeling, compilers,
editors, debuggers, change management, metrics automation, document
automation, test automation, cost estimation, and workflow automation.

36. TOOLS: AUTOMATION BUILDING BLOCKS
Typical automation and tool components that support the process workflows

37. TOOLS: AUTOMATION BUILDING BLOCKS
• Management
• There are many opportunities for automating the project planning and
control activities of the management workflow.
• Software cost estimation tools and WBS tools are useful for generating
the planning artifacts.
• It uses on-line version of the status assessment are advantageous.
• This automation improves the insight of the metrics collection and
reporting.
• Environment
• Configuration management and version control are essential in a modern
iterative development process.
• Much of the metrics dependent on measuring changes in software artifact
baselines.

38. TOOLS: AUTOMATION BUILDING BLOCKS
• Requirements
• Conventional approaches decomposed system requirements into subsystem
requirements, subsystem requirements into component requirements, and
component requirements into unit requirements.
• The equal treatment of all requirements drained away engineering hours
from the driving requirements, then wasted that time on paperwork
associated with detailed traceability that was inevitably discarded later as
the driving requirements and subsequent design understanding evolved.
• Lower levels of requirements are driven by the process-organized by
iteration rather than by lower level component-in the form of evaluation
criteria.
• Evaluation criteria are captured in the release specification artifacts, which
are transient snapshots of objectives for a given iteration.
• Evaluation criteria are derived from the vision statement as well as from
many other sources, such as make/buy analyses, risk management
concerns, architectural considerations, implementation constraints, quality
thresholds, and even shots in the dark.

39. TOOLS: AUTOMATION BUILDING BLOCKS
• Design
• The tools that support the requirements, design, implementation, and assessment
workflows are usually used together.
• The primary support required for the design workflow is visual modeling, which is
used for capturing design models, presenting them in human-readable format, and
translating them into source code.
• An architecture-first and demonstration-based process is enabled by existing
architecture components and middleware.
• Implementation
• It relies primarily on a programming environment (editor, compiler, debugger, linker,
run time) with the change management tools, visual modeling tools, and test
automation tools to support productive iteration.
• Assessment and Deployment
• Requires to support test automation and test management.
• To increase change freedom, testing and document production must be mostly
automated.
• Defect tracking is a tool that supports assessment. It provides the change management
instrumentation necessary to automate metrics and control release baselines. It is also
needed to support the deployment workflow throughout the life cycle.

40. PROJECT ENVIRONMENT
The project environment artifacts evolve through three discrete states:
1. Prototyping environment, 2. Development environment, and 3. Maintenance
environment.
1. The prototyping environment
• Includes an architecture testbed for prototyping project architectures to
evaluate trade-offs during the inception and elaboration phases.
• This informal configuration of tools should be capable of supporting the
following activities:
• Performance trade-offs and technical risk analyses
• Make/buy trade-offs and feasibility studies for commercial products
• Fault tolerance/dynamic reconfiguration trade-offs
• Analysis of the risks associated with transitioning to full-scale implementation
• Development of test scenarios, tools, and instrumentation suitable for
analyzing the requirements
2. The development environment
• It should include a full suite of development tools needed to support the various
process workflows and to support round-trip engineering to the maximum
extent possible.

41. PROJECT ENVIRONMENT
• 3. The maintenance environment
• It 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 delivered as one of the project's end products.
Four important environment disciplines to the success of a modern iterative
development process:
1. Tools must be integrated to maintain consistency and traceability.
Roundtrip engineering is the term used to describe this key requirement for
environments that support iterative development.
2. Change management must be automated and enforced to manage multiple
iterations and to enable change freedom.
3. Organizational infrastructures enable project environments to be derived from a
common base of processes and tools. A common infrastructure promotes inter-
project consistency, reuse of training, reuse of lessons learned, and other
strategic improvements to the organization's meta-process.
4. Extending automation support for stakeholder environments enables further
support for paperless exchange of information and more effective review of
engineering artifacts.

42. Roundtrip engineering in project environment
It maintains consistency among the engineering artifacts.
• The automated translation of design models to source code (both forward and reverse
engineering) is fairly well established.
• Distributed ActiveX and the Common Object Request Broker Architecture (CORBA)
used. Compilers and linkers have long provided automation of source code into
executable code.

43. Change management in project environment
Tracking changes in the technical artifacts to understand technical progress and quality
trends toward delivering an acceptable end product or interim release.
In a modern process, requirements, design, and implementation set artifacts are captured
early in the life cycle and evolved through multiple generations.
Software Change Orders (SCO)
The atomic unit of software work to create, modify, or obsolesce components within a
configuration baseline is called a software change order (SCO).
SCO is a key mechanism for partitioning, allocating, and scheduling software work against
an established software baseline and for assessing progress and quality.
Figure shows a set of change primitives and required metrics. By automating data entry and
maintaining change records on-line, the change management bureaucracy associated with
metrics reporting activities can also be automated.
• Title. The title is suggested by the originator and is finalized upon acceptance by the
configuration control board (CCB). It is reference to an external software problem report
if the change was initiated by an external person (such as a user).
• Description. The problem description includes the name of the originator, date of
origination, CCB-assigned SCO identifier, and relevant version identifiers of related
support software. It provides much detail along with code excerpts, display snapshots,
error messages, and any other data.

44. Change management in project environment

45. Change management in project environment
Metrics. The metrics are important for planning, scheduling, and assessing quality
improvement.
• Change categories are type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3
(new feature), and type 4 (other).
• Initial estimates are made of the amount of breakage and effort required to resolve the
problem. The breakage item quantifies the volume of change, and the rework item
quantifies the complexity of change.
• Upon resolution, the actual breakage is noted, and the actual rework effort is further
elaborated.
• The analysis item identifies the number of staff hours expended in understanding the
required change (re-creating, isolating, and debugging the problem if the change is
type a or 1; analysis and proto typing alternative solutions if it is type 2 or 3).
• The implement item identifies the staff hours necessary to design and implement the
resolution.
• The test item identifies the hours expended in testing the resolution, and the document
item identifies all effort expended in updating other artifacts such as the user manual
or release description.
• Breakage quantifies the extent of change and can be defined in units of SLOC,
function points, files, components, or classes

46. Change management in project environment
Resolution. This field includes the name of the person responsible for implementing the
change, the components changed, the actual metrics, and a description of the change.
Assessment. This field describes the assessment technique as either inspection, analysis,
demonstration, or test. It should identify all different test configurations, such as platforms,
topologies, and compilers.
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, with rationale, such as not a problem, duplicate, obsolete change,
resolved by another SCO
• Archived: accepted but postponed until a later release
• In progress: assigned and actively being resolved by the development organization
• In assessment: resolved by the development organization; being assessed by a test
organization
• Closed: completely resolved, with the concurrence of all CCB members

47. Infrastructures in project environment
Infrastructure provides the organization‘s capital assets, including two key artifacts:
1. a policy that captures the standards for project software development processes, and
2. an environment that captures an inventory of tools.
Organization Policy
It is usually packaged as a handbook that defines the life cycle and the process primitives
(major milestones, intermediate artifacts, engineering repositories, metrics, roles and
responsibilities).
The handbook provides a general framework for answering the following questions:
• What gets done? (activities and artifacts)
• When does it get done? (mapping to the life-cycle phases and milestones)
• Who does it? (team roles and responsibilities)
• How do we know that it is adequate? (checkpoints, metrics, and standards of
performance)

48. Infrastructures in project environment
Organization Environment
The organization environment defines 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 (through investment by the organization in a site
license or negotiation of a favorable discount with a tool vendor so that project teams
are motivated economically to use that tool), which promote common workflows and
a higher ROI on training
• Standard notations for artifacts, such as UML for all design models, or Ada 95 for
all custom-developed, reliability-critical implementation artifacts.
• Tool adjuncts such as existing artifact templates (architecture description, evaluation
criteria, release descriptions, status assessments] or customizations
• Activity templates (iteration planning, major milestone activities, configuration
control boards)

49. Stakeholder environments in project environment
Many large-scale contractual projects include people in external organizations that
represent other stakeholders such as procurement agency contract monitors, end-user
engineering support personnel, third-party maintenance contractors, independent
verification and validation contractors, representatives of regulatory agencies, and others.
These stakeholder representatives also need access to development environment resources to
contribute overall effort.
An on-line environment accessible by the external stakeholders allows them to participate in
the process as follows:
• 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

50. Infrastructures in project environment
Extending environments into stakeholder domains

51. • Technical artifacts are not just paper. Electronic artifacts in rigorous notations such as
visual models and source code are viewed far more efficiently by using tools with smart
browsers.
• Independent assessments of the evolving artifacts are encouraged by electronic read-
only access to on-line data such as configuration baseline libraries and the change
management database. Reviews and inspections, breakage/rework assessments, metrics
analyses, and even beta testing can be performed independently of the development
team.
• Even paper documents should be delivered electronically to reduce production
costs and turnaround time.
Infrastructures in project environment
Extending environments into stakeholder domains

52. Reference
• Software Project Management, Walker Rayce,
PEA.