Ui Maintenance Management System - Project Plan

FAKULTAS ILMU KOMPUTER UNIVERSITAS INDONESIA

UI Maintenance Management System

January 12, 2003 Jeremias Tanamal Yudha Sanyoto L. Didi Andrianto A. Sasmito Adibowo Moh Aditya MH

Daftar Isi About this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Project Stakeholders . . . Project Sponsors . . Resource Providers Candidate Users . . Potential Users . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 5 5 6 6

Team Task Descriptions Project Manager . Technical Writers System Architect System Analysts . Programmers . . . Testers . . . . . . . . Trainers . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6 6 6 7 7 7 7 7

. . . . . . . .

Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Schedule Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Schedule Task Descriptions . . . . . . . . Meetings . . . . . . . . . . . . . . . . . . Product Documentation . . . . . . Requirements . . . . . . . . . . . . . . Training/Orientation . . . . . . . . Preliminary Design/Prototyping Detailed Design . . . . . . . . . . . . Construction . . . . . . . . . . . . . . Change Management . . . . . . . . Deployment . . . . . . . . . . . . . . . Closeout . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

.9 .9 .9 10 10 10 10 11 12 12 12

Project Deliverables . . . . . . . . . Project Plan . . . . . . . . . . Requirements Document Design Document . . . . . . Final Project Notebook . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

12 12 13 13 13

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Communications Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Project Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Existing Systems . . . . . . . . . . . . . . . . . . . . . . . Method for Updating the Communications Plan Other Communications Information . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

14 14 15 15

Quality Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Quality Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Quality Assurance Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Risk Identification and Mitigation . . . . . . . . . List of risks and cause or circumstance Impact Assessment Table . . . . . . . . . . . Risk Table . . . . . . . . . . . . . . . . . . . . . . Risks . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 17 18 19 19

Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Halaman 3 dari 20

1

About this Document

This document contains descriptions of the project. In this document you will find : 1. Problem description 2. Solution strategy 3. Information System Description 4. Team organization structure 5. Propose Stakeholder

2

Project Description

2.1

Problem Statement

The University of Indonesia possesses a vast number of facilities located within its two campus complexes. The primary campus complex located in Depok, Jawa Barat, houses the majority of its faculty buildings in several acres of land. Alternately, the satellite campus located in Jakarta houses a smaller number of buildings. These facilities range from standard classroom and office equipment to medical supplies to highly sophisticated research tools. Even when observed at-a-glance it is apparent that the maintenance of these facilities is sub-optimal. There are equipments that are still in use even though they need to be replaced. Some other are under-used because of the lack of access or because of political constraints. Analogical to the tip of the iceberg, the problem mentioned earlier are only a small amount of the real problem. Zooming into other aspects such as inventory management and accounting processes concerning those facilities will reveal other subliminal matters. These problems include: •

Lost/damaged items went unnoticed.

•

Difficulty in procurement of equipment.

•

Under-depreciated equipment value.

•

Poorly-maintained equipment leading to lower use-life expectancy.

•

Neglected equipment which leads to poor maintenance.

•

Social loafing or “passing the buck” when it comes to maintaining equipment.

Halaman 4 dari 20

2.2

Proposed Solution

In relation to the problems mentioned earlier, we propose to build and deploy a computerized information system that addresses University of Indonesia’s facility maintenance management. The system is targeted to be used by all levels in the organization: from the janitors to the students to the administration staff, and up to the rectorate. After successful use within the university, the product will be targeted for commercial use in other universities. Building, deploying, and selling this system will provide several other benefits to the university apart from solving the original problem: •

Identification and aggregation of skilled people that work within the university.

•

Better brand recognition of the university in the field of computerized information systems.

•

Financial benefits obtained from the system’s licensing and training services.

3

Project Stakeholders

3.1

Project Sponsors

3.1.1 University of Indonesia’s Rectorate 3.1.2 Quality for Undergraduate Education 3.1.3 Indonesian Directorate of High Education 3.2

Resource Providers

3.2.1 Faculty of Computer Science As the primary resource provider, the Faculty of Computer Science will provide resources for system analysis, design, and construction. 3.2.2 Faculty of Engineering The Faculty of Engineering shall participate primarily in the areas of hardware and infrastructure implementation. 3.2.3 Faculty of Psychology Assistance from the Faculty of Psychology is required in areas such as user interface design, change management, and user training. 3.2.4 Faculty of Economics Upon completion of the project, the Faculty of Economics will carry on the project further to market the completed product.

