To define the numbers, type (skills, domain), experience and caliber of staff required for the
Based on the effort estimates for the project, the desired schedule, the chosen organizational structure and mapping of
roles, the Project Manager determines the staffing profile (number of staff over time, and skill set) required for the
project. The effort estimate for a project is of course not independent of team size, experience, skills and caliber -
in all probability, the Project Manager will have made assumptions about staff capability, etc. when forming the effort
estimate. In the COCOMO estimation
model (see Task: Plan Phases and Iterations), staff capability and experience
are major effort drivers. Therefore, selecting an acceptable total effort (by tuning the various COCOMO effort drivers)
and a feasible schedule will determine the staff profile.
In some cases, the Project Manager may know in advance the numbers and skills of staff that will be available. In
these cases, with the staff size and skills set, only the schedule is variable, assuming the project scope stays
The Project Manager must also be aware of the disruption that may be caused by ramping up staff levels too rapidly, and
the potentially catastrophic effect on productivity of attempting radical reductions in schedule, by large increases in
During Inception, the focus is on defining and bounding the scope, and developing a business case for the project.
Consequently, the team size is quite small: a Project Manager, a Software Architect, and perhaps a developer or two,
especially where a proof of concept prototype is needed to clarify the requirements or build support for the product.
During Elaboration, the focus is primarily on the architecture and the architectural prototype. Consequently, design
tasks in early elaboration focus on the architectural aspects; little attention is given to the details of the classes
and their attributes, which although identified are not architecturally significant. During these iterations, most of
the effort comes from your architecture team and a designated prototyping team. The prototyping team is usually put
together by the more experienced programmers. At this point you have a very small design team that will focus on
generic mechanisms and technologies. The test group will focus on building the test environment and testing the early
The choice of members of the architecture team should be made carefully: they should not only possess superior analysis
and design skills, but also leadership qualities. In order to communicate the architecture to the larger team during
the construction phase, a good practice is to distribute the members of the architecture team among the Construction
teams. Members of the architecture team also need to cover a broad spectrum of software engineering experience:
software design and implementation, performance tuning, database management, network management and configuration
management include the major skill sets that must be represented in the architecture team.
The Construction Phase focuses on maintaining the architectural integrity of the system while building increasing
functionality into the system. This requires architectural refinement (hence the "baselining" and not "freezing" of the
architecture following the Elaboration Phase) and an architecture team that keeps an eye on the designers and their
The architecture team will tend to distribute itself among the development teams, acting as technical leads and
coordinating inter-group issues with the other technical leads. The Construction teams themselves must be
cross-functional teams with both design and development expertise, as they are responsible for both the design and
implementation of their assigned functionality. Typically, a Construction team is responsible for one or more
subsystems with well-defined interfaces; changes to these interfaces or the addition of new subsystems causes
architectural change and needs to be carefully considered. Within the subsystem, the team is relatively free to design
and implement as it sees fit, but cross-team communication is needed to ensure that teams are not building the same
implementation mechanisms in parallel.
Typically, Construction teams are usually organized horizontally, along the lines of layering. A team may be
responsible for database interfaces, or communication infrastructure, while other teams focus on the application
functionality itself. The "upper" layer teams as a result require more expertise in the problem domain and with User
Interface design or interfacing with external systems. "Lower" layer teams are more intimate with the implementation
technology. The composition of these teams must reflect these different skill demands.
The first question in test is how much formal testing are you required to do? And then, how much of this can you afford
to do to meet your quality objectives and still be within reasonable limits from a cost and schedule perspective. It is
rare that projects have the budget to do all kind of tests. Typically, projects must select a test level they can
afford. Remember, each test specification must be inspected and maintained. It is very bad for project team morale if
there are plans to create a lot of test specifications, but cannot implement those plans because you run out of time.
Create a specific test team. At least one person in the test team must come from the requirements capture team. The
test team is responsible for
Black-box testing. Test the use cases from outside the system on the basis of the use case's flow of events
(see Artifact: Use Case).
White-box testing. Test the actual sending of messages in the use case on the basis of the sequence views
for the scenarios.
System test. Stressing the system to reveal its true nature.
Remember that testing is not just to run the tests - it is also to prepare the test environment and to write and
inspect the test specifications.
An independent group should test the use cases and the entire system. They should perform the tests and write the test
reports as well. The work of testing the use cases should be organized so that there is one individual responsible for
testing each use case.
If it is not possible for an independent group to test the use cases, as on a small project, you should at least make
sure that the person responsible for a use case in design does not test the use case.
Automated regression testing should be used on medium and large projects. The test team will require some programmers
to support this capability. This is even more important during an iterative development, where you do not want to
expend a lot of effort re-running the same test suites again and again.
In the Transition Phase, development work is completed. Beta testing is conducted, and a final release is prepared. If
a good job has been done in Construction, the project team can begin scaling back in size, reducing the number of
developers and testers. The mix of the team will shift in favor of trainers and infrastructure logistics experts who
are responsible for deploying the product into the user community.
The software architect, or architecture team, works in a "follow up mode": they help sort out problem reports,
prioritize change proposals, and change orders to make sure that problems are not fixed for the sake of expediency in a
way that damages the architecture. Design tasks recede during the transition phase, and are limited to correcting
problems, or introducing last minute enhancements.