Pre-Project Components CHAPTER 3 Pre-Project Components

Learning Objectives: Development and Quality Plan To discuss: Contract Review Development and Quality Plan

Development and Quality Plan Development and quality plan objectives Elements of the development plan Elements of the quality plan Major software risk items Explain the process of software risk management Importance of development and quality plans for small projects Importance of development and quality plans for internal projects

Development and quality plan objectives Scheduling development activities that will lead to the successful and timely completion of the project, and estimating the required manpower resources and budget. Recruiting team members and allocating development resources (according to activity schedules and manpower resource requirement estimates). Resolving development risks. Implementing required SQA activities. Providing management with data needed for project control.

Elements of the development plan Based on the proposal materials, the project’s development plan is prepared to fulfill the objectives mentioned before. The following elements, each applicable to different project components, comprise a project development plan: 1) Project products, 2) interfaces, 3) methodology, and development tools, 4) standards and procedures, 5) the mapping of the development process, 6) project milestone, 7) staff organization, 8) facilities, 9) risk, 10) control methods, 11) cost estimation.

1) Project products Design documents specifying dates of completion, indicating those items to be delivered to the customer (“deliverables”) Software products (specifying completion date and installation site) Training tasks (specifying dates, participants and sites).

2) Project interfaces Interfaces with existing software packages (software interface) Interfaces with other software and/or hardware development teams that are working on the same system or project (i.e., cooperation and coordination links) Interfaces with existing hardware (hardware interface).

3) Project methodology and development tools To be applied at each phase of the project. Should take account the professional experience of the staff, including the subcontractors’ personnel, even if temporary.

4) Software development standards and procedures A list should be prepared of the software development standards and procedures to be applied in the project.

5) The mapping of the development process Involves providing detailed definitions of each of the project’s phases. These descriptions include definitions of inputs and outputs, and the specific activities planned. Activity descriptions include: An estimate of the activity’s duration. These estimates are highly dependent on the experience gained in previous projects. The logical sequence in which each activity is to be performed, including a description of each activity’s dependence on previously completed activities. The type of professional resources required and estimates of how much of these resources are necessary for each activity.

6) Project milestones For each milestone, its completion time and project products (documents and code) are to be defined.

7) Project staff organization The organization plan comprises: Organizational structure: definition of project teams and their tasks, including teams comprised of a subcontractor’s temporary workers. Professional requirements: professional certification, experience in a specific programming language or development tool, specific software product and type, etc. Number of team members required for each period of time, according to the activities scheduled. Names of team leaders and team members.

8) Development facilities Required development facilities include hardware, software and hardware development tools, office space, and other items. For each facility, the period required for its use should be indicated on the timetable.

9) Development risks Typical development risks are: Technical gaps – lack of adequate and sufficient professional knowledge and experience to carry out the demands of the development contract. Staff shortages – unanticipated shortfalls of the professional staff. Interdependence of organizational elements – the likelihood that suppliers of specialized hardware or software subcontractors, for example, will not fulfill their obligations on schedule. Further readings for development risks: Ropponen & Lyytinen (2000) Boehm & Ross (1989)

Classes of software development risks 1. Scheduling and timing risks 2. System functionality risks 3. Subcontracting risks 4. Requirement management risks 5. Resource usage and performance risks 6. Personnel management risks

Boehm & Ross’s Top 10 software risk items 1. Developing wrong software functions 2. Unrealistic schedules and budgets 3. Developing wrong user interface 4. Gold plating 5. Continuing stream of requirement changes 6. Shortfalls in externally furnished components 7. Shortfalls in externally performed tasks 8. Personnel shortfalls 9. Real-time performance shortfalls 10. Straining computer science capabilities

The software risks management process Pre - project Risk identification and assessment Planning risk management activities New Planning and updating risk Implementing risk management actions (risk resolution) Monitoring software risk Identifying and assessing new software risks Ongoing projects Evaluate monitoring results Required results achieved Unsatisfactory results

10) Control methods In order to control project implementation, the project manager and the department management apply a series of monitoring practices when preparing progress reports and coordinating meetings. Project control method – Documentation control (Chapter 5(5.6)).

11) Project cost estimation Project cost estimations are based on proposal costs estimates, followed by a thorough review of their continued relevance based on updated human resource estimates, contracts negotiated with subcontractors and suppliers, and so forth.

Development plan approval Development plan review and approval is to be completed according to the procedures applied within the organization.

Elements of the quality plan Quality goals Planned review activities Planned software tests Planned acceptance tests for externally developed software Configuration management

1) Quality goals “Quality goals” refers to the developed software system’s substantive quality requirements. When choosing quality goals: Quantitative measures – more objective assessments of software performance. Qualitative measures

Help desk system (HDS) requirements and quantitative goals HDS qualitative requirements Related quantitative quality goals The HDS should be user friendly A new help desk operator should be able to learn details of the HDS following a course lasting less than 8 hours, and to master operation of the HDS in less than 5 working days. The HDS should be very reliable HDS availability should exceed 99.5% (HDS downtime should not exceed 30 minutes per week). The HDS should operate continuously The system’s recovery time should not exceed 10 minutes in 99% of cases of HDS failure. …

2) Planned review activities The quality plan should provide a complete listing of all planned review activities: design reviews (DRs), design inspections, code inspections, etc., with the following determined for each activity: The scope of the review activity The type of the review activity The schedule of review activities (as defined by its priority and the succeeding activities of the project process) The specific procedures to be applied Who is responsible for carrying out the review activity.

3) Planned software tests The quality plan should provide a complete list of planned software tests: The unit, integration or the complete system to be tested The type of testing activities to be carried out, including specification of computerized software tests to be applied The planned test schedule The specific procedures to be applied Who is responsible for carrying out the test

4) Planned acceptance tests for externally developed software Items to be included: Purchased software Software developed by subcontractors Customer-supplied software

5) Configuration management The quality plan should specify configuration management tools and procedures, including those change-control procedures meant to be applied throughout the project.

The quality plan document, its format and approval The quality plan may be prepared as part of the development plan or as an independent document. In some cases, the plan is divided into several documents by item category, such as DR plan, testing plan, and plan for externally developed software acceptance tests. Review and approval of the quality plan should be conducted according to the organization’s standard procedures for such plans.

Development and quality plans for small projects It should be clear that the development and quality plan procedures applicable to large projects cannot be automatically applied to small projects. Recommended elements of development and quality plans for small projects: Development plan – products, benchmarks, risks, costs. Quality plan – quality goals.

Importance of development and quality plans for small projects A more comprehensive and thorough understanding of the task is attained. Greater responsibility for meeting obligations can be assigned. It becomes easier for management and customers to share control of the project and to identify unexpected delays early on. Better understandings with respect to the requirements and timetable can be reached between the developer and the customer.

Development and quality plans for internal projects Internal projects – project intended for use by other departments in the organization or by the entire organization, as well as those projects dealing with software package development for the software market. No external body participates as customer. Can be medium or large scale. Recommended procedure – treat the internal project as “regular project”.

Importance of development and quality plans for internal projects The development department will avoid losses incurred by unrealistic timetables and budgets, as well as the consequent damage to other projects and to the firm reputation. The internal “customer” will enjoy reduced risk of late completion and budget overrun in addition to and by improved project control and coordination with the developer. The firm will enjoy reduced risk of its software product’s late entry into the market, reduced risk of a decline in its reputation resulting from late supply, and reduced risk of budget overruns.