Halaman 5 dari 20

3.3

Candidate Users

3.3.1 Maintenance Staff The maintenance staff will be the primary users of the system. It will provide functionalities for facility data capture and assistance for facility maintenance. 3.3.2 Administrative Staff The administrative staff will validate, maintain, and dispatch the data that are input by the maintenance staff. 3.3.3 Management Staff The system will provide management decision-support functionalities that assist management staff in decision making. 3.3.4 Students Students of the university are also provided with some access to the system through their own private electronic devices (such as data-enabled mobile phones) and official terminals designated for their use. 3.4

Potential Users

3.4.1 Other Universities and/or Educational Institutes Upon success of the system within the university, the system will be made available commercially for use in other universities. 3.4.2 University of Indonesia’s Marketing staff The marketing staff may obtain information about the facilities to assist them in promoting the university. 3.4.3 Guests and/or candidate students The general public will be provided with some read-only access to the information in the system through a publicly-accessible network.

4

Team Task Descriptions

The project team is divided into several major roles, which are divided among and shared by the members. Here are descriptions of the roles: 4.1

Project Manager

The manager is responsible for preparing, maintaining, and enforcing the project schedule, organizing and leading the project meetings, and interacting with the project sponsor where necessary. 4.2

Technical Writers

Halaman 6 dari 20

The technical writer is responsible for preparing and maintaining all Duration 297 days?

Start Mon 21-04-03

02 09 Mar '03 25 May '03 Finish F S S M T Thu 01-07-04

ID 1

Task Name Meetings

14

Product Documentation

42 days?

Fri 16-01-04

19

Requirements

56 days?

Thu 22-05-03

Fri 08-08-03

24

Training/Orientation

17 days?

Thu 22-05-03

Mon 16-06-03

32

Preliminary Design/Prototyping

35 days?

Mon 23-06-03

Fri 08-08-03

35

Detailed Design

49 days?

Mon 11-08-03

Fri 17-10-03

42

Construction

84 days?

Mon 20-10-03

Thu 26-02-04

50

Change Management

182 days?

Fri 11-07-03

Wed 07-04-04

54

Deployment

45 days?

Fri 19-03-04

Fri 21-05-04

57

Closeout

35 days?

Mon 24-05-04

Mon 12-07-04

61

Project Complete

0 days

Mon 12-07-04

Mon 12-07-04

10 Aug '03 W T

26 Oct '03 F S

11 Jan '04 S M

28 Mar '04 T W

13 Jun '04 T F

Thu 18-03-04

12

documentation and reports for the project, both internal and external. This includes the project notebook and all other Web-based documentation. 4.3

System Architect

The architect is the head technical member of the team. He is responsible for the high-level design aspects of the project, and for organizing the implementation of the design. The architect knows the "big picture" and understands and documents the overall organization of the system. 4.4

System Analysts

The system analysts will be responsible for gathering and finalizing the system requirements specification. 4.5

Programmers

The programmers are responsible for learning the Java programming language and training other members as necessary. The programmers perform the actual implementation and testing of the system under the direction of and in conjunction with the architect. The programmers handle the details of bringing the system to an operational software. 4.6

Testers

The testers are responsible for ensuring that the system works properly and reliably as adhering to the requirements as possible. 4.7

Trainers

The trainers will be responsible for facilitating changes to the organization as the system is deployed and put into operation. Specifically, they will perform the initial socialization, user education, and training.

5

Project Schedule

5.1

Schedule Overview

This project is planned to start at April 21, 2003 and planned to end at July 12, 2004

Halaman 7 dari 20

5.2

Milestones

5.2.1 Final Requirements Document Final requirements document is planned to complete at august 8, 2003 This document tells about requirements elicitation, requirement formalization and requirements validation 5.2.2 Final Design Document Final design document is planned to complete at October 17, 2003 5.2.3 Code Complete Coding application is planned to complete at February 26, 2004 5.2.4 Team Certification Team Certification is planned to complete at June 16, 2003 5.2.5 Final Product Documentation Final product documentation is planned to complete at March 18, 2004

Halaman 8 dari 20

5.2.6 Project Complete Whole project is planned to complete at June 22, 2004

6

Schedule Task Descriptions

6.1

Meetings

Description & Roles: During the project, meeting is held 12 times : Role Name Meeting Name

