Activity: Agree Mission

Understand iteration objectives

Examine the iteration plan, and identify the scope and objectives of the plan.

It's useful to supplement this examination with informal discussions with key project staff such as the project manager, software architect and customer sponsor; these meetings will often highlight concerns more explicitly than documented in the plan. Attending iteration kickoff meetings also provides useful information.

Investigate options for the scope of the assessment effort

The mission is the governing principal that guides the test effort during a given time period. Testing resources are typically limited, so the challenge is to balance given testing resource constraints with the quality validation needs of the software development effort.

Gain an initial understanding at a strategic level of the expectations of the software development team. You should mainly be concerned with the expectations of the project manager, software architect and lead system analysts.

Present options to stakeholders

It's not a terribly useful practice to consider objectives and scope in isolation from the rest of the project team. RUP advocates team ownership of product quality, and as such you should include relevant stakeholders from the rest of the project team when deciding what testing is important. You should consider team members that fill the following roles as important stakeholders: Project Manager, Architect, System Analyst, Integrator.

In some cases, the presentation format will suit being formal, with the stakeholders convening as a review board and requiring significant preparation in advance. In other cases, "brown-bag" lunches may be appropriate, or individual interview with each stakeholder. There are good and bad points for each approach: choose the format that best suits you needs in the context of the current project environment.

Formulate mission statement

Mission statements are helpful in providing focus to a team, especially in situations where the team is faced with many possible choices. Test teams without an Evaluation Mission often consider that they simply "do testing": this provides little guidance when difficult choices must be made regarding the best focus for testing within time or resource constraints. A mission statement distills the essence of the current work objective and provides a "mantra" to keep the team focused on the right things.

Formulate a mission statement that can be used by the test team. Don't make it too complex or incorporate too many conflicting ideas: The best mission statements are simple, short and sweet and in most situations where a decision needs to be made between possible options, the mission will make it obvious what choice the team should make.

Here some ideas for mission statements you might adopt for a given iteration:

• find as many bugs as possible
• find important problems fast
• assess perceived quality risks
• advise about perceived project risks
• advise about perceived quality
• certify to a standard
• verify a specification (requirements, design or product claims)
• satisfy stakeholders
• fulfill process mandates

Looking through this list, it should occur to you that many missions are mutually exclusive. For example, if my mission is to "find important problems fast", I likely won't be able to "verify a specification": To successfully achieve one mission often negates other possible missions, and requires a different supporting test approach.

Test teams that try to satisfy too many Evaluation Missions often get into trouble, encountering ongoing conflict in their work. Note also that we recommend choosing or reconsidering your Evaluation Mission in each iteration: it's natural for the mission to alter over time based on the context of the current work effort.

Identify test deliverables

Certain work products are deliverables important to one or more stakeholders: other work products are necessary artifacts of the test effort and while important to the test team, they are of little interest to those same stakeholders.

Give some thought to the minimal set of useful deliverables for the test effort. Don't list all work products; only list those that give direct, tangible benefit to a stakeholder and those by which you want the success of the test effort to be measured. You might need to adjust your initial list to accommodate the needs of the stakeholders, but you will need to take an proactive role in encouraging the deliverables to be kept useful and manageable.

Gain stakeholder agreement

Again, give thought to the appropriate format for presenting the mission and gaining required approvals. Choose the format that best suits you needs in the context of the current project environment..

Evaluate and verify your results

Now that you have completed the work, it is beneficial to verify that the work was of sufficient value, and that you did not simply consume vast quantities of paper. You should evaluate whether your work is of appropriate quality, and that it is complete enough to be useful to those team members who will make subsequent use of it as input to their work. Where possible, use the checklists provided in RUP to verify that quality and completeness are "good enough".

Have the people performing the downstream activities that rely on your work as input take part in reviewing your interim work. Do this while you still have time available to take action to address their concerns. You should also evaluate your work against the key input artifacts to make sure you have represented them accurately and sufficiently. It may be useful to have the author of the input artifact review your work on this basis.

Try to remember that that RUP is an iterative process and that in many cases artifacts evolve over time. As such, it is not usually necessary—and is often counterproductive—to fully-form an artifact that will only be partially used or will not be used at all in immediately subsequent work. This is because there is a high probability that the situation surrounding the artifact will change—and the assumptions made when the artifact was created proven incorrect—before the artifact is used, resulting in wasted effort and costly rework. Also avoid the trap of spending too many cycles on presentation to the detriment of content value. In project environments where presentation has importance and economic value as a project deliverable, you might want to consider using an administrative resource to perform presentation tasks.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process