Chapter 14- tailoring the process

1. Chapter 14- tailoring the process

2. Overview • Introductory Remarks • 14.1 Process Discriminants 14.1.1 Scale 14.1.2 Stakeholder cohesion or contention 14.1.3 Process Flexibility or rigor 14.1.4 Process Maturity 14.1.5 Architectural Risk 14.1.6 Domain Experience 14.2 Example: Small Scale Vs Large Scale project

3. Introductory Remarks • The process framework must be configured to the specific characteristics of the project • The Scale of the project (Team size ) drives the process configuration more than any other factor • Other key factors include Stakeholder relationship, Process flexibility, Process maturity, Architectural risk & domain experience. • While specific process implementations will vary but the spirit underlying the process is the same

4. Process Discriminants In tailoring the management process to a specific domain or project there are two dimensions of discrimination factors • Technical Complexity • Management complexity

5. Higher technical Complexity • Embedded,real-time,Distributed, Fault-Tolerant • High-performance,Portable • Unprecedented, architecture re-engineering Average software Project 5 to 10 people 10 to 12 Months 3 to 5 external interfaces Some unknown riks • Higher management Complexity • Large scale • Contractual • Many stakeholders • Projects • Lower management Complexity • Smaller scale • Informal • Few stakeholders • Products • Lower technical Complexity • Straightforward automation, Single thread • Interactive performance, Single platform • Many precedent system, application re-engineering The two primary dimensions of process variability

6. Higher technical Complexity • More domain experience required • Longer inception & elaboration phase • More iterations for risk management • Less predictable costs & schedules • Higher management Complexity • More emphasis on risk management • More process formality • More emphasis on teamwork • Longer Inception & elaboration phases • Lower management Complexity • Less emphasis on risk management • Less process formality • More emphasis on individual skills • Longer production & transition phases • Lower technical Complexity • More Emphasis on existing assets • Shorter inception & elaboration phase • fewer iterations for risk management • More predictable costs & schedules Priorities for tailoring the process framework

7. Process Discriminants A Project framework is not a project-specific process implementation with a well-defined recipe for success Methods, techniques, culture, formality & organization must be tailored to the specific domain to achieve a process implementation that can be succeed. All the six parameters that effect the process exponent should be considered when tailoring a process framework th create a practical process implementation. The six parameters are • Scale • Stakeholder cohesion or contention • Process flexibility or rigor • Process maturity • Architectural risk • Domain experience

8. Process Discriminants I Scale The single most important factor in tailoring a software process framework to the specific needs of a project is total scale of the software application The scale factor can be measured by • Source lines of code( SLOC ) • Number of function points • Number of use cases • Number of dollars From a process tailoring perspective the primary measure of the scale is the size of the team. As the headcount increases the importance of consistent interpersonal communication becomes paramount

9. Process Discriminants I Scale Projects are categorized into • Trivial-sized projects( 1 people )requires almost no management overhead • Small projects ( 5 people )require very little management overhead but team leadership toward a common objective is crucial • Moderate-sized projects( 25 people )require moderate management overhead • Large projects( 125 people ) require substantial management overhead • Huge projects( 625 people )require management overhead

10. Process Primitive Smaller Team Larger Team Life cycle phases Weak boundaries between Well-defined phases transitions to phases synchronize progress among concurrent Activities Artifacts Focus on technical artifacts Change management of technical Few discrete baselines artifacts which may result in Very few management numerous baselines artifacts required Management artifacts important Work effort More need for generalists, Higher percentage of specialists allocations people who performs roles More people & teams focused on in multiple workflows a specific workflow Checkpoints Many informal events for A few formal events maintaining technical Synchronization among teams consistency which can take days No schedule description Management Informal planning, project Formal planning, project control, discipline control, & organization & organization Automation Most ad-hoc environment, Infrastructure to ensure consistent discipline managed by individuals Additional tool integration to support project control & change control

11. Process Discriminants II Stakeholder contention & contention The degree of cooperation & coordination among stakeholders can significantly drive the specifics of how a process is defined This process parameter can range from cohesive to adversarial Cohesive teams have common goals, complementary skills & close communications Adversarial teams have conflicting goals, competing of incomplete skills & less-than-open communications

12. Process PrimitiveFew Stakeholders,Multiple Stakeholders, Cohesive Teams Adversarial Teams Life cycle phases Weak boundaries between Well-defined phases transitions to phases synchronize progress among concurrent Activities Artifacts Fewer & less detailed Management artifacts paramount, management artifacts especially the business case, required Vision & status assessment Work effort Less overhead in High assessment overhead to ensure allocations assessment stakeholder concurrence Checkpoints Many informal events 3 or 4 formal events Many informal technical walkthroughs Synchronization among stakeholder teams Management Informal planning,project Formal planning, project control, discipline control, & organization & organization Automation ( insignificant ) on-line stakeholder environment discipline necessary