Project Sponsor

Candidate Users

Project Manager

Project Initiation

/

/

/

Team Formation

/

Final Project Plan

/

System Analyst

Technical Writer

System Architect

Progr ammers

/

/

/

/

/

/

/

/

/

/

/

Platform Evaluation

/

/

Development Tools Evaluation

/

/

/

/

/

Platform & Tools Freeze

/

/

/

/

/

Design Freeze

/

/

/

/

/

Code Freeze

/

/

/

/

/

/

/

/

Pre-Deployment Meeting PostDeployment Meeting

/

/

/

Closeout Meeting

/

/

/

6.2

Trainers

/ /

Requirements Freeze

Testers

/

/

/

/

/

/

Product Documentation

6.2.1 Description There are three documents that will be produced as part of the end-product of this project. •

System Description

•

Administrator's Guide Halaman 9 dari 20

•

User's Guide

6.2.2 Roles :Project Manager, Technical Writer, System Architect, System Analyst 6.3

Requirements

6.3.1 Description All functional requirements of the system must initially be assessed. This includes storyboarding potential user scenarios, demonstrating how the system will look and be used. Requirements assessment also includes evaluation of the testing needs and any non-functional requirements related to testing the system for acceptability. Roles: 6.3.2 Roles Manager, Architect, Programmers, Technical Writer 6.4

Training/Orientation

6.4.1 Description After the application is done, then the user must be trained in order they can operate the application developed 6.4.2 Roles : Trainer,User. 6.5

Preliminary Design/Prototyping

6.5.1 Description This is the earliest stage of design, consisting primarily of "brainstorming", leading up the the initial basis for analyzing the requirements of the system. This also includes the high-level architectural layout of the system. 6.5.2 Roles Manager, Architect, Programmers, Technical Writer

6.6

Detailed Design

Description The detailed design phase consists of the lower-level architectural design and detailing of the modules that the programmers will be implementing. Halaman 10 dari 20

6.6.1 Roles Manager (2 hrs.), Architect (10 hrs.), Programmers (10 hrs.), Technical Writer (3 hrs.) 6.7

Construction

6.7.1 Coding Description: This will be the time spent writing the initial system, as directed by the architect's design. Roles: Architect (20 hrs.), Programmers (50 hrs.) 6.7.2 Pre-Integration Testing Description: This is the phase of module-level testing prior to the integration of the system's separate software components. It will include any necessary code modifications in reponse to test results. Roles: Manager (2 hrs.), Architect (10 hrs.), Programmers (10 hrs.), Technical Writer (3 hrs.) 6.7.3 Integration Description: After pre-integration testing has shown the system components to be functioning nominally, the modules will be integrated into a complete system. This system is the final (or "final prototype") of the financial manager. Roles: Architect (15 hrs.), Programmers (20 hrs.) 6.7.4 Post-Integration Testing Description: This is the phase of system-level testing following the integration of the system's separate software components. It will include any necessary code modifications in reponse to test results. Roles: Manager (20 hrs.), Architect (30 hrs.), Programmers (35 hrs.), Technical Writer (15 hrs.)

Halaman 11 dari 20

6.7.5 Modification / Enhancements Description: This will be the final phase, in which the entire system will be "cleaned up" and finalized for delivery. Time permitting, this phase will also allow for the addition of some additional "perks"to the final system. Roles: Manager (5 hrs.), Architect (5 hrs.), Programmers (10 hrs.), Technical Writer (10 hrs.) 6.8

Change Management

6.8.1 Description If there are management change, then new user must be trained again, in order they can operate the system 6.8.2 Roles : Trainer, User 6.9

Deployment

6.9.1 Description Before the application is used in the institution, first it must be deployed at targeted computer. 6.9.2 Roles Tester, Project Manager, User, Trainer, System Analyst 6.10

Closeout

After the project is finished, then there would be held a closeout meeting . In this meeting, project manager report the overall project.

7

Project Deliverables

There are four formal documents required for this project. Detailed descriptions of the requirements for each of these documents can be found on the Project Milestones page. The deliverables are: Project Start Date: April 4, 2003 7.1

Project Plan

Due: 21 May 2003

Halaman 12 dari 20

The Project Plan (finalization of this document) is a brief introduction to the project team members and a preliminary schedule and breakdown of the project's activities. 7.2

Requirements Document

