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.