presenting
PROCESS AUTOMATION
Prepared and presented by:
Shruti Sogi(1706212)
Jaspreet Kaur(1706213)
Process Automation
Tools: Building Blocks
Project Environment
Round Trip
Engineering
Change
Management
 The
process automation is required for modern
Mechanizing
thedevelopment projects to operate
software
Depends on sort of process and
process to reduce
profitability..
the architecture of the process
the manpower
efforts..
A wholesome that was
actually desired and
required..
Time Elapsed is worth
the performance
Better workflow
+
infrastructure context
Engineering-stage activity..
The Process Automation and change management in
particular, are critical to an iterative process. If change is too
expensive, it is to be resist by the change management..
The environment must be the first class ARTIFACT of the
process..
Main FOCUS is the workflow of a project-level
environment, infrastructure context of the project’s parent
organization
WORKFLOWS
ENVIRONMENT TOOLS AND PROCESS AUTOMATION
MANAGEMENT
Workflow Automation, Metrics Automation
ENVIRONMENT
Change Management, Document Automation
REQUIREMENTS
Requirement Management
DESIGN
Visual Modeling
IMPLEMENTATI
ON
Editor, Compiler-Debugger
Test Automation, Defect
Tracking
ASSESSMENT
DEPLOYMENT
PROCESS
Life Cycle
Defect Tracking
ORGANISATION POLICY
INCEPTION
ELABORATION
CONSTRUCTION
TRANSITION
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.
For managing against a plan, workflow
management tools and a software project control
panel that can maintain an on-line version of the
status assessment are advantageous.
WORKFLOWS
ENVIRONMENT TOOLS AND PROCESS AUTOMATION
MANAGEMENT
Workflow Automation, Metrics Automation
ENVIRONMENT
Change Management, Document Automation
REQUIREMENTS
Requirement Management
DESIGN
Visual Modeling
IMPLEMENTATI
ON
Editor, Compiler-Debugger
Test Automation, Defect
Tracking
ASSESSMENT
DEPLOYMENT
PROCESS
Life Cycle
Defect Tracking
ORGANISATION POLICY
INCEPTION
ELABORATION
CONSTRUCTION
TRANSITION
Configuration Management and version control are
essential in a modern iterative development process.
Most of the iterative approach is dependent on
measuring changes in software artifact baselines.
There are some of the change management automation
supported by the environment, namely:


Organization Environment
Stakeholder Environment, and more.
WORKFLOWS
ENVIRONMENT TOOLS AND PROCESS AUTOMATION
MANAGEMENT
Workflow Automation, Metrics Automation
ENVIRONMENT
Change Management, Document Automation
REQUIREMENTS
Requirement Management
DESIGN
Visual Modeling
IMPLEMENTATI
ON
Editor, Compiler-Debugger
Test Automation, Defect
Tracking
ASSESSMENT
DEPLOYMENT
PROCESS
Life Cycle
Defect Tracking
ORGANISATION POLICY
INCEPTION
ELABORATION
CONSTRUCTION
TRANSITION
 Conventional
Approach:
Component Requirements
Unit Requirements
 Modern
Approach:
System Requirements
VISION STATEMENTS
 Vision
statements captures the contract between
the development group and the buyer.
= EVALUATION CRITERIA
MODERN
APPROACH
 Time could be utilized as per
engineering priorities..
 The info should be evolving but
slowly varying..
 The buyers should be understood
of the information..
 The lower-level requirements are
driven by the process- organized by
the iteration- rather than lower-level
components..
 Evaluation criteria are derived
from vision statements and other
considerations..
CONVENTIONAL
APPROACH
 The equal treatment of all
requirements drained away
engineering hours..
 The info is varying but evolving..
 Unit requirements are as
prioritized as the system tasks..
 Evaluation criteria are caught in
subsequent design understanding


Iterative process allow the customer and the
developer to work with tangible, evolving
versions of the system…
Requirements can-and must be-evolved along
with architecture, rather than focusing on
consistency and completeness and traceability
of the immature requirements specification..
(1)
(2)
Requirement is based on textual and modelbased representations..so, environment should
provide INTEGRATED DOCUMENT
AUTOMATION..
Traceability between requirements and other
artifacts needs to be AUTOMATED..
VISUALMODELING
is the
primary
support
Visual modeling is used
to capture design
models…

•
•
•
Three states
The prototyping environment
The development environment
The maintenance environment






It includes an architecture test bed to evaluate tradeoff
during the inception and elaboration phases of life cycle.
It includes following activities:Performance trade-off and technical risk analyses.
Fault tolerance/dynamic reconfiguration trade-offs.
Analysis of risk associated with transitioning to full scale
implementation.
Development of test scenarios ,tools suitable for
analyzing the requirements.

It includes a full suite of development tools
needed to support the various process
workflows and to support round trip
engineering to the maximum extent possible.

It coincides with a mature version of
development environment. Maintenance
should be applied when project is completed.
Tools must be integrated
to maintain consistency
and tracebility.
Change management
must be automated and
enforced to manage
multiple iterations and to
enable change freedom.
Organizational
infrastructure enable
project environment to be
derived from a common
base of process and tools
Extending automation
support for stakeholder
environment enables
support for paperless
exchange of information.




Round Trip Engineering is the environmental 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
source.
This configuration control of all the technical artifacts
is crucial to maintaining a consistent and error free
representation of evolving product.
Translation of one data source to another may not
provide 100% completeness.
Round trip engineering
Forward Engineering
Reverse Engineering
Design set UML models
Implementation set source code
Requirement set UML models
Deployment set executable code
Change
management is as crucial to
iterative process as planning. Tracking
changes in the technical artifacts is
crucial to understanding the true
technical progress trends and quality
trends towards delivering an acceptable
end product or interim release.
Now change management has become
fundamental to all phases and almost
all activities.



The atomic unit of software work is authorized to
create ,modify, or obsolesce components within a
configuration baseline is called a SCO.
SCO are key mechanism for partitioning, allocating,
and scheduling software work against an established
software baseline and for assessing progress and
quality.
The level at which SCO is written is always an issue.
What is a discrete change?, Is it a change to a
program unit or component?, Is it a new feature?.

Title :-The title is suggested by the originator and is
finalized by the CCB.

Description:-The problem description includes name
of originator, date of origination, CCB assigned SCO
identifier and relevant version identifiers of related
support software.

Metrics:-The metrics collected for each SCO are
important for planning ,scheduling, and for assessing
quality improvement.

Resolution :-This field includes the name of 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

Disposition :-The SCO is assigned one of the
following states by the CCB.
•
•
•
•
•
Proposed
Accepted
Rejected
Archived
In Progress


•
•
A configuration baseline is a named collection
of software components and supporting
documentation that is subject to a change
management and is upgraded, maintained,
tested, statused, and obsolesced as a unit.
There are two classes of baselines
External Product Baseline
Internal Testing Releases

Type 0 :-Critical failures, which are defects that are
nearly always fixed before any external release.




Type 1 :-A bug or defect
Type 2 :-A change that is enhancement rather than a
response to a defect.
Type 3 :-A change that is necessitated by an update to
the requirement.
Type 4 :-Changes that are not accommodated by
other categories, example includes documentation only
or a version upgrade to commercial components.


A CCB is a team of people that functions as the
decision authority on the content of
configuration baseline.
A CCB usually includes the software manager,
software architecture manager, software
development manager, software assessment
manager, and other stakeholders.