Project environment 1) Round trip engineering 2) Change management Infrastructures.

1. Overview of process Automation • Project environment • 1) Round trip engineering • 2) Change management • Infrastructures. • Stakeholder environments.

2. . • Project environment • Prototyping environment • 1) Performance trade-offs and technical risks. • 2) Make/buy trade-offs and feasibility study for commercial products. • 3) Fault tolerance /dynamic reconfiguration trade-offs. • 4) Analysis of the risks • 5) Development of test scenarios, tools. • 2) The Development environment. • 3) The Maintenance environment

3. Change management • Software change orders. • Configuration Baseline. • Configuration Control board • Infrastructures • Organizations policy. • Organizations environment. • Process automation • Meta process. • Macro process. • Micro process.

4. PROCESS AUTOMATION The environment must be a first-class artifact of the process. Process automation, and change management in particular, are critical to an iterative process. If change is too expensive, the development organization will resist it. round-trip engineering and integrated environments promote change freedom and effective evolution of technical artifacts. Metrics automation is crucial to effective project control. Many software development organizations are focused on evolving mature processes to improve the predictability of software management and the performance of their software lines of business (in terms of product quality, time to market, return on investment, and productivity). There are 3 types of processes meta, macro, micro.

5. Process automation Each level of process requires a certain degree of process automation for the corresponding process to be carried out efficiently. Meta process: organization’s policies, procedures, and practices for managing a software-intensive line of business. The automation support for this level is called an infrastructure. Macro process: 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. Micro process: 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.

6. Software change order • Title • Description • Metrics • Resolution • Assessment. • Disposition

7. Title: ______________________________________________________ Description Name:______________________ Date:__________ Project:____________________________________ Metrics Category:_________ (0/1:error, 2:environment, 3:new feature, 4:other Initial estimate Actual Rework Expended Breakage: _________ Analysis:__________ Test:________ Rework:_____________ Implement:_________ Document:__________________ Resolution Analyst:_________________________________________________ Software component:_______________________________________ Assessment Method:_________________ (inspection, analysis, demonstration, test) Tester:________________ Platforms:___________________ Date:_________ Disposition State:_________ Release:___________________ Priority:___________ Acceptance: ___________________________________________ Date:______________ Closure:____________________________ Date:____________

8. SOFTWARE CHANGE ORDERS • The five basic fields of the SCO are title, description, metrics, resolution, assessment, and disposition. • Title. The title is suggested by the originator and is finalized upon acceptance by the configuration control board (CCB). • 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.

9. Metrics. The metrics collected for each SCO are important for planning, for scheduling, and for assessing quality improvement. • Change categories include 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.

10. Resolution. This field includes the name of the person responsible for implementing the change, the components changed, the actual metrics, and the 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: written, pending CCB review, accepted: CCB-approved for resolution, Rejected; closed,resolved with 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.

11. CONFIGURATION BASELINE A configuration baseline is a collection of software components and supporting documentation that is subject to change management and is upgraded, maintained, tested as a unit. There are generally two classes of baselines: 1) External product releases 2) Internal testing releases. Levels of baseline releases 1) Major, 2) Minor, and 3) Interim.

12. A major release represents a new generation of the product or project • Minor release represents the same basic product but with enhanced features, performance, or quality. • An interim release corresponds to a developmental configuration that is intended to be transient.

13. CONFIGURATION CONTROL BOARD (CCB) • A CCB is a team of people that functions as a decision authority on the content of configuration baselines. • A CCB usually includes the software manager, software architecture manager, software development manager, software assessment manager, and other stakeholders. • Sequence of states traversed by an SCO. • Proposed. • Accepted, archived, or rejected. • In progress. • In assessment. • Closed.

14. Tools for automating building blocks • Management. • Environment. • Requirements • Design. • Implementation. • Assessment and Deployment.

15. Typical automation and tool components that support the process workflows Management Workflow automation, metrics automation Environment Change management, document automation Requirements Requirements mgt. Design Visual modeling Implementation Editor-compiler-debugger Assessment Test automation, defect tracking Deployment Defect tracking Process Organization policy Inception Elaboration Construction Transition Life Cycle

16. TOOLS: AUTOMATION BUILDING BLOCKS Each of the process workflows has a distinct need for automation support. In some cases, it is necessary to generate an artifact; in others, it is needed for simple bookkeeping. MANAGEMENT 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. ENVIRONMENT Configuration management and version control are essential in a modern iterative development process. REQUIREMENTS In a modern process, the system requirements are captured in the vision statement.

17. DESIGN 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 then into source code. IMPLEMENTATION The implementation workflow relies primarily on a programming environment but must also include substantial integration with the change management tools, visual modeling tools, and test automation tools to support productive iteration. ASSESSMENT AND DEPLOYMENT To increase change freedom, testing and document production must be mostly automated. Defect tracking is another important tool that supports assessment.

18. INFRASTRUCTURES • From a process automation perspective, the organization’s infrastructure provides the organization’s capital assets, • Two key artifacts: • A policy that captures the standards for software development processes. • Environment that captures the inventory of tools. • ORGANIZATION POLICY • The organization policy 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).

19. 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)

20. There are many different organizational structures throughout the software development industry. Most software intensive companies have three distinct levels of organization, with a different policy at each level: • Highest organization level: standards that promote • strategic and long term process improvements, • general technology insertion and education, • comparability of project and business unit performance • mandatory quality control.

21. Intermediate line-of-business level: standards that promote (1) tactical and short-term process improvement; (2) domain-specific technology insertion and training; (3) reuse of components, processes, training, tools, and personnel experience, (4) compliance with organizational standards. Lowest project level: standards that promote: (1) efficiency in achieving quality, schedule, and cost targets, (2) project-specific training, (3) compliance with customer requirements (4) compliance with organizational business unit standards.

22. ORGANIZATION ENVIRONMENT • Some of the typical components of an organization’s automation building blocks are as follows: • Standardized tool selections 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 or customizations. (architecture description, evaluation criteria) • Activity templates (iteration planning, major milestone activities, configuration control boards)

23. Other indirectly useful components of an organization’s infrastructures: • A reference library of precedent experience for planning, assessing, and improving process performance parameters. • Existing case studies, including objective benchmarks of performance for successful projects that followed the organizational process. • Adjuncts : Something added to another thing but not an essential part of it

24. A library of project artifact examples such as software development plans, architecture descriptions, and status assessments. • Mock audits and compliance traceability for external process assessment frameworks such as SEI CMM.

25. STAKEHOLDER ENVIRONMENTS • External stakeholder representatives also need access to development environment resources so that they can contribute value to the overall effort. • An on-line environment accessible by the external stakeholder 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.

26. Avoid excessive travel, paper interchange delays, format translations, paper and shipping costs, and other overhead costs. • Technical artifacts are not just paper. Electronic artifacts in rigorous notations such as visual models and source code re viewed far more efficiently by using tools with smart browsers. • Even paper documents should be delivered electronically to reduce production costs and turnaround times.