Chapter 8 Workflows of the Process

1. Chapter 8 Workflows of the Process Taken from Walker Royce’s textbook – Software Project Management plus a number of Personal Comments

2. Overview • Introductory Remarks • 8.1 Software Process Workflows • 8.2 Iteration Workflows

3. Introductory Remarks • We like sequential activities. • Human nature. KISS technique. • We basically perform activities sequentially • But Teams must operate in parallel. • Requires synchronization, cross-checking, … • Managing these workflows is a primary source of management complexity and leadership. • Times have changed from the old days. • We are required to more in less time with more tools, better support environments, but with very high expectations!

4. Old Way for Tracking Workflow:SequentialActivities • In the past, projects ‘progressed’ via sequential progress through fixed activities. • Successful projects had boundaries not rigid; non-adversarial stakeholders • Unsuccessful projects had rigid boundaries. All activities had to be completed before pressing on… • Much work spent on details (such as completing a manual…) while slighting important development / engineering activities.

5. Gantt Chart Civilian Pay System : System Code: BQ Jan Feb Mar Apr May June July Aug Sep Oct Nov Dec Jan …. Requirements subtasks subtasks …. Design Preliminary Design Detailed design (mgmt level) different granularities Coding Testing document prep. Implementation Travel/ install

6. New Way for Tracking Workflow:State of the Project • We now avoid naming life-cycle phases after the predominant activities. • Now we track the ‘state’ of development within phases (inception, elaboration, construction, transition), recognizing that activities and artifacts evolve and eventually become stable. • We develop incrementally producing executables along way. • Avoiding a discrete set of lock-step activities and cut-off / due dates. • The ‘state’ of a project can be tracked via the minor milestones (end of each iteration). • This is a VERY HARD SALE to management!!!

7. 8.1 Software Process Workflows • We have spoken about fundamental sets of artifacts and the phases in which they are largely produced – recognizing the evolution of these artifacts. (Scan Chapter 6) • We now need to look inside the phases and the iterations – micro-level. • Interestingly, within these boundaries, we will use the term workflow, and talk about a thread of cohesive activities that are mostly sequential. • The Workflows will be mapped to the product artifacts and to the teams… • So, let’s look at high-level workflows.

8. Workflows vs Core Process Disciplines and Core Supporting Disciplines • Recognize that your text is a wee bit dated. • Process Workflows (formerly eight) are now referred to as Core Process Disciplines and Core Supporting Disciplines. • Mapping: • Management (from the Workflows) is now Project Management in Core Supporting Discipline • Environment has moved to a Core Supporting Discipline • Business Modeling was added and is in Core Process Disciplines. • Assessment (in Workflows) is now Test in Core Process Disciplines • Be aware of these mappings in the text that follows.

9. Activity Levels across life cycle phases: Project Management (Core Discipline) • Project Management (formerly Workflow: ‘Management’) • Level of Activities: Has a reasonably constant level of activity. • Artifacts include • Business Case • Software Development Plan (SDP) • Status Assessments • Vision – Business and Product • Work Breakdown structure • Life Cycle Phase Emphasis • Inception – prepare business case and vision (Business case + Vision) • Elaboration – Plan development (map to SDP) • Construction – Monitor and control development (map to Status Assessments) • Transition – Monitor and control deployment

