1 / 22

Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16

Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16. Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book). Software Management Renaissance The conventional software management process. Five improvements to make the waterfall process work.

dara-lamb
Download Presentation

Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Thirteenth Lecture Hour8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)

  2. Software Management Renaissance The conventional software management process. Five improvements to make the waterfall process work. A Software Management Process Framework Phases Artifacts Workflows Checkpoints Software Management Disciplines Planning Organization Automation Process control and instrumentation Tailoring Looking Ahead Modern project profiles Next-generation software economics Modern process transitions Review –The Four Parts of the Course

  3. Topics for Today • Automation building blocks • The project environment • Round-trip engineering • Change management • Infrastructures • Stakeholder environments

  4. Levels of Automation • Meta-process • Organization’s policies, procedures, and practices for the line of business • Inventory of preferred tools, artifact templates, guidelines, project repositories, skill sets, library. • Macro-process • Project’s policies, procedures, practices, project environment and collection of tools to produce artifacts. • Micro-process • Project team’s policies, etc., for achieving an artifact. Tools.

  5. Automation and Tools

  6. Management Project planning and control, on-line status assessments. Environment Configuration management and change control Requirements Integrate documents and visual representations for specifications and use cases. Design Visual modeling Implementation Integration of programming environment with change management tools, visual modeling tools, and test automation tools. Assessment and deployment Test automation, test management, and defect tracking tools. Workflow Tools

  7. The Prototype Environment Architecture testbed Performance trade-offs Technical risk analysis Make/buy tradeoffs Fault tolerance trades Transitioning risks Test scenarios The Development Environment Development tools Round-trip engineering tools The Maintenance Environment Mature version of the development environment The Three Project Environments

  8. Four Important Environment Disciplines • Integration of tools to support round-trip engineering for iterative development. • Change management automation to manage multiple iterations AND change freedom. • Infrastructure to enable environments derived from a common base. • Promotes inter-project consistency, reuse of training, and reuse of lessons learned. • Stakeholder environment extensions • Provides cost savings for information exchange and approvals for engineering artifacts.

  9. Round-trip Engineering • Primary reason: allow freedom in changing software engineering data sources. • New needs for automation: • Heterogeneous components, platforms, languages, complexity of building, controlling and maintaining large-scale webs of components.

  10. Round-trip Engineering

  11. Change Management • Change management is more critical in modern processes. • Artifacts are begun early, use rigor, and evolve over time. • Software Change Orders (SCO) are used to create, modify, or obsolesce components. • Change Orders are used to track status and performance.

  12. Software Change Order

  13. Configuration Control • Configuration Control Board • Manages releases • Makes change decisions • Membership • Software manager(s), system engineer (sometimes), key software architect (sometimes), customer representatives. • General comment • It’s never dull! Can be the most fun and exciting software management job of all.

  14. Release History

  15. Representative Changes

  16. Organizational Policy Process definition – major milestones, intermediate artifacts, engineering repositories, metrics, roles and responsibilities. What gets done, when does it get done, who does it, how do we know that it is adequate (checkpoints, metrics and standards of performance. Three Levels Highest: long-term process improvement, general technology, education, mandatory quality control. Intermediate: domain-specific technology, reuse of components, processes, training, tools, and personnel. Lowest: efficiency items, project-specific training, compliance with customer requirements and business unit standards. Infrastructure

  17. Organization Environment • Provides answers as to how things get done. • Provide tools and techniques to automate the process. • Standardized tool selections. • Standard notations for artifacts. • Tool adjuncts such as artifact templates (architecture description, evaluation criteria, release descriptions, status assessments • Activity templates (iteration planning, major milestones, configuration control boards.

  18. Organization Environment (cont’d) • Additional components • Reference library for planning, etc. • Existing case studies • Project artifacts library • Audit and compliance traceability frameworks.

  19. Stakeholder Environment • Stakeholders will participate. • Participation should be constructive and value-added to the development. • On-line extension to stakeholder environment enables hands-on evaluations, use of same tools to manage and monitor the project, and minimizes customer travel and paper exchanges.

  20. Extension to Stakeholder Domain

  21. Extension Issues • How much access freedom is supported? • Who pays for the environment and tool investments. • How secure is the information exchange. • How is change management synchronized. • How to avoid abuse by customer. • How to avoid disruption to the development.

  22. Assignment for Next Class Meeting • Read Chapter 12 of Royce’ book, on process automation. • Learn and discuss the types of automation tools which should be used. • Learn and discuss the elements of organization policy. • Learn and discuss the elements of organization environment. • Learn and discuss the pros and cons of extension to the stakeholder environment.

More Related