UNIT-4

PROCESS AUTOMATION
TOOLS: AUTOMATION BUILDING
BLOCKS
 Process automation generally refers to use of digital technology
simply to work and perform a process or processes.
 This is done to accomplish or complete workflow or function.
 To an iterative process, process automation and change
management is a very critical one.
 Even if change will be too expensive, then development will resist
and won’t allow it.
 Many tools are available to automate the s/w development
process.
 Each of the process workflows has a distinct need for automation
support.
Cont..
 In diagram given above, some of important tools are included and
introduced that are very much needed across overall software
process and correlates very well to process framework.

 Each of tools of software development map closely to one of process

workflows and each of these process workflows have a distinct
automation support.

 Workflow automation generally makes complicated software process

in an easy way to manage.

 Here you will see environment that is necessary to support process

framework.

 Some of concerns are associated with each workflow are given

below :
1. Management :

 Nowadays, there are several opportunities and chances available for

automation of project planning and control activities of management
workflow.
 For creating planning artifacts, several tools are useful such as
software cost estimation tools and Work Breakdown Structure (WBS)
tools.
 Workflow management software is an advanced platform that
provides flexible tools to improve way you work in an efficient
manner.
 Thus, automation support can also improve insight into metrics.
2. Environment :

 Automating development process and also developing an

infrastructure for supporting different project workflows are very
essential activities of engineering stage of life-cycle.
 Environment that generally gives and provides process automation is
a tangible artifact that is generally very critical to life-cycle of system
being developed.
 Even, top-level WBS recognizes environment like a first-class
workflow.
 Integrating their own environment and infrastructure for software
development is one of main tasks for most of software organizations.
3. Requirements :

 Requirements management is a very systematic approach for identifying,

documenting, organizing, and tracking changing requirements of a system.
 It is also responsible for establishing and maintaining agreement between
user or customer and project team on changing requirements of system.
 If process wants strong traceability among requirements and design, then
architecture is very much likely to evolve in a way that it optimizes
requirements traceability other than design integrity.
 This effect is even more and highly effective and pronounced if tools are
used for process automation.
 For effective requirement management, points that must include are
maintaining a clear statement of requirements with attributes for every
type of requirement and traceability to other requirements and other
project artifacts.
4. Design :

 Workflow design is actually a visual depiction of each step that is

involved in a workflow from start to end.
 It generally lays out each and every task sequentially and provides
complete clarity into how data moves from one task to another one.
 Workflow design tools simply allow us to depict different tasks
involved graphically as well as also depict performers, timelines,
data, and other aspects that are crucial to execution.
 Visual modelling is primary support that is required and essential for
design workflow.
 Visual model is generally used for capturing design models,
representing them in a human-readable format, and also translating
them into source code.
5. Implementation :

 The main focus and purpose of implementation workflow are to write

and initially test software, relies primarily on programming
environment (editor, compiler, debugger, etc.).
 But on other hand, it should also include substantial integration along
with change management tools, visual modelling tools, and test
automation tools.
 This is simply required to just support iteration to be productive.
 It is main focus of Construction phase.
 The implementation simply means to transform a design model into
executable one.
6. Assessment and
Deployment :
 Workflow assessment is initial step to identifying outdated software
processes and just replace them with most effective process.
 This generally combines domain expertise, qualitative and
quantitative information gathering and collection, proprietary tools,
and much more.
 It requires and needs every tool discussed along with some additional
capabilities simply to support test automation and test management.
 Defect tracking is also a tool that supports assessment.
The Project Environment:

 The project environment artifacts evolve through three discrete

states. (1)Prototyping Environment.(2)Development Environment.
(3)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.
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.
Round Trip Environment
• Tools must be integrated to maintain consistency & traceability.
• Round-Trip engineering is the term used to describe this key requirement
for environment that support iterative development.
• 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 is the environment support necessary to maintain
Consistency among the engineering artifacts.
• The primary reason for round-trip engineering is to allow freedom in
changing software engineering data sources.
• This configuration control of all the technical artifacts is crucial to
maintaining a consistent & error-free representation of the evolving
product.
• Compilers and Linkers have long provided automation of source code into
executable code.
Change Management

• Change management must be automated & enforced to

manage multiple iterations & to enable change freedom.
• Tracking changes in the technical artifacts is crucial to
understanding the true technical progress & quality
trends towards delivering an acceptable end product.
• In a modern process – in which requirements, design, &
implementation set artifacts – change management has
become fundamental to all phases & almost all activities.
• 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 )
• SCO are a key mechanism for partitioning, allocating, &
scheduling software work for assessing progress & quality.
• An SCO should be written against a single component so
that it is easily allocated to a single individual.
• The basic fields of the SCO are Title, description, metrics,
resolution, assessment & disposition.
 Title:
 The title is suggested by the originator and is finalized upon
