Professional Documents
Culture Documents
02 Review
02 Review
02 Review
Contract Review
A bad contract is always an undesirable event Bad contract Loosely defined requirements, unrealistic budgets & schedules Low quality software
Signing a Contract
Participation in a tender Submission of a proposal according to the customers RFP Receipt of an order from a companys customer Receipt of an internal request or order from another department in the organization
Review Stages
Review of the proposal draft prior to submission to the potential customer (proposal draft review) Review of contract draft prior to signing (contract draft review)
Customer requirements have been clarified and documented Alternative approaches for carrying out the project have been examined Formal aspects of the relationship between the customer and the software firm have been specified Identification of development risks Adequate estimation of project resources and timetable have been prepared
5
Examination of the firms capacity with respect to the project Examination of the customers capacity to fulfill his commitments Definition of partner and subcontractor participation conditions Definition and protection of proprietary rights
No unclarified issues remain in the contract draft All understandings reached subsequent to the proposal are correctly documented No new changes, additions, or omissions have entered the contract draft
Project magnitude Project technical complexity Degree of staff acquaintance with and experience in the project area Project organizational complexity
The leader or another member of the proposal team The members of the proposal team An outside professional or a company staff member who is not a member of the proposal team A team of outside experts
Inadequate definition of project requirements Poor estimates of required resources Poor timetable/scheduling Inadequate awareness of development risks
11
12
To detect analysis and design errors To identify new risks likely to affect completion of the project To locate deviations from templates and style procedures and conventions To approve the analysis or design product
13
To provide an informal meeting place for exchange of professional knowledge about development methods, tools, and techniques To record analysis and design errors that will serve as a basis for future corrective actions
14
Necessary for approval of the design product Without this approval, the development team cannot continue to the next phase of the software development project Formal design reviews may be conducted at any development milestone requiring completion of an analysis or design document, whether that document is a requirement specification or an installation plan
15
DPR Development Plan Review SRSR Software Requirement Specification Review PDR Preliminary Design Review DDR Detailed Design Review DBDR Data Base Design Review TPR Test Plan Review STPR Software Test Procedure Review
16
VDR Version Description Review OMR Operator Manual Review SMR Support Manual Review TRR Test Readiness Review PRR Product Release Review IPR Installation Plan Review
17
A summary of the review discussions The decision about continuation of the project A full list of the required actions corrections, changes, and additions that the project team has to perform The name(s) of the review team member(s) assigned to follow up performance of corrections
18
Peer Review
Participants in peer reviews are the project leaders equals, members of his or her department and other units Main objectives of peer review lie in detecting errors and deviations from standards
19
20
Insufficient in-house professional capabilities in a specialized area Temporary lack of in-house professionals for review team participation due to intense workload pressures during periods when waiting will cause substantial delays in the project completion schedule Indecisiveness caused by major disagreements among the organizations senior professionals In small organizations, where the number of suitable candidates for a review team is insufficient
21