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

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.

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 ORGANIZATION MANAGER SE PROCESS AUTHORITY PROJECT REVIEW AUTHORITY

Process Definition Process Improvement

SE ENVIRONMENT AUTHORITY

Project Compliance Periodic risk assessment

INFRASTRUCTURE

Process Automation

Project administration Engg. Skill centers Professional development

PRJ. A Manager

PRJ. B Manager PRJ. C Manager

PRJ. N Manager

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.

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.

DEFAULT PROJECT ORGANIZATION AND RESPONSIBILITIES Software Management

Artifacts: Business Case Software Development Plan Status assessments Activities: Customer interface, PRA interface, planning, progress monitoring, RM, S/W process Def., Process Improvement

Systems Engineering
Artifacts: Vision statement, Requirements Set Activities: Requirements Elicitation, Requirements Specification, Use case Modeling

Administration
Artifacts: WBS Activities: Financial forecasting, reporting, WBS definition, administration.

S/W Architecture
Artifacts: Architecture description, Release specification, Design Set

S/W Development
Artifacts: Design set, Implementation Set, Requirements Set, Deployment Set Activities: component design, component implementation, component testing, component maintenance

S/W Assessment
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 ..

Activities: Demonstration planning, Analysis, design, architecture prototyping, architecture documentation, demonstration coordination, component design, make/ buy/ reuse analysis

SOFTWARE MANAGEMENT TEAM ACTIVITIES Software Management Systems Engineering Financial Administration Artifacts: Business case, Vision, WBS, Status Assessments, Requirements Set Quality Assurance (QA) Responsibilities: Resource commitments, Personnel assignments, Plans, Priorities, Stakeholder satisfaction, Scope Definition, Risk Management, Project Control. Construction
Transition Phase Planning, Construction Plan Organization, Risk Management

Inception
Elaboration phase planning, Team formulation, contract baselining, Architecture costs

Elaboration
Construction phase planning, Risk resolution, Product Acceptance Criteria, Construction costs

Transition
Customer satisfaction, Contract closure, Sales Support, Next generation planning

SOFTWARE ARCHITECTURE TEAM ACTIVITIES Software Architecture Demonstrations Use Case Modelers Performance Analysis Artifacts: Architecture description, Requirements Set, Design Set, Release specifications Inception
Architecture prototyping, Make/Buy trade-offs, Primary scenario definition, Architecture evaluation criteria definition

Design Modelers Responsibilities: Requirements trade-offs, Design trade-offs, Component selection, Initial Integration, Technical risk resolution Construction
Architecture Maintenance, Multiple-component issue resolution, performance tuning, quality improvements

Elaboration
Architecture baselining, Primary Scenario demonstration, Make/Buy trade-off base lining

Transition
Architecture maintenance, Multiple component Issue resolution, performance tuning, quality improvements

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 Construction
Component Design, Component Implementation, Component stand alone test, component maintenance

Inception
Prototyping Support

Elaboration
Critical Component Design, Critical Component Implementation Set, Critical Component Baseline

Transition
Component maintenance, component documentation

Make/Buy trade-offs

SOFTWARE ASSESMENT TEAM ACTIVITIES Software Assessment Release Testing Change Management Deployment Artifacts: Deployment Set, SCO DB, Environment, Release Specs., Release Description, Deployment Documents Inception
Infrastructure planning, Primary Scenario Prototyping

Environment Support Responsibilities: Project Infrastructure, Independent Testing, Requirements verification, Metrics Analysis, Configuration Control, Change Management, User Deployment Construction
Infrastructure upgrades, Release testing, Change management, User Manual baseline, Requirements Verification

Elaboration
Infrastructure baseline, architecture release testing, change management, initial user manual

Transition
Infrastructure Maintenance, release baselining, change Mgt., Deployment to users, Requirements verification

SOFTWARE PROJECT TEAM EVOLUTION OVER THE LIFECYCLE

SM 50% SM 10%

SA 20%

SD 20%

SAss 10%

SA 50%

SD 20%

SAss 20%

INCEPTION TRANSITION
SM 10%

ELABORATION CONSTRUCTION
SM 10%

SA 5%

SD 35%

SAss 50%

SA 10%

SD 50%

SAss 30%

SM Software Management, SD Software Development

SA Software Architecture Sass Software Assessment