13. Process Discriminants III Process flexibility or rigor The degree of rigor formality & change freedom inherent in a specific project’s contract will have a substantial impact on the implementation of the project’s process. For a loose contracts such as building a commercial product within a business unit of a software company, management complexity will be minimal On the other hand, for a very rigorous contract it could take months to authorize a change in a release schedule

14. Process Primitive Flexible Process Inflexible process Life cycle phases Tolerant of cavalier phase More credible basis required for communications inception phase commitments Artifacts Changeable business case Carefully controlled changes & vision to business case & vision Work effort ( insignificant ) increased levels of management allocations & assessment workflow Checkpoints Many informal events for 3 or 4 formal events maintaining technical Synchronization among stakeholder consistency teams Management ( insignificant) More fidelity required for planning discipline & project control Automation ( insignificant) ( insignificant) discipline Process discriminators that result from differences in process flexibility

15. Process Discriminants IV Process maturity The process maturity level of the development organization is another key driver of management complexity. Managing a mature process ( level 3 or higher ) is far simpler than managing an immature process( level1 & 2). Organizations with a mature process typically have a high level of precedent experience in developing software & high level existing process collateral that enables predictable planning & execution of the process

16. Process Primitive Mature level 3 or 4 Level 1 Organization Life cycle phases Well-establish criteria for ( insignificant) phase transition Artifacts Well-establish format, Free-form content & production methods Work effort Well-establish basis No basis allocations Checkpoints Well-defined combination ( insignificant) of formal & informal events Management Predictable planning Informal planning & project discipline Objective status control Automation Requires high levels of discipline automation for round-trip Little automation or disconnect engineering, change islands of automation management & process instrumentation Process discriminators that result from differences in process maturity

17. Process Discriminants V. Architectural Risk The degree of technical feasibility demonstrated before commitment to full-scale-production is an important dimension of defining a specific project’s process There are many sources of architecture risk such as • System performance • Robustness • System reliability The degree to which these risks can be eliminated before construction begins can have dramatic ramifications in the process tailoring

18. Process Primitive Complete Architecture No architecture Feasibility Feasibility demonstration demonstration Life cycle phases More inception & elaboration Fewer early iterations phase iteration More construction iterations Artifacts Earlier breadth & depth( insignificant ) across technical artifacts Work effort Higher level of design effort Higher levels of implement- allocations Lower levels of ation to deal with increased implementation & assessment scrap & rework Checkpoints More emphasis on executable More emphasis on briefings, demonstration documents & simulation Management ( insignificant ) ( insignificant ) discipline Automation More environment resources Less environment demand discipline required earlier in the life cycle early in the life cycle Process discriminators that result from differences in architecture risk

19. Process Discriminants VI. Domain Experience The development organization’s domain experience governs its ability to converge on an acceptable architecture in a minimum number of iterations. Generally a skilled software organization building it’s first radar application may require 4 or 5 prototype releases before converging on an adequate baseline.

20. Process Primitive Experienced Team Inexperienced tean Life cycle phases shorter engineering stage Longer engineering stage Artifacts Less scrap & rework in More scrap & rework in requirement & design sets requirement & design sets Work effort Lower levels of requirement Higher levels of requirement allocations & design & design Checkpoints ( insignificant ) ( insignificant ) Management Less emphasis on risk More-frequent status assess- discipline management ment required Less frequent status assessments needed Automation ( insignificant ) ( insignificant ) discipline Process discriminators that result from differences in domain experience

21. Small scale Vs large-scale project Engineering Production Domain Inception Elaboration Construction Transition Small 10% 20% 50% 20% Commercial Project Large,Complex 15% 30% 40% 15% project

22. Small scale Vs large-scale project • Differences in workflow priorities between small & large projects • Rank Small commercial project Large, complex project • Design Management • Implementation Design • Deployment Requirements • Requirements Assessment • Assessment Environment • Management Implementation • Environment Deployment

23. Artifacts Small Commercial project Large,Complex project Work breakdown 1-page spreadsheet with 2 Financial management system with structure levels of WBS elements 5 or 6 levels of WBS elements Business case Spreadsheet & short memo 3-volume proposal including technical volume, cost volume, & related experience Vision statement 10-page concept paper 200-page subsystem specification Development plan 10-page plan 200-page development plan Release specification 3 interim release 8 to 10 interim release & No of release specification specification Architecture 5 critical use case, 50 UML 25 critical use case,200 UML description diagram, 20 pages of text, diagrams,100 pages of text, other graphics other graphics Software 50,000 lines of VB code 300,000 lines of C++ code Release description 10-page release notes 100-page summary Deployment use training course Transition plan sales rollout kit Installation plan User manual On-line help & 100-page 200-page user manual user manual Status Assessment Quarterly project reviews Monthly project management reviews Difference in artifacts between small & large projects