Chapter 11- Project Organizations & Responsibilities

1. Chapter 11- Project Organizations & Responsibilities 22

2. Overview • Introductory Remarks • 11.1 Line-of-Business organization • 11.2 Project Organizations • 11.3 Evolution of Organization 22

3. Introductory Remarks • Organizations engaged in a software Line-of- Business need to support projects with the infrastructure necessary to use a common process • Project organizations need to allocate artifacts & responsibilities across project team to ensure a balance of global( architecture ) & local (component ) concerns • The organization must evolve with the WBS & Life cycle concerns 22

4. Introductory Remarks Software lines of business & product teams have different motivation • Software lines of business are motivated by return of investment (ROI), new business discriminators, market diversification & profitability. • Project teams are motivated by thecost, Schedule & quality of specific deliverables 22

5. Line-Of-Business Organizations The main features of default organization are as follows • Responsibility for process definition & maintenance is specific to a cohesive line of business • Responsibility for process automation is an organizational role & is equal in importance to the process definition role • Organizational role may be fulfilled by a single individual or several different teams 22

6. Default roles in a Software Line-of-Business Organization Organization Manager Project review Authority Software Engineering Process Authority • Project Compliance • Periodic risk assessment • Process Definition • Process Improvement Infrastructure Software Engineering Environment Authority • Process Automation • Project Administration • Engineering skill centers • Professional development Project A Manager Project B Manager Project C Manager Project D Manager Project N Manager 22

7. Line-of-Business Software Engineering Process Authority ( SEPA ) The SEPA facilities the exchange of information & process guidance both to & from project practitioners This role is accountable to General Manager for maintaining a current assessment of the organization’s process maturity & its plan for future improvement Project Review Authority The PRA is the single individual responsible for ensuring that a software project complies with all organizational & business unit software policies , practices & standards A software Project Manager is responsible for meeting the requirements of a contract or some other project compliance standard 22

8. Line-of-Business Software Engineering Environment Authority ( SEEA ) The SEEA is responsible for automating the organization’s process, Maintaining the organization’s standard environment, Training projects to use the environment & maintaining organization-wide reusable assets The SEEA role is necessary to achieve a significant ROI for common process. Infrastructure An organization’s infrastructure provides human resources support, project-independent research & development, & other capital software engineering assets. 22

9. Project organizations 22

10. The Engineering Set ( 4 of 5 ) Implementation sets are evaluated, assessed & measured through a combination of the following • Analysis of consistency with the design models • Translation into deployment set notations to evaluate the consistency & completeness among artifact sets • Analysis of changes between the current version of implementation set & previous version • Subjective review of other dimensions of quality 22

11. The Engineering Set ( 5 of 5 ) Deployment sets are evaluated, assessed & measured through a combination of the following • Testing against the usage scenarios & quality attributes defined in the requirement set to evaluate the consistency & completeness • Testing the partitioning, replication & allocation strategies in mapping components of the implementation set to physical resources of the deployment system • Testing against the defined usage scenarios in the user manual • Analysis of changes between the current version of deployment set & previous version • Subjective review of other dimensions of quality 22

12. Life cycle focus on artifacts sets inception Elaboration Construction Transition Management Requirements Design Implementation Deployment 22

13. Artifact Evolution over the Life Cycle Engineering Stage Inception Elaboration Inception Inception Elaboration Inception Elaboration Construction Deployment Construction Depolyment Management Management Management 22

14. Artifact Evolution over the Life Cycle Production Stage Construction Transistion Inception Inception Elaboration Construction Inception Elaboration Construction Deployment Depolyment Management Management Management 22

15. Test Artifacts Conventional software testing followed same document driven approach that was applied To software development. Development team & testing team prepare their required procedures in the form of document driven which lead to many problems In the modern process exactly same sets,notations & artifacts are used both for Testing & production activities. This forced several engineering disciplines into the process • The testing artifacts must be developed concurrently with the product from inception through deployment • The test artifacts are communicated, engineered & developed within the same artifacts Sets as the developed product • The test artifacts are implemented as software programs • Testing artifacts are documented similar to product is documented • Developers of test artifacts use the same tools, techniques & training as the software engineers developing the products 22

16. Management Artifacts All the Management artifacts are studied in detail • Business case • Software development plan • Work Breakdown structure • Software change order database • Release specifications • Release descriptions • Status Assessment • Environment • Deployment 22

17. Engineering Artifacts Related Engineering Artifacts are explained for • Vision Document • Architecture Description • Software User Manual 22

18. Artifacts sequences across a typical life cycle Informal version Controlled baseline Management set 1.Work breakdown structure 2. Business case 3. Release Specifications 4. Software Development Plan 5.Release Description 6. Status Assessment 7. Software change order data 8. Deployment document 9. Environment Elaboration Construction Deployment Inception iteration1 iteration2 iteration3 iteration4 iteration5 iteration6 iteration7 22

19. Artifacts sequences across a typical life cycle Informal version Controlled baseline Requirement set 1.Vision Document 2. Requirement Model(s) Design set 1 Design Model(s) 2 Test Model 3 Architecture description Implementation set 1. Source code baselines 2. Associated compile-time files 3. Component executables Deployment set 1. Integrated product-executable baselines 2. Associated run-time files 3. User Manual Elaboration Construction Deployment Inception iteration1 iteration2 iteration3 iteration4 iteration5 iteration6 iteration7 22

20. Pragmatic Artifacts Conventional document driven approach is changed to more effective Approach which redirect this documentation effort to improving the rigor & Understandability of information source & allowing on-line review of native Information source by using smart browsing & navigation tools This philosophy raises the following cultural issues • People want to review information but don’t understand the language of the artifacts • People want to review the information but don’t have access to the tools • Human-readable engineering artifacts should use rigorous notations that are complete,consistent & used in a self-documenting manner • Useful documentation is self-defining : it is documentation that gets used • Paper is tangible;electronic artifacts are too easy to change 22