| RUS | UKR | ENG | ÄîíÍÒÓ> Ïîðòàë ìàãèñòðîâ ÄîíÍÒÓ |
|
|
| Ãëàâíàÿ |
Ìàòåðèàëû:
Ðåôåðàò | Áèáëèîòåêà |Êàòàëîã áèáëèîòåêè | Ññûëêè | Îò÷åò î ïîèñêå
Email: kseniya.mos@gmail.com |
| Áèîãðàôèÿ |
| Ðåçþìå |
| Ïóáëèêàöèè |
| ×ëåíñòâî â AIESEC |
| Êîíòàêòû |
The risks in a software development project can be known, unknown, or unknowable. Known risks are those that one or more project personnel are aware of—if not explicitly as risks, at least as concerns. The unknown risks are those that would be surfaced (i.e., become known) if project personnel were given the right opportunity, cues, and information. The unknowable risks are those that, even in principle, none could foresee. Hence these risks, while potentially critical to project success, are beyond the purview of any risk identification method.
Of the known risks some may already have been communicated to project management. The focus of the risk identification method described here is on risks that are known whether or not they have yet been communicated to project management, and on unknown risks.
The risk identification method achieves the desired focus through the interdependence of the TBQ instrument, and its application process. That is, the use of the one without the other would, in general, fail to reach the desired goals of surfacing and communicating risks to project management.
The SEI risk identification method is based on the following assumptions:
The SEI taxonomy of software development maps the characteristics of software development and hence of software development risks. The TBQ consists of a list of non-judgmental questions to elicit issues and concerns (i.e., potential risks) and risks in each taxonomic group. Hence, the questionnaire ensures that all risk areas are systematically addressed, while the application process is designed to ensure that the questions are asked of the right people and in the right manner to produce optimum results.
The method described in this report presents a disciplined and systematic way to identify risk in a software-dependent system development. This method allows risks to be identified without justification and without a proposed solution. We believe this is the first step in establishing vital communication within an organization.
The TBQ application is semi-structured. The questions and their sequence are used as a defining but not as a limiting instrument. That is, the questions are asked in a given sequence, but the discussion is not restricted to that sequence. This is done to permit context- and culture- sensitive issues to arise in as “natural” a manner as possible. A completely structured interview, while arguably yielding more reliable data for subsequent analysis across different projects, may also yield less valid data. Since for us the pragmatics of risk management were paramount, the semi-structured format was chosen. In effect, the TBQ method can be described as a form of structured brainstorming.
The risk identification method surfaces and clarifies the uncertainties and concerns of a project’s technical and managerial staff. They are close to the problems at their level and have the experience and knowledge to recognize potential problems in technical, procedural, and contractual areas.
1 The Software Development Risk Taxonomy
Central to the risk identification method is the software development taxonomy. The taxonomy provides a framework for organizing and studying the breadth of software development issues. Hence, it serves as the basis for eliciting and organizing the full breadth of software development risks—both technical and non-technical. The taxonomy also provides a consistent framework for the development of other risk management methods and activities.
The software taxonomy is organized into three major classes.
These taxonomic classes are further divided into elements and each element is characterized by its attributes.
Figure 3-1 contains a schematic of the taxonomy. The complete taxonomy, described from the software development risk perspective, is contained in Appendix A where Figure A-1 shows the detailed class-element-attribute structure of the taxonomy.
The next three subsections present a brief description of the software taxonomy to the classelement
level.
1.1 Product Engineering Class
The product engineering class consists of the intellectual and physical activities required to build the product to be delivered to the customer. It includes the complete system hardware, software, and documentation. The class focuses on the work to be performed, and includes the following elements:
3.1.2 Development Environment Class
The development environment class is concerned with the project environment in which a software product is engineered. This environment consists of the following elements:
1.3 Program Constraints Class
The program constraints class consists of the “externals” of the project—the factors that are outside the direct control of the project but can still have major effects on its success. Program constraints include the following elements:
2 The Taxonomy-Based Questionnaire (TBQ)
The TBQ consists of questions at the attribute level along with specific cues and follow-up probe questions (the complete TBQ is reproduced in Appendix B). Because the TBQ is comprehensive, it contains questions that may not be relevant for all stages of a software development life cycle, for specific software domains, or for specific project organizations. Typically, the questionnaire is tailored to a particular project and its stage in the development life cycle by deleting questions not relevant to it. For example, a project without any subcontractors would have the subcontractor questions deleted.
To achieve clarity in the questions, many terms have been given specific definitions (see Appendix C). While these definitions are useful for understanding and using the instrument, they remain general to make the TBQ applicable to a wide range of projects.
Figure 3-2 contains an excerpt from the TBQ from the product engineering class, the requirements element, and performance attribute. The bracketed statement provides the questioner with a generalized context for the questions. Each “starter” question may have additional probe questions based on the initial response. These probe questions are prefaced by a parenthesized “Yes” or “No” indicating the type of initial response that activates the probe question. For instance, if the answer to the starter question “Has a performance analysis been done?” is “Yes,” then the probe questions “What is your level of confidence in the performance analysis?” and “Do you have a model to track performance through design and implementation?” are asked.
Implicit in the TBQ is the probing of areas that contain issues, concerns, or risks. That is, the interview protocol requires the interviewer to always follow up on responses that seem to indicate a potential problem (as described in the next chapter). For instance, if the response to question 23 were “No,” then the interviewer would probe for the issues, concerns, or risks to the project due to lack of performance analysis.
Questions and probes may also have “cues” (bulleted lists) associated with them that list areas that may be covered by the question. The cues are used after the participants have had the opportunity to respond freely. For instance, in question 22 in Figure 3-2, the probe “Are there any problems with performance?” lists possible types of performance problems the software might exhibit—problems with throughput, scheduling asynchronous real-time events, and so forth.
3 Field Testing the TBQ
To validate the ability of the TBQ to elicit project risks, we tested the TBQ on a series of active projects within various companies. The lessons learned from each field test were incorporated into the next version of the TBQ to be tested again. This section describes the TBQ field test process.
In determining the TBQ field test process, the aim was to balance the needs of a thorough risk identification against the “costs” in terms of the time demands on both project personnel and the risk identification team. The method described in this section evolved from several field tests and represents our best understanding of how to use the TBQ under limited time constraints. The method described here is meant as a guide to organizations integrating TBQ risk identification into their risk management process. Implications for TBQ application drawn from information or experience obtained from these tests are presented in Chapter 5.
Figure 3-2 Sample Taxonomy-Based Question
The TBQ field test process consists of four distinct activities: management commitment, team selection and training, risk identification, and identification conclusion. Figure 3-3 shows the process used in the field tests. Each of the steps in the process is described in greater detail below.
3.1 Management Commitment
Three activities need to take place before a field test can be conducted: executive commitment, project selection, and participant selection.
3.1.1 Executive Commitment
Our experience in field testing the TBQ showed that a lack of serious acceptance of the benefits of risk identification by project managers and their immediate superiors led to significant delay or even cancelation of the identification. Hence, our first step was to present an executive briefing to obtain executive commitment. This briefing gave an overview of the process with specifics as to personnel involved and cost to the project, as well as the benefits of conducting a risk identification.
3.1.2 Project Selection
Once executive commitment was obtained, the next step was the selection of a project for the field test. Two main criteria were found useful for selecting a project: that the project manager saw a benefit in doing a risk identification, and that the project had significant software content. Once a specific project was selected, it was found necessary that the client organization des-
Figure 3-3 Risk Identification Process
ignate a site coordinator as the interface between the SEI identification team and the project being reviewed. The site coordinator was given the field test logistics with respect to participants, meeting space, schedule, and support and was responsible for the overall coordination of project personnel for the risk identification sessions.
3.1.3 Interview Participant Selection
The risk identification interview protocol requires an environment in which uncertainties, concerns, issues, and risks can be raised without fear of attribution or the need for a solution. This is essential so that critical risks, while possibly unavoidable, do not stay unarticulated because of the risk avoidance culture of the organization. It was decided to achieve an environment of non-attribution by having each interview group consist only of peers. That is, those participating in a given interview were chosen such that there are no reporting relationships among them.
For a comprehensive risk identification it was also important to select participants who provided adequate vertical and horizontal project coverage. Vertical coverage refers to the project’s organizational hierarchy, while horizontal coverage refers to the functional groups within or relevant to the project. Combining the need for adequate coverage and the pragmatic constraints of a field test, we found four interviews to be optimum. The four groups were technical leads, developers, support functions (SQA, Test, Integration, and so on), and project management. The project management group may be the project manager alone or, at his/her request, may include the chief technical or operations manager. In practice, the specific characteristics of the software project in question should guide the actual number of interview groups required for thorough risk identification. For several reasons (group dynamics, follow-up probing, observing and reacting to non-verbal responses, etc.), groups were limited to a maximum of five participants.
3.2 Team Selection and Training
To prepare for the transition of the TBQ into developing organizations, the SEI field test team was augmented with members from the client organization. Client team members selected to conduct the risk identification, in the collective, need a working knowledge of software development processes, the technology used on the project, the application domain, and the government contracting arena. In keeping with the need to have only peer relations within an interview, no reporting relationships should exist between team members and interview participants.
The entire team needed to be trained, which was done the day before the risk identification sessions. Training covered the TBQ, the roles, process, and interviewing protocol. The training also included a simulated risk identification exercise in which individuals on the team assume the various roles in an application. Role playing was used to give the team members practice in using the questionnaire and the facilitation methods for eliciting risks from partici- pants. An integral part of the client team member training is observing experienced team members during actual interviews. This on-the-job training gives client team members a model to follow when conducting interviews. Client team members can then undertake critical roles during the course of the identification including that of an interviewer (generally after the second interview).
A key aspect of team training has been the provision of specific knowledge of the project under examination. This was provided to team members by a project briefing given by project personnel. It was found adequate if the project briefing was sufficiently detailed to acquaint team members with the characteristics, terminology, and organizational structure of the project.
3.3 Risk Identification
The risk identification session began with a briefing to all risk identification participants consisting of a description of the TBQ method and a summary of the schedule and process to be followed over the duration of the risk identification. In the interests of minimizing the overall time spent on identification, all participants selected by the project were asked to attend. Attendees may also include personnel who might take an active role in future risk identification or other risk management activities for the project.
The field test risk identification process consists of a series of interviews with the groups of selected project personnel. Each interview sessions has two parts:
3.4 Identification Conclusion
In concluding the risk identification, it was necessary to provide feedback to all participants. This was done through a results briefing. This briefing consists of all identified issues, and some suggestions on the next steps in managing the identified issues.5 The intent of the briefing is to provide the participants with feedback on the results of their efforts.
While the reporting step concludes the risk identification process, it represents just the beginning of the project’s risk management strategy. Consequently a copy of the results of the risk identification6 is left exclusively with the project manager. The most compelling reason for this is that many organizations are risk averse. That is, a notion exists that any project having a list of risks is in trouble and needs help fast. Leaving only a single copy of the identified issues and risks allows the project manager to retain control over the situation. This also gives the manager the opportunity to first distinguish among risks, concerns, and misinformation before circulating the results. Premature release of this information could needlessly force or hamper the manager’s actions and expose the project to unjustified negative attention.
The process described above evolved over 15 field tests, undergoing significant refinement in each. We do not recommend the risk identification process described here as the only way to accomplish effective risk identification. We have, however, found it to be effective and efficient.
|
ÄîíÍÒÓ>
Ïîðòàë ìàãèñòðîâ ÄîíÍÒÓ>
Ðåôåðàò | Áèáëèîòåêà | Ññûëêè | Îò÷åò î ïîèñêå
Email: kseniya.mos@gmail.com |