acceptance by the configuration control board (CCB).
 This field should include a 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.
 The textual problem description should provide as much detail as
possible, along with attached code excerpts, display snapshots, error
messages.

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.
 Metrics:
 The metrics collected for each SCO are important for planning, for scheduling, and for
assessing quality improvement.
 Change categories are type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3
(new feature), and type 4 (other).
 Upon acceptance of the SCO, initial estimates are made of the amount of breakage and
the effort required to resolve the problem.
 The breakage item quantifies the Title: volume of change, and the rework item
quantifies the complexity of change.
 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
0 or 1; analysis and prototyping 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.
 In the case of SLOC, a source file comparison program that quantifies differences may
provide a simple estimate of breakage.
 Assessment:
 This field describes the assessment technique as either inspection, analysis,
demonstration, or test.
 Where applicable, it should also reference all existing test cases and new test
cases executed, and 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(Change/configuration Control Board):
 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
A priority and release identifier can also be assigned by the CCB to guide the
prioritization and organization of concurrent development activities.
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.
External Product Release
Internal testing Release
 A configuration baseline is a named collection of components that is
treated as a unit.
 A project may release a configuration baseline to the user community
for beta testing.
Cont…

 Three levels of baseline releases are required for most Systems

 1. Major release (N)
 2. Minor Release (M)
 3. Interim (temporary) Release (X)
 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 & supported for a period of time.
 An interim release corresponds to a developmental configuration
that is intended to be transient(Impermanent).
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.(version upgrade etc)
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 system.
 The operational concept of an iterative development process must include
comprehensive and rigorous change management of the evolving software
baselines.
 The fundamental process for controlling the software development and
maintenance activities is described through the sequence of states traversed by
an SCO.
[Proposed]:
 A proposed change is drafted and submitted to the CCB.
 The proposed change must include a technical description of the problem and
an estimate of the resolution effort.
[Accepted, archived, or rejected]:
 The CCB assigns a unique identifier and accepts, archives, or rejects each
proposed change.
 Acceptance includes the change for resolution in the next release;
 archiving accepts the change but postpones it for resolution in a future release;
 And rejection judges the change to be without merit, redundant with other
proposed changes, or out of scope.
 The CCB verifies that all SCO fields are appropriate and accurate before
accepting the SCO, then assigns the SCO to a responsible person in the
development organization for resolution.
 [In progress]:

 The responsible person analyzes, implements, and tests a solution

to satisfy the SCO.
 This task includes updating documentation, release notes, and SCO
metrics actuals, and submitting new SCOs, if necessary.
 Upon achieving a complete solution, the responsible person
completes the resolution section of the SCO and submits it to the
independent test team for assessment.
[In assessment]:

 The independent test team assesses whether the SCO is completely

resolved.
 When the independent test team deems the change to be
satisfactorily resolved, the SCO is submitted to the CCB for final
disposition and closure.

[Closed]:

 When the development organization, independent test organization,

and CCB concur that the SCO is resolved, it is transitioned to a
closed status.
Infrastructure
 The organization infrastructure provides the organization’s capital assets including
two key artifacts - Policy & Environment
 A policy that captures the standards for project software development processes,
and an environment that captures an Inventory of tools.

1. Organization Policy:
 A Policy captures the standards for project software development processes.
 The Organization Policy is the defining document for the organization’s software
policies.
 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
The handbook provides a general framework
for answering the following questions:
Most software intensive companies have
three distinct levels of organizations, with
a different policy focus at each level:
II 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 & techniques to automate the process as much as practical.
 The Environment that captures an inventory of tools which are
building blocks from which project environments can be configured
efficiently & economically.
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(Procurement agency means any State agency,
except a Department, that is authorized by law or regulations to procure or contract, A
procurement agent is a professional who helps companies get the best possible deals
on products and services. They work with suppliers to get the best prices and ensure
that contracts are fulfilled in a timely manner. Procurement agents can also help
companies find new suppliers or evaluate their current ones)
 End-user engineering support personnel
 Third party maintenance contractors
 Independent verification & validation contractors
 Representatives of regulatory agencies & others.(regulatory agency, independent
governmental body established by legislative act in order to set standards in a specific
field of activity, or operations, in the private sector of the economy and then to enforce
those standards).
Cont…

• These stakeholder representatives also need to access to

development resources so that they can contribute value to overall
effort. These stakeholders will be access through on-line
• 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