1. Pre-Project Components
CHAPTER 3
Pre-Project Components

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

3. 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

4. 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.

5. 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.

6. 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).

7. 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).

8. 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.

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

10. 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.

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

12. 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.

13. 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.

14. 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)

15. 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

16. 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

17. 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

18. 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)).

19. 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.

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

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

22. 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

23. 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. …

24. 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.

25. 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

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

27. 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.

28. 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.

29. 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.

30. 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.

31. 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”.

32. 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.