Due: 8 August 2003 The Requirements Document is an "extended document that details all functional requirements of the delivered prototype. A section of this document also indicates nonfunctional requirements that will be used to test the system for acceptability and a storyboard that will be used to demonstrate how the system will look and be used." 7.3

Design Document

Due: 17 October 2003 The Design Document is a "detailed description of how the system will be built, including, for example, any object-oriented analysis and design to show the system structure." 7.4

Final Project Notebook

Due: 2 July 2004 The Final Project Notebook is a "final collection of all of the above information in a well-organized Web page." It will include all revisions of all of the documents and provide access to the system's source code.

8

Communications Plan

Halaman 13 dari 20

Stakeholder

Message/Information Need

Delivery Vehicle

Frequency

Feedback

Project Sponsor

Project sponsor needs infornation from project manager about project documents and also about progress report.

By courier

Weekly

Provide other stakeholder about what other stakeholder need

Project

Project Manager must receive input from Project Team members about the progress of the project. He also needs information from internal and external stakeholders about their information and communications requirements, determine the best and most cost effective way in which the requirements can be met, and record the information in a formal, approved document.

By courier and meeting

Weekly

Communicate with other stakeholder and coordinate with project team member

Project Team Member

Project Team Member needs the detailed task from Project manager and material from other stakeholder

By meeting

Weekly

Provide information to project manager and other stakeholder about the progress has been made.

Other Stakeholder

Needs information especially on project progress report, and other informations

Meeting and courier

Weekly

Provide data and other informations to other stakeholder

Manager

8.1

Existing Systems

Halaman 14 dari 20

Currently University of Indonesia uses electronic system such as telephone and also uses courier from its internal employees. But the use of internet or e-mail has not so common. 8.2

Method for Updating the Communications Plan

We suggest the use of internet facility such as email as method of communication, besides the conventional methods such as meeting. But if the meeting cannot be held , we suggest the use of video conference techology as a method of communication. 8.3

Other Communications Information

Other kinds of information are the responsibility of the project manager. So project manager must often inform other stakeholders especially on the progress of the project.

9

Quality Plan

9.1

Quality Policy

•

Properly documented system architecture.

•

Properly documented source code - hypertext document with detailed descriptions for all classes, properties, and methods.

•

Properly documented database schema.

•

The system will be user-friendly.

•

The user's manual will be separated into several parts: tutorial, reference, and system administration.

9.2

Quality Assurance Activities

•

Ensure that the programmers properly document their code.

•

Ensure a System Description document exists and easily understandable.

•

Ensure the requirements specifications are complete and concise.

•

Ensure the database design is properly documented.

•

Performs user test often.

•

Reviews the manuscripts for the user manuals.

10

Risk Identification and Mitigation

Halaman 15 dari 20

We will adopt the Software Institutes seven principles of effective risk management. They are global perspective, forward-looking view, open communication, integrated management, continuous process, shared product vision, and teamwork. •

Global perspective. Viewing software development within the context of the larger systems-level definition, design, and development. Recognizing both the potential value of opportunity and the potential impact of adverse effects.

•

Forward looking view Thinking toward tomorrow, identifying uncertainties, anticipating potential outcomes. Managing project resources and activities while anticipating uncertainties.

•

Open communication Encouraging free-flowing information at and between all project levels. Enabling formal, informal, and impromptu communication. Using processes that value the individual voice (bringing unique knowledge and insight to identifying and managing risk).

•

Integrated management Making risk management an integral and vital part of project management. Adapting risk management methods and tools to a project's infrastructure and culture

•

Continuous process Sustaining constant vigilance and identifying and managing risks routinely through all phases of the project's life cycle.

•

Shared project vision Mutual product vision based on common purpose, shared ownership, and collective communication and focusing on results.

•

Teamwork working cooperatively to achieve a common goal. Pooling talents, skills, and knowledge.

Found at http://www.sei.cmu.edu/programs/sepm/risk/principles.html Our primary goal in project risk assessment is to design a risk management system that would identify all the risks that might effect our project. We then prioritized all the risks and sorted them as to their priority. The first thing we did was to create a risk category table that would bound all the risk into one category or another. The main subjects that bounded are risks product size, business impact, customer characteristics, process definition, development environment, technology to be built, scheduling risks, and staff Halaman 16 dari 20

size and experience (Pressman 1997). Each subject of risks was then broken down into all the potential risks (appendix). We found that 11 risks were worth further investigation with three of the these standing out from the others.

