The Life cycle plan gives the allocation of resources to the various activities involved in developing the project. These resources include time, effort, personnel and the skills required by these people. It also discusses the risks involved and steps that can be taken to reduce their impact.
1.1 Purpose
The purpose of the Life Cycle Plan is to provide detailed allocation of resources. This can be done by using various charts and tools. The PERT charts indicate the order of tasks to be performed, the Gantt charts indicate the time at which these tasks will be performed and the staffing plans show the assignment of people to tasks.
1.2 References
Documents:
Operational Concept Description
System and Software Requirements Definition
System and Software Architecture Description
Feasibility Rationale
Tools:
USC COCOMO II
Primavera Project Planner
The major life cycle stages are explained here and the detailed phases and milestones are given in the following subsection.
2.1 Overall Life Cycle Strategy
The process model used for the entire project is the WinWin Spiral model. The production stage uses incremental development within the framework of the overall WinWin Spiral model. To counteract the impact of schedule constraints and improve productivity, parts of the increments will be developed concurrently. The stages of the plan are:
In this stage the 577a team analyses the need for ‘World War I – Access Enhancement’ within the framework of VKC Library. Based on this analysis, the objectives and requirements are decided and the design process for the proposed system is initiated. This stage consists of the following two phases
In this phase there was extensive student – client meetings and negotiations to determine the objectives, requirements and alternatives. Prototyping of interfaces was used to determine customer and user expectations. Based on these an initial architecture was developed. The milestone that marked the completion of this phase was the LCO ARB review held on 11/13/98.
In this phase the architecture and prototype were further refined. The modifications suggested by the LCO ARB were incorporated to increase stakeholder concurrence. A preliminary design for the proposed system providing sufficient detail will be provided. This milestone for the completion of this phase is the LCA package submission on 12/14/98.
The PERT chart for the Engineering stage is as shown below, the quantities in brackets indicate the estimated time in weeks:
In this stage the 577b team makes the final adjustments or refinements required and then proceeds to develop the software. This software is then tested, debugged and installed. The customer and users are trained and the documentation for using and maintaining the system will be provided. This stage also consists of two phases that are described below.
The 577b team finalizes the design based on the 577a LCO, LCA documents and the suggested in the individual critiques. The project will then be developed in three increments.
Increment – 01 : (i) User interface
(ii) Administrator interface
(iii) Database design and creation
(iv) Search
(v) Insert/Update
Increment – 02 : (i) Password based authentication facility
(ii) Email facility for users to contact library staff
(iii) Providing online help for users
Increment – 03 : (i) Formatting output of user interface
(ii) Generating reports for library staff.
In increment – 01, the first three parts i.e. the interface and database design and creation will be done concurrently. The implementation of these tasks is sufficiently independent to be done in parallel. The remaining two tasks depend on these and hence they will be developed after these three. However the last two parts will also be developed in parallel.
In increment – 02, all the parts will be developed concurrently as they are fairly independent of each other. The password facility will be for the administrator interface, the email for the user interface and the online help will be mainly documentation of using the system.
The final part is increment – 03, contains two parts which can be developed in parallel. By developing subtasks concurrently the productivity can be increased, however they have to be properly coordinated. This milestone for the completion of this phase is the Transition Readiness review that will be held on 04/20/98.
Following is the detailed description of the increments:
Increment – 01:
This increment will develop the very high priority requirements of the project, it consists of the following:
(i) User Interface:
This is the interface that will be accessed from the internet and will provide search facility. People will be able to perform two types of search – normal and advanced. In normal search, they will enter a keyword that will be used to match text in all fields. In advanced search they will give keywords that will be matched to individual fields.
(ii) Administrator Interface:
This interface will be used by the VKC Library staff. It will provide them a means to input data and use it to add new information, modify and remove existing information about World War I books.
(iii) Database design and creation:
The database will be designed to store the data for the various fields and facilities that have been provided in the user and administrator interfaces. A database based on this design will then be created.
(iv) Search:
This part will develop the actual facility for searching that will use the data entered through the user interface and transform it to preformatted queries to the database. It will then send the results back to the user interface over the internet.
(v) Insert/Update:
This part will provide the library staff with the facility for adding new records, modifying and removing existing records. This will enable them to maintain the information about the World War I books.
Increment – 02:
This increment will develop the high priority requirements of the project, and it consists of the following:
(i) Password based authentication facility:
An authorization mechanism using passwords will be added to the administrative interface. The passwords for the administrator and reference librarian will be different and the system will provide different services to them.
(ii) Email facility for users to contact the library staff:
An email facility will be added to the user interface that will allow them to communicate with the library staff. They can use this to ask questions to the reference librarians about books or to the administrator about using the software.
(iii) Providing online help for users:
This will provide instructions to use the software that will be in text format and will be available for explaining the features of the software. There will be separate help for the user interface and for the administrator interface.
Increment – 03:
This increment provides the medium priority requirements and it consists of:
(i) Formatting output of the user interface:
Will enhance the user interface to allow the users to select the number of search results that they want to view at a time.
(ii) Generating reports for library staff:
This facility in the administrator interface will allow the library staff to view information about the books in the form of reports. They can select the number of records they want to view at a time.
In this phase the software is installed and the necessary documentation is delivered. The VKC Library staff will be trained to operate the system and the 577b team will explain the various options to them. This phase will be completed by a Release Readiness Review held on 05/04/99.
The PERT chart for the Production stage is as shown below, the quantities in the brackets indicate the estimated time for the activity in weeks:
In this stage ISD can further enhance the software. This software could evolve in scope and ISD will be responsible for these developments and maintenance of the software. These additions and extensions could be due to change in technology or for evolution purposes. This stage will be completed by a series of Release Readiness Reviews.
The Rebaselined version of the milestone (Gantt) chart for the overall life cycle strategy is as shown below:
2.2 Phase Milestones and Schedules
Based on the top-level information described in the previous section, the detailed phase milestones and schedules have been described using milestone and activity charts. For the activity (PERT) charts, critical path analysis has been performed and it also shows the latest start and slack times for each activity.
2.2.1 Engineering stage
The detailed PERT (activity) chart for the Engineering Stage is as shown below, the pair of values on the top of each activity are used for calculating the critical path. The values on the left hand corner is the latest – start time and those on the right hand corner are the slack time for each activity.
The Rebaselined version of the detailed Gantt chart for the engineering stage is shown below,
2.2.2 Production stage
The detailed PERT (activity) chart for the Production stage is as shown below, the pair of values on the top of each activity are used for calculating the critical path. The values on the left hand corner is the latest – start time and those on the right hand corner are the slack time for each activity.
The Rebaselined version of the detailed Gantt chart for the Production Stage is as shown below:
2.2.3 Support stage
After the successful completion of the production stage the software package would have been installed. However the data describing the books of the World War I collection will have to be entered into the database. The administrator interface is such that this activity can be an iterative process triggered whenever a book that was previously on the bookstacks is shifted to remote storage.
2.3 Phase Deliverables and Completion Criteria
|
Name: |
Transition package |
|
Due date: |
04/20/99 |
|
Format: |
Floppy disks containing the source code in the /WWIAE/code/ directory and installation files in the /WWIAE/install/ directory. |
|
Completion criteria: |
The software should provide search and administrative capabilities as described in detail in the requirements whose pointers are given below. There should be a README.TXT file giving the steps for installing the package. |
|
Pointers: |
NMRQ-01, 02, 04, 05, 06, 09, 10, 11 |
|
Name: |
User manual |
|
Due date: |
04/20/99 |
|
Format: |
The document will have the following format:
|
|
Completion criteria: |
The document should contain the specifications of the minimum requirements for the system (both hardware and software). It should also contain and explanation of the usage of the two modes and all the options provided by them. The troubleshooting section should suggest solutions to problems and guide to sources of more information about solving problems. |
|
Pointers: |
QARQ-02 |
|
Name: |
Training material |
|
Due date: |
05/04/99 |
|
Format: |
The document will have the following format:
|
|
Completion criteria: |
The training material should provide details of how to use the system with the help of user manual and suitable examples. It should explain both normal circumstances and exceptional ones. |
|
Pointers: |
QARQ-04 |
3. Responsibilities
The following section describes the responsibilities of the various organizations, and positions involved with the help of charts.
3.1 Organizational Responsibilities
The following chart shows the responsibilities of the various organizations involved:
|
|
Inception |
Elaboration |
Construction |
Transition |
|
VKC Library (Client) |
Provide details about World War I book collection and VKC library. Use prototype and provide feedback |
Decide the system capabilities achievable and completion criteria of product through negotiation with 577a team |
Test increments as they are developed by 577b team and monitor progress at milestones. |
Test entire software product and provide support in installing the software. |
|
CSci 577 (Developer) |
577a team does system analysis to determine operational concept, prototype, initial architecture and plans |
577a team refines design and develops detailed architecture and plans. |
577b team revises design and develops software according to the project plan. |
577b installs the software and provides documentation and training for using it. |
|
ISD (Maintainer) |
Provide constraints for implementation and support. |
Provide information on existing solutions and products and constraints for other products. |
Provide resources for developing the software. |
Review product and documentation for future releases and maintenance. |
3.1.1 Global Organization chart
3.1.2 Organizational Commitment Responsibilities
|
Individual |
Commitment Responsibility |
|
Mr. Kenneth Klein ( Head, Von KleinSmid Center Library and the East Asian Library ) |
Mr. Klein is the authority that is responsible for committing to project changes, scope, budget and schedule. |
|
Prof. Barry Boehm (CS 577 course instructor) |
Prof. Boehm is the authority that is responsible for assigning teams of students to the project. |
|
Mr. Phil Reese (Executive Director of Information Infrastructure Core, ISD) |
Mr. Reese is responsible for providing the computer resources for development and for maintenance after installation. |
|
Mr. Damien Elwood (Director CCP/Digital Document Services) |
Mr. Elwood is responsible for the digitizing of the books and for OCR of the ones in english. |
|
Rajnish Lal (Manager 577a team 13) |
As manager of the team, he is responsible for coordinating the commitments of the changes to the team and committed to deliver to the LCO and LCA documents for the engineering stage. |
|
Rajnish Lal (Manager 577b team 13) |
He is responsible for committing to the changes in the project scope and environment during the production stage. He will also deliver the transition package, training material and user manual. |
3.2 Stakeholder Responsibilities
The following section describes in detail the major organizational components, types of personnel and skills required for each stage of the project
3.2.1 Engineering Stage
The following are the details for the engineering stage:
Organization:
The major organizational components have been shown as a chart indicating the management hierarchies and responsibilities:
Types of personnel and critical skills required for Engineering stage:
Analyst: There were three people assigned to the task of meeting with Mr. Klein and analyzing the scope, requirements and other details of ‘World War I – Access Enhancement’. These people required experience in software development so that they could analyze the practicality of a software based solution for the problem.
Prototypist: One person was assigned to the task of developing the prototype and required skills with HTML, web authoring tools, and Visual Basic/C++.
Manager: One person was assigned to the task of coordinating the entire project and for configuration management and quality assurance. He was responsible for tracking the project activities to meet schedule constraints. The skills required were management, communication skills and planning.
Staffing plan for Engineering stage:
|
WBS |
Activity Week |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
Total |
% |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
S2 |
System Analysis |
3 |
3 |
1 |
|
|
|
1 |
1 |
|
|
|
9 |
16 |
|
S2 |
Ops Concept |
|
|
2 |
1 |
|
|
2 |
1 |
1 |
|
|
7 |
13 |
|
S2 |
Requirements |
|
|
|
1 |
1 |
1 |
1 |
1 |
|
|
|
5 |
10 |
|
S2 |
Architecture |
|
|
|
1 |
1 |
1 |
|
|
3 |
1 |
1 |
8 |
14 |
|
S1 |
Life cycle plan |
|
|
|
|
1 |
2 |
|
|
|
1 |
1 |
5 |
10 |
|
S1 |
Feasibility |
|
|
|
|
|
1 |
|
1 |
1 |
1 |
1 |
5 |
10 |
|
SA2,SB2 |
Prototype |
|
1 |
1 |
1 |
1 |
|
1 |
|
|
1 |
1 |
7 |
13 |
|
S1 |
Project management CM/QA |
1 |
1 |
1 |
1 |
1 |
|
|
1 |
|
1 |
1 |
8 |
14 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
54 |
100 |
Week – 1 starts on September 20, 1998 (Monday)
Week – 11 starts on December 11, 1998 (Monday)
3.2.2 Production Stage
The following are the details for the production stage:
Organization:
The major organizational components have been shown as a chart indicating the management hierarchies and responsibilities:
Types of personnel and critical skills required for Production stage:
Developer: About five people will be required to perform development activities. At least two people are required who have prerequisite experience in Java programming, especially in socket communication and spawning multiple threads to handle concurrent users. Other skills required by some or all of the developers are IBM Digital Library, HTML, web authoring, Net.Data macro programming and database concepts.
Manager: One person will be needed for project tracking and performing configuration management and quality assurance. Experience in managing similar project will be helpful, more useful would be experience in analyzing the project.
Staffing Plan for Production stage:
|
WBS |
Activity |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
Total |
% |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
S2 |
Architecture Rebaseline |
4 |
4 |
|
|
|
|
|
|
|
|
|
|
8 |
13.3 |
|
SAA |
User Interface |
|
|
2 |
2 |
|
|
|
|
|
|
|
|
4 |
6.7 |
|
SAB |
Administrator Interface |
|
|
2 |
|
|
|
|
|
|
|
|
|
2 |
3.3 |
|
SB |
Database |
|
|
1 |
|
|
|
|
|
|
|
|
|
1 |
1.7 |
|
SC |
Search |
|
|
|
|
2 |
2 |
2 |
|
|
|
|
|
6 |
10 |
|
SD |
Insert/update |
|
|
|
|
2 |
2 |
|
|
|
|
|
|
4 |
6.7 |
|
SAB |
Password |
|
|
|
|
1 |
|
|
|
|
|
|
|
1 |
1.7 |
|
SAA |
|
|
|
|
|
|
1 |
|
|
|
|
|
|
1 |
1.7 |
|
SAA |
Online help |
|
|
|
|
|
|
|
2 |
|
|
|
|
2 |
3.3 |
|
S5 |
Reports |
|
|
|
|
|
|
|
2 |
|
|
|
|
2 |
3.3 |
|
S4 |
Unit testing |
|
|
|
2 |
|
2 |
|
1 |
|
|
|
|
5 |
8.3 |
|
S4 |
System testing |
|
|
|
|
|
|
|
|
4 |
4 |
|
|
8 |
13.3 |
|
S1 |
Project management, CM/QA |
1 |
1 |
|
1 |
|
|
1 |
|
1 |
1 |
1 |
1 |
8 |
13.3 |
|
S6 |
Transition and training |
|
|
|
|
|
|
|
|
|
|
4 |
4 |
8 |
13.3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
60 |
99.9 |
3.2.3 Support Stage
Organization:
The major organizational components have been shown as a chart indicating the management hierarchies and responsibilities
3.3 Organizational Impacts
This section describes the impact (personnel, time requirements, budgets, etc) this project will have on each of the organizational components during each of the development stages.
3.3.1 Engineering Stage
No impact. ISD will continue to provide services without any changes as a result of this project.
Medium impact. The customer must be available and accessible to the development team for requirements definition, prototype validation, conflict resolution and information gathering/distribution. The customer is assigned by the library and will carry this in addition to their normal library duties.
Minimal impact. Any number of patrons as requested and selected by the customer to provide feedback on user interfaces. Time requirements are minimal, to the extent of 5 hours over the course of the semester.
Minimal impact. Same as patrons.
Major impact. The CSCI 577a development is comprised of five students, each with a primary responsibility. All team members have a secondary responsibility to ensure adequate role coverage and provide a backup should a difficulty arise. Various time requirements, upwards of 20 hours per week depending on upcoming milestones, time management and team efficiency.
3.3.2 Production Stage
In this stage the 577b team developers will meet the client for rebaselining the architecture. Once development has begun the VKC library staff will review and provide feedback for the interfaces as they are developed. Finally in the transition phase the staff will be trained to use the system.
No impact on most of ISD operations unless a liaison is selected for the CS577b development team. In this case the impact would be minimal, as it would be an additional duty with minimal time requirements for an existing ISD employee. Major impact on ISD-CCP operations due to the scanning process. ISD-CCP will need to scan approximately 1200 artifacts and provide the WWI-AE administrators with the scanned files. This impact may be reduced by increasing the time available for scanning.
Medium impact. The customer will need to be available and accessible to the development team throughout the implementation process. An average of approximately 3 hours per week is expected to be needed to cover program validation, conflict resolution, and information gathering.
Medium impact. The patrons will need to devote a few hours each week during the later stages of the development process in order to validate the user interfaces. A minimum of 2 people should be used, with additional patrons increasing the likelihood of catching program errors.
Major impact. The administrators will need to have a large amount of time available to input the artifacts scanned by ISD-CCP into the database. Temporary staff may be hired by the library to cover artifact entry.
Major impact. The development team will have 15 weeks to complete implementation and deploy the program. The standard 5-member team will be needed. Increasing or decreasing the number of team member will proportionately change the time requirements and impact level on the team. One of the team members should serve as the project lead, one as interface lead, one as database lead, one as quality/testing lead and one as the integration lead. All members should have secondary roles to provide backup and overlapping coverage in the event that personnel problems develop.
3.3.3 Support Stage
Once the system is installed and operational, VKC Library staff will enter data about ‘World War I’ books and then send them to remote storage. This may be done at the same time or in phases if books are shifted in increments. Also if the books are shifted before the completion of the system, they can be recalled from the remote storage to enter data about them.
Major impact. Continued scanning of the artifacts that were not scanned during the Production stage. The fewer artifacts which remain, the less the impact on ISD-CCP. For ISD in general, support and maintenance of the system will be a minimal impact due to the robust and self-contained nature of the project. Online help and universal interfaces will reduce the amount of time required for system support. Existing support personnel must be trained in the operation of the system before providing support to the users; but no additional staff is necessary.
No impact. The customer can return to their normal duties without the responsibilities of the project. Specifying program upgrades may be done at the customer's discretion but are not considered to be within the scope of the original project.
No Impact. Patrons become private entities after deployment and are no longer considered in the scope of the project.
A minimum of one person will be required to perform the duties of system administrator. The time requirements depend entirely on the number of artifacts that need to be added or updated in the database. As ISD-CCP provides scanned artifact, an administrator must input them into the database. The impact varies proportionately with the artifacts remaining to be scanned by ISD-CCP in this stage.
No Impact. The development team finishes their responsibilities upon deployment and are no longer affiliated with the project.
4. Approach
The following section describes the major risks involved in the project and how these can be reduced. It also describes the other major project related activities such as configuration management and quality assurance.
4.1 Risk Management
|
Number: |
RISK-01 |
|
Description: |
Members of the 577b team may leave the project in between the production stage. |
|
Name: |
Personnel shortfall |
|
Risk Exposure: |
RE = Prob(UO) X (Loss) = (6) X (7) = 42 (on a scale of 1 to 10) |
|
Damage: |
High |
|
Management: |
Such a risk is reduced in 577 as students are committed to completing the course after a certain initial period. However assigning teams that have previously worked on the project can reduce this risk. |
|
Contingency plan: |
In case this does occur then Prof. Boehm can assign other students to the team. |
|
Number: |
RISK-02 |
|
Description: |
The team might not be able to complete the development process on time. |
|
Name: |
Schedule slippage |
|
Risk Exposure: |
RE = Prob(UO) X (Loss) = (10) X (9 ) = 90 (on a scale of 1 to 10) |
|
Damage: |
Very High |
|
Management: |
Estimation helps reduce the risk as teams perform it and they will have an idea of its feasibility |
|
Contingency plan: |
In case the team falls behind schedule, increment – 03 may be dropped. |
|
Number: |
RISK-03 |
|
Description: |
The interfaces developed do not match to the user expectations. |
|
Name: |
User Interface mismatch |
|
Risk Exposure: |
RE = Prob(UO) X (Loss) = (3) X (6) =18 (on a scale of 1 to 10) |
|
Damage: |
Medium |
|
Actions to mitigate risk: |
This risk can be reduced by developing the user interface so that it can be reviewed by the client and changed if necessary. Extensive prototyping was done to ensure that the interfaces are what the users and customers desire. |
|
Number: |
RISK-04 |
|
Description: |
Once the initial artifacts are entered, if any additional artifacts need to be added or modifications to present data is required, then similar data generation capabilities may be needed. |
|
Name: |
Data generation capabilities for maintenance |
|
Risk Exposure: |
RE = Prob(UO) X (Loss) = (7) X (3) = 21 (on a scale of 1 to 10) |
|
Damage: |
Medium |
|
Management: |
Text modifications could be done by the administrative subsystem |
|
Contingency plan: |
CCP could be approached to generate image/OCR data for the required material. |
|
Number: |
RISK-05 |
|
Description: |
There is a possibility that permission to reproduce some of the books digitally can not be obtained. |
|
Name: |
Copyright for digitized data. |
|
Risk Exposure: |
RE = Prob(UO) X (Loss) = (2) X (3) = 6 (on a scale of 1 to 10) |
|
Damage: |
Very Low |
|
Management: |
Every effort should be made to obtain approval for reproduction of the artifacts. |
|
Contingency plan: |
In the case permission to reproduce the artifact can not be obtained, it will not be entered into the database. |
4.2 Support Environment, Methods, and Tools
The following table indicates the tools used along the various stages of the project for the different activities:
|
Activities |
Inception |
Elaboration |
Construction |
|
|
|
|
|
|
System Engineering |
WinWin |
WinWin |
|
|
Object Oriented Analysis & Design |
Rational Rose |
Rational Rose |
Rational Rose |
|
Prototyping |
Microsoft FrontPage Netscape Composer |
Netscape composer, Visual Basic 6.0 |
|
|
Process model |
Spiral (MBASE) |
Spiral(MBASE) |
Spiral with increments (MBASE & CMM) |
|
Programming |
|
|
IBM Digital Library, Net.Data & HTML |
|
Database |
|
|
DB/2 relational |
|
Project Management |
USC COCOMO II |
USC COCOMO II Primavera planner |
USC COCOMO II Primavera planner |
4.3 Reviews
This part explains the preparation and objectives of the reviews to be held during the course of the project.
4.3.1 Architecture Review Board I
The objective of the first ARB was to review the initial progress made and provide feedback for improving the project. It was the entry point into the elaboration phase. Mr. Kenneth Klein was representing the VKC Library on the review board.
4.3.2 Architecture Review Board II
This objective of this review is to provide assurance for the consistency of the operational concept, requirements, architecture, plan and feasibility. It also covers the risk management plan that describes the major risks and plans to mitigate them.
4.3.3 Architecture Review Board III
This will be held to verify the LCA Rebaseline, it will be an incremental review of the LCA package with respect to its feasibility.
4.3.4 Inspections and In-Process Reviews
These will be done by the team members. They can be done after completion of each part, or increments. It will mainly be used to review the progress being made.
Unit Test Completion Review (UTCR) - development team adequately tests software with assistance from users and administrators. A detailed design inspection and an inspection of the code may be completed as an internal deliverable used to track and measure progress toward goals. Guidelines for the inspection process can be found on the CSCI577b course home page
4.3.5 Transition Readiness Review
This will be done when the team has completed the software development process and is ready to install the software. It will mainly involve the discussion of the software satisfying the requirements and its installation.
Software Acceptance Review (SWAR) - focus on the acceptability of the system from the customer's point of view. Validates program's capability of customer's requirements. A plan shall be created which details the steps necessary to transition the software project from the developer to the customer/ISD upon completion of the production stage. The plan shall include customer requirements for the following items:
The designated project leader will oversee this review and its corresponding documentation.
4.3.6 Release Readiness Review
This will be done once the software has been installed successfully and the library staff has been trained to use the software. System Acceptance Review - verifies that all stakeholder requirements and conditions for a successful product are met by the software. Final milestone before releasing product to the customer.
4.4 Project Communications
The team members of 577a had meetings with the client every week. However this will not be necessary for the 577b team because 577a involved a detailed analysis while 577b will mainly involve construction. Thus the members can meet the client to update them about the progress and for testing the developed software.
The team members can communicate amongst themselves via email, phone or by scheduling meetings. They will be meeting fir the 577b class every week nd can decide meeting time and location.
4.5 Configuration Management
The following table indicates the key products and the time that they enter into the project.
|
|
Inception |
Elaboration |
Production |
|
Operational Concept |
m |
l |
|
|
Requirements |
m |
l |
|
|
Architecture |
m |
l |
|
|
Life Cycle Plan |
m |
l |
|
|
Feasibility |
m |
l |
|
|
Prototype |
m |
l |
|
|
PERT Charts |
|
l |
|
|
Gantt Charts |
|
l |
|
|
Staffing Plans |
|
l |
|
|
Transition package |
|
|
l |
|
User Manual |
|
|
l |
|
Training material |
|
|
l |
4.6 Quality Management
Establishing appropriate code and document standards will be the responsibility of the development team. These standards should be agreed on early in the development process and adhered to by all team members. One member of the development team shall be designated as the quality control leader. Specific test plans for each component will be created by the quality leader to facilitate the process of testing the software. Each user and administrator will be required to adhere to the basic test plan and report any problems they encounter. Additionally, each tester will further test the software by attempting to place the software in an unknown (and unplanned) state. Further testing of the database will be accomplished through virtue of the user testing. Following each formal system test, a document shall be prepared which contains all discrepancies against the set requirements found as well as any suggestions which may enhance the system functionality. The discrepancies will be assigned a priority and shall be fixed before the next scheduled test.
4.7 Facilities and Related Concerns
Existing facilities will be used for the deployment of the WWI-AE system. The Digital Library and related web server are provided and maintained by ISD. Network services for connection to the WWI-AE system are already provided and maintained by ISD.
Scanning of all artifacts will be accomplished by the Customized Computer Publishing department within ISD. As such, all scanning equipment will be maintained by ISD-CCP. Scanned artifacts will be provided to the WWI-AE administrators on a predetermined storage medium (tape, network, CD-R, etc).
4.8 Status monitoring and Control
The project tracking can be done by the project manager by using the charts provided in the LCP as the basis. The PERT charts can be used to track the critical path quantities. The Gantt charts can be used to determine the effort required for these activities.
Process control will be managed by the designated project manager. The project manager will be responsible for maintaining a binder will current copies of all documentation related to the project. This includes all change reports, quality documents and inspection reports. The project manager is also responsible for keeping the development on schedule according to the milestones given in Section 2.2.2. The use of metrics or schedule tracking is left to the discretion of the team leader, but a minimum of a textual calendar containing all milestones and deadlines shall be created and maintained. Finally, the project leader must also oversee the Transition Readiness Review and create a plan as described in Section 4.3.5.
Another team member will be designated as the quality control leader. This member will be responsible for creating testing plans and change management documents as required. Coordinating testing with designated users and tracking the results of each test are also the responsibility of the quality control leader. All documents created by the quality control leader shall be stored in the project binder. The team as a whole will decide on the necessity of and implementation details of any internal deliverables such as informal code inspections and coding guidelines
5. Resources
This section describes the various tasks involved in developing the system, it uses a work breakdown structure to depict this information. It also provides an estimate of the cost of developing the system.
5.1 Work Breakdown Structure
The Work breakdown structure (WBS) shown below provides a hierarchical ordering of project tasks and activities that are essential for cost estimation, project tracking and control.
The people and organizations responsible for the above tasks are listed below:
The management (S1) of the entire project is done by the 577 course. The 577a team mainly performs the system engineering (S2) part and the prototyping for the various modules (SA, SB, SC, and SD) and the architecture (SA2, SB2). The 577b team is responsible for detailed design and the entire modules. It is also responsible for preparing the manuals (S5) and testing the entire system (S4). The VKC library is responsible for the implementation (S6) of the system and ISD is responsible for the maintenance (S7).
5.2 Budgets
The estimated cost of the project has been calculated using the COCOMO tool. The estimate based on the number of source instructions is as shown below.
The estimate above shows the five modules, the most likely estimate of effort required is
Adjusted Effort estimate = 8.9 person months.
The above estimate schedule is based on the assumption that people work 152 hours a month. However students will not be devoting their entire time to the project as they might be doing other courses. Hence we assume that they will put in 20 hours a week. Also, the number of students in the team is assumed to be 5.
Schedule = Effort = 8.9 = 1.78 months = 1.78 X 152 = 270.56 hours
FSP 5
At 20 hours a week, the number of hours spent during a month is
No. of hours spent by a student working on the course = 20 X 4.5 = 90
Thus number of months required to develop IOC is,
Estimated time = Schedule = 270.56 = 3 months = 13.5 weeks
No. of hours working 90
Using the Object point approach, the calculation of the estimate is :
Based on the prototype the user interface will have 9 screens and the administrator interface about 7. The complexity of these is medium and hence a complexity weight of 1 is used. There will be five modules to be developed and two of them are difficult, hence a complexity weight of 10 is used for them.
NOP = (16 X 1 + 2 X 10 + 3 X 1) X (85) = 33.15
100
If PROD = 4 then PM = NOP = 33.15 = 8.3
PROD 4
This is quite comparable to the estimate obtained using the lines of code. If we proceed in a similar fashion as above we get the following estimate for schedule.
Schedule = Effort = 8.3 = 1.66 months = 1.66 X 152 = 252.32 hours
FSP 5
Thus number of months required to develop IOC is,
Estimated time = Schedule = 252.32 = 2.8 months = 12.6 weeks
No. of hours working 90
6. Assumptions
This part is used to describe the circumstances and conditions under which the above estimates will hold. This section will change as the system evolves. At this point of time, many of the necessary details are not known. The assumptions that have been made above are as follows: