Project Organizations

Figure 11-2 shows a default project organization and maps project-level roles and responsibilities. This structure can be tailored to the size and circumstances of the specific project organization.

Program Management Structure

Artifacts

• Architecture description

• Release specifications

Activities

• Demonstration planning

• Analysis, design

• Architecture prototyping

• Architecture documentation

• Demonstration coordination

• Component design

• Make/buy/reuse analysis

Artifacts

• Implementation set

• Requirements set

• Deployment set

Activities

• Component design

• Component implementation

• Component testing

• Component maintenance

Artifacts

• Deployment set

• Release descriptions

• Environment

• Deployment documents

Activities

• Release assessment

• Use case/scenario testing

• Test scenario development

• Change management

• Transition to user

• System administration

• Environment configuration

• Environment maintenance

• Toolsmithing

Figure 11-2. Default project organization and responsibilities

The main features of the default organization are as follows:

• The project management team is an active participant, responsible for producing as well as managing. Project management is not a spectator sport.

• The architecture team is responsible for real artifacts and for the integration of components, not just for staff functions.

• The development team owns the component construction and maintenance activities. The assessment team is separate from development. This structure fosters an independent quality perspective and focuses a team on testing and product evaluation activities concurrent with on-going development.

• Quality is everyone's job, integrated into all activities and checkpoints. Each team takes responsibility for a different quality perspective.

Software Management Team

Most projects are overconstrained. Schedules, costs, functionality, and quality expectations are highly interrelated and require continuous negotiation among multiple stakeholders who have differing goals. The software management team carries the burden of delivering win conditions to all stakeholders. In this regard, the software project manager spends every day worrying about balance. Figure 11-3 shows the focus of software management team activities over the project life cycle.

The software management team is responsible for planning the effort, conducting the plan, and adapting the plan to changes in the understanding of the requirements or the design. Toward this end, the team takes ownership of resource management and

Software Management

Systems engineering Responsibilities

Financial administration . Resource commitments Quality assurance . Personnel assignments

• Plans, priorities

• Stakeholder satisfaction

• Scope definition

• Risk management

• Project control

Life-Cycle Focus

Inception

Elaboration

Construction

Transition

Elaboration phase planning Team formulation Contract baselining Architecture costs

Construction phase planning Full staff recruitment Risk resolution Product acceptance criteria Construction costs

Transition phase planning Construction plan optimization Risk management

Customer satisfaction Contract closure Sales support Next-generation planning

Artifacts

• Business case

• Software development plan

Work breakdown structure

• Status assessments

• Requirements set project scope, and sets operational priorities across the project life cycle. At an abstract level, these activities correspond to managing the expectations of all stakeholders throughout the project life cycle.

The software management team takes ownership of all aspects of quality. In particular, it is responsible for attaining and maintaining a balance among these aspects so that the overall solution is adequate for all stakeholders and optimal for as many of them as possible.

Software Architecture Team

The software architecture team is responsible for the architecture. This responsibility encompasses the engineering necessary to specify a complete bill of materials for the software and the engineering necessary to make significant make/buy trade-offs so that all custom components are elaborated to the extent that construction/assembly costs are highly predictable. Figure 11-4 shows the focus of software architecture team activities over the project life cycle.

For any project, the skill of the software architecture team is crucial. It provides the framework for facilitating team communications, for achieving system-wide qualities, and for implementing the applications. With a good architecture team, an average development team can succeed. If the architecture is weak, even an expert development team of superstar programmers will probably not succeed.

In most projects, the inception and elaboration phases will be dominated by two distinct teams: the software management team and the software architecture team. (Even this distinction may be blurred, depending on scale.) The software development and software assessment teams tend to engage in support roles while preparing for the

Artifacts

• Architecture description

• Requirements set

• Release specifications

Software Architecture

— Demonstrations

— Use case modelers

— Design modelers Performance analysts

Life-Cycle Focus

Responsibilities

• Requirements trade-offs

• Design trade-offs

• Component selection

• Initial integration

• Technical risk resolution

Life-Cycle Focus

Inception

Elaboration

Construction

Transition

Architecture prototyping Make/buy trade-offs Primary scenario definition Architecture evaluation criteria definition

Architecture baselining Primary scenario demonstration Make/buy trade-off baselining

Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements

Architecture maintenance Multiple-component Issue resolution Performance tuning Quality improvements

full-scale production stage. By the time the construction phase is initiated, the architecture transitions into a maintenance mode and must be supported by a minimal level of effort to ensure that there is continuity of the engineering legacy.

To succeed, the architecture team must include a fairly broad level of expertise, including the following:

• Domain experience to produce an acceptable design view (architecturally significant elements of the design model) and use case view (architecturally significant elements of the use case model)