10.1

List of risks and cause or circumstance

•

Estimated size of project in LOC or FP Due to the lack of experience that the project planners have we rated this risk as critical and with a very high chance of occurring. The relative inexperience of the programmers also play apart in this assessment.

•

Lack of needed specialization increases defects and reworks We rated this as critical also with a decent chance of occurring, as the project programmers have little or no programming experience in this type of program.

•

Unfamiliar areas of the product take more time than expected to design and implement We rated this area as marginal also since the programmers are experienced with Java programming and learning Internet interface programming in Java is not difficult.

•

Does the environment make use of a database We rated this as marginal with a small chance of occurring due to the relative lack of database programming experience of the programmers.

•

Components developed separately cannot be integrated easily, requiring redesign Rated as marginal due to the intricacies of working with Java packages and interfaces.

•

Development of the wrong software functions requires redesign and implementation Rated as a marginal risk only as the programmers are relying on the expertise of the inexperienced project planners.

•

Development of extra software functions that are not needed Rated as a marginal risk due to the inexperience in Internet and Java programming on the part of the programmers.

•

Strict requirements for compatibility with existing system require more testing, design, and implementation than expected Rated as marginal since this is a new systems development and integration with existing systems is not within the scope for the initial release of the product.

•

Operations in a unfamiliar software environment causes unforeseen problems Rated as negligible as both developers and programmers have Halaman 17 dari 20

experience in other object oriented languages and some experience in the programming language of choice. •

Team members do not work well together Rated as critical since this is a cross-faculty project, the quality of teamwork may be questionable.

•

Key personnel are available only part-time Rated as negligible, again there is a possibility that circumstances could change in the future.

10.2

Impact Assessment Table

CATEGORY / COMPONENTS

PERFORMANCE

SUPPORT

Failure to meet would result in 1 mission failure CATASTROPHIC

Significant degradation to non-achievement 2 of technical performance

Nonresponsive or unsupportable software

Failure to meet the requirement would degrade system performance 1 to a point where mission success is questionable CRITICAL Some reduction in technical 2 performance

MARGINAL

Minor delays in software modifications

COST

SCHEDULE

Failure results in increased costs and schedule delays with expected values in excess of Rp 500M Significant, financial shortages, budget overrun likely

Unachievable delivery date

Failure results in operational delays and/or increased costs with expected value of Rp 100M to Rp 500M Some shortage of financial resources, possible overruns

Possible slippage in delivery date

Failure to meet the requirement would result in degradation of 1 secondary mission

Costs, impacts, and/or recoverable schedule slips with expected value of Rp 1M to Rp 100M

Minimal to small reduction in 2 technical performance

Sufficient financial resources

Responsive software support

Realistic, achievable schedule

Halaman 18 dari 20

CATEGORY / COMPONENTS

PERFORMANCE

SUPPORT

Failure to meet the requirement would create inconvenience or non1 operational impact NEGLIGIBLE

10.3

No reduction in technical 2 performance

Easily supportable software

COST

SCHEDULE

Error results in minor cost and/or schedule impact with expected value of less than Rp 1M Possible budget under run

Early achievable date

Risk Table

Risks Estimated size of project in LOC or FP Lack of needed specialization increases defects and reworks Unfamiliar areas of the product take more time than expected to design and implement Does the environment make use of a database Components developed separately cannot be integrated easily, requiring redesign Development of the wrong software functions requires redesign and implementation Development of extra software functions that are not needed Strict requirements for compatibility with existing system require more testing, design, and implementation than expected Operation in unfamiliar software environment causes unforeseen problems Team members do not work well together Key personnel are available only part-time

10.3.1 PS TE DE ST EV

Category

Probability

Impact

PS ST

80% 50%

2 2

DE

25%

3

DE

35%

3

DE

25%

3

DE

25%

3

DE

20%

3

DE

20%

3

EV

25%

4

ST ST

80% 20%

2 4

Categories / project size risk / technology risk / development risk / personnel or staff risk / environment

10.3.2 Probability This is the chance of the risk coming to fruition. 10.3.3 1. 2. 3.

Impact Catastrophic Critical Marginal Halaman 19 dari 20

4.

Negligible

11

Appendixes

• • •

Project Schedule Gantt Chart Detailed Work Breakdown

Halaman 20 dari 20