Chapter 11 Project Organizations Responsibilities 22 1 Overview

Chapter 11 - Project Organizations & Responsibilities 22 1

Overview n n Introductory Remarks 11. 1 Line-of-Business organization 11. 2 Project Organizations 11. 3 Evolution of Organization 22 2

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

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. n Project teams are motivated by the cost, Schedule & quality of specific deliverables n 22 4

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 n Responsibility for process automation is an organizational role & is equal in importance to the process definition role n Organizational role may be fulfilled by a single individual or several different teams n 22 5

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

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 7

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 8

Project organizations 22 9

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

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 n Testing the partitioning, replication & allocation strategies in mapping components of the implementation set to physical resources of the deployment system n n Testing against the defined usage scenarios in the user manual Analysis of changes between the current version of deployment set & previous version n n Subjective review of other dimensions of quality 22 11

Life cycle focus on artifacts sets Management Requirements Design Implementation Deployment 22 12

Artifact Evolution over the Life Cycle 22 13

Artifact Evolution over the Life Cycle 22 14

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 n n The test artifacts are communicated, engineered & developed within the same artifacts Sets as the developed product n The test artifacts are implemented as software programs n 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 n 22 15

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

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

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 22 18

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 22 19

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 n n 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 n n Useful documentation is self-defining : it is documentation that gets used n Paper is tangible; electronic artifacts are too easy to change 22 20