• Software technology experience to produce an acceptable process view (concurrency and control thread relationships among the design, component, and deployment models), component view (structure of the implementation set), and deployment view (structure of the deployment set)

The architecture team is responsible for system-level quality, which includes attributes such as reliability, performance, and maintainability. These attributes span multiple components and represent how well the components integrate to provide an effective solution. In this regard, the architecture team decides how most multiple-component design issues are resolved.

Software Development Team

Figure 11-5 shows the focus of software development team activities over the project life cycle.

Software Development

Artifacts I— Component teams

• Implementation set

• Deployment set

Life-Cycle Focus

Responsibilities

• Component design

• Component implementation

• Component stand-alone test

• Component maintenance

• Component documentation

Life-Cycle Focus

Inception

Elaboration

Construction

Transition

Prototyping support Make/buy trade-offs

Critical component design Critical component implementation and test Critical component baseline

Component design Component implementation Component stand-alone test Component maintenance

Component maintenance Component documentation

The software development team is the most application-specific group. In general, the software development team comprises several subteams dedicated to groups of components that require a common skill set. Typical skill sets include the following:

• Commercial component: specialists with detailed knowledge of commercial components central to a system's architecture

• Database: specialists with experience in the organization, storage, and retrieval of data

• Graphical user interfaces: specialists with experience in the display organization, data presentation, and user interaction necessary to support human input, output, and control needs

• Operating systems and networking: specialists with experience in the execution of multiple software objects on a network of hardware resources, including all the typical control issues associated with initialization, synchronization, resource sharing, name space management, reconfiguration, termination, and interobject communications

• Domain applications: specialists with experience in the algorithms, application processing, or business rules specific to the system

The software development team is responsible for the quality of individual components, including all component development, testing, and maintenance. Component tests should be built as self-documented, repeatable software that is treated like other operational component source code so that it is maintained naturally and is available for automated regression testing. The development team decides how any design or implementation issue local to a single component is resolved.

Software Assessment Team

Figure 11-6 shows the focus of software assessment team activities over the project life cycle.

There are two reasons for using an independent team for software assessment. The first has to do with ensuring an independent quality perspective. This often-debated approach has its pros (such as ensuring that the ownership biases of developers do not pollute the assessment of quality) and cons (such as relieving the software development team of ownership in quality, to some extent). A more important reason for using an independent test team is to exploit the concurrency of activities. Schedules can be accelerated by developing the software and preparing for testing in parallel with development activities. Change management, test planning, and test scenario development can be performed in parallel with design and development.

Software Assessment

Artifacts

• Deployment set > SCO database » User manual 1 Environment

■ Release specifications 1 Release descriptions

■ Deployment documents

Release testing Change management Deployment Environment support

Life-Cycle Focus

Responsibilities

> Project infrastructure

> Independent testing

• Requirements verification

> Metrics analysis

> Configuration control

• Change management

> User deployment

Life-Cycle Focus

Inception

Elaboration

Construction

Transition

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 management Deployment to users Requirements verification

Figure 11-6. Software assessment team activities

Figure 11-6. Software assessment team activities

A modern process should employ use-case-oriented or capability-based testing (which may span many components) organized as a sequence of builds and mechanized via two artifacts:

1. Release specification (the plan and evaluation criteria for a release)

2. Release description (the results of a release)

Each release may encompass several (perhaps incomplete) components, because integration is proceeding continuously. Evaluation criteria will document what the customer may expect to see at a major milestone, and release descriptions will substantiate the test results. The final iteration(s) will generally be equivalent to acceptance testing and include levels of detail similar to the levels of detail of conventional software test plans, procedures, and reports. These artifacts evolve from fairly brief, abstract versions in early iterations into more detailed and more rigorous documents, with detailed completeness and traceability discussions in later releases. Even for use case testing, test components should be developed in a manner similar to the development of component test cases. For example, rather than develop test procedure documents, a project should generate self-documenting test scenarios that are software programs in their own right. These scenarios should be subjected to change management just like other software and are always maintained up-to-date for automated regression testing.

Some component tests may get elevated to evaluation criteria, with their results documented in release descriptions. Many components may undergo only informal component testing by the development team, with the results captured only within the test software built by a developer. Formal testing for many components will then be subsumed in higher level evaluation criteria (usually capability-oriented or thread-oriented scenarios) and corresponding release descriptions. All components are not created equal: Some of them deserve formal component testing to verify requirements, while others are best tested in the context of capability testing. This judgment must be left to the discretion of the assessment team.

The assessment team is responsible for the quality of baseline releases with respect to the requirements and customer expectations. The assessment team is therefore responsible for exposing any quality issues that affect the customer's expectations, whether or not these expectations are captured in the requirements.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

  • Jennifer
    What is project organizations in spm?
    3 months ago

Post a comment