10. Activity Levels across life cycle phases: Environment (Core Supporting Discipline) • Environment – (now in Core Supporting Disciplines_ • Level of Activities: • Reasonably medium level activity in inception; • Quite low in Construction and Transition (should already be well established and operational); • High level of activity in Elaboration, development environment and change management database are obtained, installed and configured for use. • A robust Environment is essential! • Artifacts • Environment Defined (tools, procedures, standards, version / configuration ctl…) • Software Change Order database (Mechanism for Change Control!!!) • Life Cycle Phase Emphasis • Inception – define development environment and change mgmt infrastructure • Elaboration – install development environment; establish change management database • Construction – maintain development environment; maintain software change order database • Transition – Transition to maintenance environment and software change order database.

11. Activity Levels across life cycle phases: Requirements (Core Discipline) • Requirements (retitled: ‘Workflow’ to ‘Core Discipline’) • Level of Activities: • Construction / Transition: Very low level (does not mean NO activity…) • Higher level in Inception, especially toward the end of Inception. In fact, activities of Requirements effort are highest at the end of inception and the start of Elaboration and continuing at a high (but lower) level in Elaboration. • Artifacts: • Requirements set – vision; business rules; risks; statements of work, … • Release Specifications – Plans for dissemination of products/ documentation/ training/ customer support/ follow-on activities…. • Vision Documents – further developed; refined; bought into; shared vision… • Life Cycle Phase Emphasis • Inception – define operational concept • Elaboration – Define architecture objectives (components; distribution, platforms, …) • Construction – Define iteration objectives – high level; purpose; plans • Transition – Transition maintenance environment and software change order database.

12. Activity Levels across life cycle phases: Design (Core Discipline) • Design – (from ‘workflow’ to ‘core discipline’) • Levels of activities – (model the solution and evolving the architecture and design artifacts) • Builds like a symmetrical mountain from inception steadily upward and peaking in Elaboration and gradually diminishing during Construction. • Remember: key architecture done early; remaining items should be done but not as architecturally-significant. • Artifacts • Design set – Models … • Architecture Description – architectural model choices. … • Life Cycle Phase Emphasis • Inception – formulate architecture concept • Elaboration – Achieve architecture baseline • Construction – Design components • Transition – Refine architecture and components.

13. Activity Levels across life cycle phases: Implementation (Core Discipline) • Implementation – (from ‘workflow’ to ‘core discipline.’ • Levels of activities – (Programming the components and evolving the implementation and deployment artifacts) • Inception: Low activity in Inception, • Elaboration: medium activity • Construction: very high activity • Transition: tapering off during Transition but fixes / maintenance resulting from alpha, beta testing... • Artifacts • Implementation set: architectural models; subsystems, packages, programs, modules, etc. etc. • Deployment set – what goes into the release? • Life Cycle Phase Emphasis • Inception – Support architecture prototype • Elaboration – Produce architecture baseline • Construction – Produce complete componentry • Transition – Maintain components

14. Activity Levels across life cycle phases: Assessment (Core Discipline) • Assessment – (from ‘workflow’ to ‘core discipline’ as Test) • Levels of activities – (assessing the trends in process and product quality) • Inception – very low • Elaboration – a little higher, but low • Construction and Transition: very very high in Construction and continuing at this height; gradually becoming a lower level of activity. • Artifacts • Release Specifications • Release Descriptions • User manuals • Deployment Set • Life Cycle Phase Emphasis • Inception – Assess plans, vision, prototypes •  Elaboration – Assess architecture •  Construction – Assess interim releases •  Transition – Assess product releases

15. Activity Levels across life cycle phases: Deployment (Core Discipline) • Deployment – (from ‘workflow’ to ‘core discipline.’ • Levels of activities – (Transitioning the end products to the user) • Inception: Very low level • Elaboration: Medium level • Construction: low during • Transition: pretty high level of activity • Artifacts • Deployment Set • Life Cycle Phase Emphasis • Inception – Analyze user community • Elaboration – Define use manual • Construction – Prepare transition materials •  Transition – Transition product to user • So very much to do; often slighted…

16. Modern Process Framework • These levels of activities and the artifacts produced represent one of the key signatures of a modern process framework and provides a viewpoint from which to discuss four of the key principles discussed earlier. • 1. Architecture-first approach “Extensive requirements analysis, design, implementation, and assessment activities are performed before the construction phase (phase) , when full-scale implementation (core disciplines) is the focus.  This early life-cycle focus on implementing and testing the architecture must precede full-scale development and testing of all the components and must precede the downstream focus on completeness and quality of the entire breadth of the product features.”

17. 2. Iterative life-cycle process. “Each phase portrays at least two iterations of each workflow. This default is intended to be descriptive, not prescriptive. Some projects may require only one iteration in a phase; others may require several iterations. The point is that the activities and artifacts of any given … core discipline may require more than one pass to achieve adequate results.” • 3. Round-trip Engineering “Raising the environment activities to a first-class … Core Supporting Discipline is critical. The environment is the tangible embodiment of the project’s process, methods, and notations for producing the artifacts.” • 4. Demonstration-based Approach Implementation and assessment activities are initiated early in the life cycle, reflecting the emphasis on constructing executable subsets of the evolving architecture.”  Recall, each iteration contains assessment at its conclusion.

18. 8.2 Iteration Workflows • “An iteration consists of a loosely sequential set of activities in various proportions depending on where the iteration is located in the development cycle.” • Contents of an iteration is determined by ‘iteration planning’ based on critical use cases and high risk items – decreasing in priority as we progress across the development cycle. • Based on, therefore, these use cases. Remember, the RUP is use-case driven. • Those artifacts necessary to support the implementation of these use cases / scenarios are developed, assessed, and integrated into the evolving system.

19. Iteration Contents – by Core Discipline • Project Management is concerned with the content of the iterations, assigning work, and the contents of anticipated releases. • Environment is concerned primarily with maintaining the software change database – tracking, prioritizing, addressing any changes that arise. • Really much more than this. All of our tools, standards, procedures are part of this.

20. Iteration Contents – by Core Discipline • Requirements: is concerned with looking carefully at the  baseline plan, architecture, and requirement set artifacts needed to fully expand the use cases that need to be demonstrated at the end of this iteration – as well as their evaluation criteria. • Design – is concerned with developing the design model and test model by evolving the baseline architecture and design set artifacts against the evaluation criteria for a specific iteration; Also need to update the design set artifacts in response to the activities within this iteration. • Implementation: addresses either developing (from scratch), customizing, or acquiring (purchase, reuse) new components and to test and integrate these components into to current architectural baseline.

21. Iteration Contents – by Core Discipline • Assessment: concerned with evaluating the results of each iteration to insure compliance with evaluation criteria and to identify rework needed before deployment of this release or allocated to the next iteration; • also, assess the results for this iteration so as to improve the next iteration’s procedure. • Deployment: concerned with transmitting the release either internally or to an external organization for exercise.

22. Remarks • Many activities occur at the same time. Recall the model of the RUP: requirements are not all done at a single setting; rather, design, implementation, test, etc. all occur to a greater or lesser degree EACH iteration depending on which iteration we’re in. • Early iterations in Inception and Elaboration focus on project management, requirements, and design – and assessment activities. • Iterations in Construction, focus on design, implementation, and assessment. • In Transition focus on assessment and deployment. • See figure 8.3 on focuses during specific phases.

23. Iteration Contents – Final Remarks – (1 of 2) • Essential to realize that while each of the core disciplines has their individual activities that are reflected in ‘levels’ of activities within any/all iterations, ALL iterations include continuous assessment of risk, controlling the baselines of each artifact, and assessing/archiving the demonstrated results that illustrate: • Understanding of requirements • Satisfying design features and performance, and • Consistently reviewing the plan for any changes that may occur.

24. Iteration Contents – Final Remarks (2 of 2) • In practice, the contents of sequences if activities in an iteration and the overlap between iterations is not terribly crisp. • Note: an iteration represents the state of the overall architecture and the complete deliverable system. An increment represents the current work in progress that will be combined with the preceding iteration to form the next iteration. • Study figure 8.4 carefully. Note that when an increment is completed, it corresponds to the end of an iteration also. Converse is not true.