Risk Identification Checklist Risk Management

J.E.D.I performance degration to the point of mission success is questionable. 3- Marginal. It would result in failure to meet the requirements would result in degration of secondary mission. 4- Negligible. It would result in inconvenience or usage problems. The last column contains the RMMM Risk Mitigation, Monitoring and Management plan for each risk. It contains the following components: 1. Risk ID. It is a unique identification number that is assigned to the risk. 2. Description. It is a brief description of the risk. 3. Risk Context. It defines the condition by which the risk may be realized. 4. Risk Mitigation and Monitoring. It defines the steps that need to be done in order to mitigate and monitor the risk. 5. Contingency Plan. It defines the steps that need to be done when the risk is realized.

7.9.2 Risk Identification Checklist

One can use the following to determine risks within the software development project. Product Size Risks The product size is directly proportional to the project risk. As software engineers, we take a look at the following: • How large is the estimated size of the software in terms of lines-of-code and function points? • How many is number of programs, files and transactions? • What is the database size? • How many is the estimated number of users? • How many components are reused? Business Impact Risks • What is the business value of the software to the company or organization? • What is the visibility of the software to senior management? • How reasonable is the delivery date? • How many is the customers? • How many are the products or systems that interoperate with the software? • How large is the project documentation? • Does the product documentation have quality? • What are the governmental constraints applied to the development of the project? • What is the cost associated with late delivery? • What is the Cost associated with a defective product? Software Engineering 329 J.E.D.I Customer Related Risks • What is the customer working relationship? • What is the level of the customer’s ability to state their requirements? • Are customers willing to spend time for requirements gathering? • Are customers willing to participate in formal technical reviews? • How knowledgeable are the customers in terms of the technological aspects of the software? • Do customer understand of the software development process and their role? Process Risks-Process Issues • Does senior management show full support or commitment to the software development effort? • Do the organization have a developed and written description of the software process to be used on this project? • Do the staff members know the software development process? • Is the software process used before in other projects with the same group of people? • Has your organization developed or acquired a series of software engineering training courses for managers and technical staff? • Are there any published software engineering standards that will be used by software developer and software manager? • Are there any developed document outlines and examples of deliverables? • Are formal technical reviews of the requirements specification, design and code done regularly? Do they have defined procedures? • Are formal technical reviews of test procedures, test cases done regularly? Do they have defined procedures? • Are the results of each formal technical review documented, including errors found and resources used? Do they have defined procedures? • Do they have procedures that ensure that work conducted on a project conforms to software engineering standards? • Do they use configuration management to maintain consistency among systemsoftware requirements, design, code, and test cases? • Do they have documents for the statement of work, software requirements specification, and software development plan for each subcontract? Process Risks-Technical Issues • Are there any mechanism that facilitates clear communication between customer and developer? • Are there any specific methods used for software analysis? • Are there any specific methods used for component design? Software Engineering 330 J.E.D.I • Are there any specific method for data and architectural design? • Are codes written in a high level language? How much is the percentage? • Are documentation and coding standards followed? • Are there any specific methods for test case design? • Are software tools used to support planning and tracking activities? • Are configuration management software tools used to control and track change activity throughout the software process? • Are CASE tools used? • Are quality metrics collected for all software projects? • Are there any productivity metrics collected for previous software projects? Technology Risks • Is the organization new to the technology? • Do we need to create new algorithms, input or output technology? • Do the software need to use new or unsupported hardware? • Do the software need to use a database system not tested in the application area? • Do we need to define a specialized user interface? • Do we need to use new analysis, design, or testing methods? • Do we need to use unconventional software development methods, such as formal methods, AI-based approaches, and artificial neural networks? Development Environment Risks • Are there any software project management tools employed? • Are there any tools for analysis and design? • Are there any testing tools? • Are there any software configuration management tools? • Are all software tools integrated with one another? • Do we need to train the members of the development team to use the tools? tools? • Are there any on-line help and support groups? Risk Associated with Staff Size and Experience • Is the staff turnover high? • Do we have skilled team members? • Is there enough number of people in the development team? • Will the people be required to work overtime? • Will there any problems with the communications? Software Engineering 331 J.E.D.I

7.10 Software Configuration Management