1. An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational structure refers to the way that an organization arranges people and jobs so that its work can be performed and its goals can be met Line of bussiness A particular kind of product or merchandise A particular kind of commercial enterprise Merchandise Commodities offered for sale

2. PROJECT ORGANIZATIONS AND RESPONSIBILITIES Organizational structures form the architecture of the team. Organizations engaged in a software line of business need to support projects with the infrastructure necessary to use a common process. Software lines of business are motivated by ROI, new business discriminators, market diversification, and profitability. Project teams are motivated by the cost, schedule, and quality of specific deliverables. Software professionals in both types of organizations are motivated by career growth, job satisfaction, and the opportunity to make a difference. This chapter recommends and describes organizations for a line of business and for a project.

3. Prescribing organizational hierarchies is clearly a dangerous undertaking in the context of specific organizations and people. Here, generic roles, relationships, and responsibilities are discussed. LINE-OF-BUSINESS ORGANIZATIONS PRJ. A ManagerPRJ. B Manager PRJ. C Manager ……. PRJ. N Manager Process Definition Process Improvement Project Compliance Periodic risk assessment Process Automation Project administration Engg. Skill centers Professional development SE PROCESS AUTHORITY ORGANIZATION MANAGER PROJECT REVIEW AUTHORITY SE ENVIRONMENT AUTHORITY INFRASTRUCTURE

4. The Software Engineering Process Authority facilitates the exchange of information and process guidance both to and from project practitioners. The Project Review Authority is the single individual responsible for ensuring that a software project complies with all organizational and business unit software policies, standards, and practices. The software engineering Environment Authority is responsible for automating the organizations process, maintaining the organizations standard environment, training projects to use the environment, and maintaining organization-wide reusable assets. An organizations Infrastructure provides human resources support, project-independent research and development, and other capital SE assets.

5. The main features of the default organization are as follows: Responsibility for process definition and maintenance is specific to a cohesive line of business, where process commonality makes sense. Responsibility for process automation is an organizational role and is equal in importance to the process definition role. Organizational roles may be fulfilled by a single individual or several different teams, depending on the scale of the project. Management team  active participants, producing and managing Architecture team  real artifacts and integration of components Development team  component construction and maintenance activities Quality team (Assessment team)  responsible for different quality perspective.

7. DEFAULT PROJECT ORGANIZATION AND RESPONSIBILITIES Artifacts: Business Case Software Development Plan Status assessments Activities: Customer interface, PRA interface, planning, progress monitoring, RM, S/W process Def., Process Improvement Artifacts: Vision statement, Requirements Set Activities: Requirements Elicitation, Requirements Specification, Use case Modeling Artifacts: WBS Activities: Financial forecasting, reporting, WBS definition, administration. Artifacts: Architecture description, Release specification, Design Set Activities: Demonstration planning, Analysis, design, architecture prototyping, architecture documentation, demonstration coordination, component design, make/ buy/ reuse analysis Artifacts: Design set, Implementation Set, Requirements Set, Deployment Set Activities: component design, component implementation, component testing, component maintenance Artifacts: Deployment set, SCO database, User Manual, Release Descriptions, Environment, Deployment documents Activities: Release assessment, use case testing, test scenario development, change Mgt., transition to use, system Admn., Env. Configuration ….. Software Management Systems Engineering Administration S/W ArchitectureS/W DevelopmentS/W Assessment

8. SOFTWARE MANAGEMENT TEAM ACTIVITIES Software Management Systems Engineering Financial Administration Quality Assurance (QA) Artifacts: Business case, Vision, WBS, Status Assessments, Requirements Set Responsibilities: Resource commitments, Personnel assignments, Plans, Priorities, Stakeholder satisfaction, Scope Definition, Risk Management, Project Control. InceptionElaborationConstructionTransition Elaboration phase planning, Team formulation, contract baselining, Architecture costs Construction phase planning, Risk resolution, Product Acceptance Criteria, Construction costs Transition Phase Planning, Construction Plan Organization, Risk Management Customer satisfaction, Contract closure, Sales Support, Next generation planning

9. SOFTWARE ARCHITECTURE TEAM ACTIVITIES Software Architecture Demonstrations Use Case Modelers Design Modelers Artifacts: Architecture description, Requirements Set, Design Set, Release specifications Responsibilities: Requirements trade-offs, Design trade-offs, Component selection, Initial Integration, Technical risk resolution InceptionElaborationConstructionTransition Architecture prototyping, Make/Buy trade-offs, Primary scenario definition, Architecture evaluation criteria definition Architecture baselining, Primary Scenario demonstration, Make/Buy trade-off base lining Architecture Maintenance, Multiple-component issue resolution, performance tuning, quality improvements Architecture maintenance, Multiple component Issue resolution, performance tuning, quality improvements Performance Analysis

10. SOFTWARE DEVELOPMENT TEAM ACTIVITIES Software Development Component Teams Artifacts: Design Set, Implementation Set, Deployment Set Responsibilities: Component Design, Component Implementation, Component Stand-Alone test, Component Maintenance, Component Documentation InceptionElaborationConstructionTransition Prototyping Support Make/Buy trade-offs Critical Component Design, Critical Component Implementation Set, Critical Component Baseline Component Design, Component Implementation, Component stand alone test, component maintenance Component maintenance, component documentation

11. SOFTWARE ASSESMENT TEAM ACTIVITIES Software Assessment Release Testing Change Management Environment Support Artifacts: Deployment Set, SCO DB, Environment, Release Specs., Release Description, Deployment Documents Responsibilities: Project Infrastructure, Independent Testing, Requirements verification, Metrics Analysis, Configuration Control, Change Management, User Deployment InceptionElaborationConstructionTransition Infrastructure planning, Primary Scenario Prototyping Infrastructure baseline, architecture release testing, change management, initial user manual Infrastructure upgrades, Release testing, Change management, User Manual baseline, Requirements Verification Infrastructure Maintenance, release baselining, change Mgt., Deployment to users, Requirements verification Deployment

12. SOFTWARE PROJECT TEAM EVOLUTION OVER THE LIFECYCLE INCEPTIONELABORATION TRANSITIONCONSTRUCTION SM 50% SA 20%SD 20%SAss 10% SM 10% SA 50%SD 20%SAss 20% SM 10% SA 5%SD 35%SAss 50% SM 10% SA 10%SD 50%SAss 30% SM – Software Management, SA – Software Architecture SD – Software Development Sass – Software Assessment