FAKULTAS ILMU KOMPUTERUNIVERSITAS INDONESIA

UI Maintenance Management System

January 12, 2003

Jeremias TanamalYudha SanyotoL. Didi Andrianto

A. Sasmito AdibowoMoh Aditya MH

Daftar Isi

About this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Project Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Project Sponsors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Resource Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Candidate Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Potential Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

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

Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Schedule Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Schedule Task Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Training/Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Preliminary Design/Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Closeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

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

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

Halaman 3 dari 20

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

Quality Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Quality Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Quality Assurance Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Risk Identification and Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15List of risks and cause or circumstance . . . . . . . . . . . . . . . . . . . . . 17Impact Assessment Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Risk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

Halaman 4 dari 20

1 About this DocumentThis document contains descriptions of the project. In this document youwill find :

1. Problem description

2. Solution strategy

3. Information System Description

4. Team organization structure

5. Propose Stakeholder

2 Project Description

2.1 Problem StatementThe University of Indonesia possesses a vast number of facilities locatedwithin its two campus complexes. The primary campus complex located inDepok, Jawa Barat, houses the majority of its faculty buildings in severalacres of land. Alternately, the satellite campus located in Jakarta houses asmaller number of buildings. These facilities range from standard classroomand office equipment to medical supplies to highly sophisticated researchtools.

Even when observed at-a-glance it is apparent that the maintenance of thesefacilities is sub-optimal. There are equipments that are still in use eventhough they need to be replaced. Some other are under-used because of thelack of access or because of political constraints.

Analogical to the tip of the iceberg, the problem mentioned earlier are only asmall amount of the real problem. Zooming into other aspects such asinventory management and accounting processes concerning those facilitieswill 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 5 dari 20

2.2 Proposed SolutionIn relation to the problems mentioned earlier, we propose to build anddeploy a computerized information system that addresses University ofIndonesia’s facility maintenance management. The system is targeted to beused by all levels in the organization: from the janitors to the students to theadministration staff, and up to the rectorate.

After successful use within the university, the product will be targeted forcommercial use in other universities. Building, deploying, and selling thissystem will provide several other benefits to the university apart from solvingthe original problem:

• Identification and aggregation of skilled people that work within theuniversity.

• Better brand recognition of the university in the field of computerizedinformation systems.

• Financial benefits obtained from the system’s licensing and trainingservices.

3 Project Stakeholders

3.1 Project Sponsors3.1.1 University of Indonesia’s Rectorate3.1.2 Quality for Undergraduate Education3.1.3 Indonesian Directorate of High Education3.2 Resource Providers3.2.1 Faculty of Computer ScienceAs the primary resource provider, the Faculty of Computer Science willprovide resources for system analysis, design, and construction.

3.2.2 Faculty of EngineeringThe Faculty of Engineering shall participate primarily in the areas ofhardware and infrastructure implementation.

3.2.3 Faculty of PsychologyAssistance from the Faculty of Psychology is required in areas such as userinterface design, change management, and user training.

3.2.4 Faculty of EconomicsUpon completion of the project, the Faculty of Economics will carry on theproject further to market the completed product.

Halaman 6 dari 20

3.3 Candidate Users3.3.1 Maintenance StaffThe maintenance staff will be the primary users of the system. It will providefunctionalities for facility data capture and assistance for facilitymaintenance.

3.3.2 Administrative StaffThe administrative staff will validate, maintain, and dispatch the data thatare input by the maintenance staff.

3.3.3 Management StaffThe system will provide management decision-support functionalities thatassist management staff in decision making.

3.3.4 StudentsStudents of the university are also provided with some access to the systemthrough their own private electronic devices (such as data-enabled mobilephones) and official terminals designated for their use.

3.4 Potential Users3.4.1 Other Universities and/or Educational InstitutesUpon success of the system within the university, the system will be madeavailable commercially for use in other universities.

3.4.2 University of Indonesia’s Marketing staffThe marketing staff may obtain information about the facilities to assistthem in promoting the university.

3.4.3 Guests and/or candidate studentsThe general public will be provided with some read-only access to theinformation in the system through a publicly-accessible network.

4 Team Task Descriptions

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

4.1 Project ManagerThe manager is responsible for preparing, maintaining, and enforcing theproject schedule, organizing and leading the project meetings, andinteracting with the project sponsor where necessary.

4.2 Technical Writers

Halaman 7 dari 20

ID Task Name Duration Start Finish1 Meetings 297 days? Mon 21-04-03 Thu 01-07-0414 Product Documentation 42 days? Fri 16-01-04 Thu 18-03-0419 Requirements 56 days? Thu 22-05-03 Fri 08-08-0324 Training/Orientation 17 days? Thu 22-05-03 Mon 16-06-0332 Preliminary Design/Prototyping 35 days? Mon 23-06-03 Fri 08-08-0335 Detailed Design 49 days? Mon 11-08-03 Fri 17-10-0342 Construction 84 days? Mon 20-10-03 Thu 26-02-0450 Change Management 182 days? Fri 11-07-03 Wed 07-04-0454 Deployment 45 days? Fri 19-03-04 Fri 21-05-0457 Closeout 35 days? Mon 24-05-04 Mon 12-07-0461 Project Complete 0 days Mon 12-07-04 Mon 12-07-04 12

F S S M T W T F S S M T W T F02 09 Mar '03 25 May '03 10 Aug '03 26 Oct '03 11 Jan '04 28 Mar '04 13 Jun '04

The technical writer is responsible for preparing and maintaining all

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

4.3 System ArchitectThe architect is the head technical member of the team. He is responsible forthe high-level design aspects of the project, and for organizing theimplementation of the design. The architect knows the "big picture" andunderstands and documents the overall organization of the system.

4.4 System AnalystsThe system analysts will be responsible for gathering and finalizing thesystem requirements specification.

4.5 ProgrammersThe programmers are responsible for learning the Java programminglanguage and training other members as necessary. The programmersperform the actual implementation and testing of the system under thedirection of and in conjunction with the architect. The programmers handlethe details of bringing the system to an operational software. 4.6 TestersThe testers are responsible for ensuring that the system works properly andreliably as adhering to the requirements as possible.

4.7 TrainersThe trainers will be responsible for facilitating changes to the organization asthe system is deployed and put into operation. Specifically, they will performthe initial socialization, user education, and training.

5 Project Schedule

5.1 Schedule OverviewThis project is planned to start at April 21, 2003 and planned to end at July12, 2004

Halaman 8 dari 20

5.2 Milestones

5.2.1 Final Requirements DocumentFinal requirements document is planned to complete at august 8, 2003This document tells about requirements elicitation, requirementformalization and requirements validation

5.2.2 Final Design DocumentFinal design document is planned to complete at October 17, 2003

5.2.3 Code CompleteCoding application is planned to complete at February 26, 2004

5.2.4 Team CertificationTeam Certification is planned to complete at June 16, 2003

5.2.5 Final Product DocumentationFinal product documentation is planned to complete at March 18, 2004

Halaman 9 dari 20

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

6 Schedule Task Descriptions

6.1 MeetingsDescription & Roles: During the project, meeting is held 12 times :

Role Name

Meeting Name ProjectSponsor

Candi-dateUsers

ProjectManager

SystemAnalyst

Techni-calWriter

SystemArchitect

Program-mers

Testers Trainers

Project Initiation / / /

Team Formation / /

Final ProjectPlan

/ / / / / / /

RequirementsFreeze

/ / / / / /

PlatformEvaluation

/ / / /

DevelopmentToolsEvaluation

/ / / / /

Platform &Tools Freeze

/ / / / /

Design Freeze / / / / /

Code Freeze / / / / /

Pre-DeploymentMeeting

/ / / / /

Post-DeploymentMeeting

/ / / / /

CloseoutMeeting

/ / /

6.2 Product Documentation6.2.1 DescriptionThere are three documents that will be produced as part of the end-productof this project.• System Description• Administrator's Guide

Halaman 10 dari 20

• User's Guide

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

6.3 Requirements6.3.1 DescriptionAll functional requirements of the system must initially be assessed. Thisincludes storyboarding potential user scenarios, demonstrating how thesystem will look and be used. Requirements assessment also includesevaluation of the testing needs and any non-functional requirements relatedto testing the system for acceptability. Roles:

6.3.2 RolesManager, Architect, Programmers, Technical Writer

6.4 Training/Orientation6.4.1 DescriptionAfter the application is done, then the user must be trained in order theycan operate the application developed

6.4.2 Roles : Trainer,User. 6.5 Preliminary Design/Prototyping6.5.1 DescriptionThis 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 RolesManager, Architect, Programmers, Technical Writer

6.6 Detailed DesignDescriptionThe detailed design phase consists of the lower-level architectural design anddetailing of the modules that the programmers will be implementing.

Halaman 11 dari 20

6.6.1 RolesManager (2 hrs.), Architect (10 hrs.), Programmers (10 hrs.), Technical Writer(3 hrs.)

6.7 Construction6.7.1 CodingDescription: This will be the time spent writing the initial system, as directed by thearchitect's design. Roles: Architect (20 hrs.), Programmers (50 hrs.)

6.7.2 Pre-Integration TestingDescription: This is the phase of module-level testing prior to the integration of thesystem's separate software components. It will include any necessary codemodifications in reponse to test results. Roles: Manager (2 hrs.), Architect (10 hrs.), Programmers (10 hrs.), Technical Writer(3 hrs.)6.7.3 IntegrationDescription: After pre-integration testing has shown the system components to befunctioning nominally, the modules will be integrated into a completesystem. This system is the final (or "final prototype") of the financialmanager. Roles: Architect (15 hrs.), Programmers (20 hrs.)6.7.4 Post-Integration TestingDescription: This is the phase of system-level testing following the integration of thesystem's separate software components. It will include any necessary codemodifications in reponse to test results. Roles: Manager (20 hrs.), Architect (30 hrs.), Programmers (35 hrs.), TechnicalWriter (15 hrs.)

Halaman 12 dari 20

6.7.5 Modification / EnhancementsDescription: 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 theaddition 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 Management6.8.1 DescriptionIf there are management change, then new user must be trained again, inorder they can operate the system

6.8.2 Roles : Trainer, User6.9 Deployment6.9.1 DescriptionBefore the application is used in the institution, first it must be deployed attargeted computer. 6.9.2 RolesTester, Project Manager, User, Trainer, System Analyst

6.10 CloseoutAfter 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. Detaileddescriptions of the requirements for each of these documents can be foundon the Project Milestones page. The deliverables are: Project Start Date: April 4, 20037.1 Project PlanDue: 21 May 2003

Halaman 13 dari 20

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

7.2 Requirements DocumentDue: 8 August 2003

The Requirements Document is an "extended document that details allfunctional requirements of the delivered prototype. A section of thisdocument also indicates nonfunctional requirements that will be used to testthe system for acceptability and a storyboard that will be used todemonstrate how the system will look and be used."

7.3 Design DocumentDue: 17 October 2003

The Design Document is a "detailed description of how the system will bebuilt, including, for example, any object-oriented analysis and design toshow the system structure."

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

8 Communications Plan

Halaman 14 dari 20

Stakeholder Message/InformationNeed

DeliveryVehicle

Frequency Feedback

ProjectSponsor

Project sponsor needsinfornation from projectmanager about projectdocuments and also aboutprogress report.

Bycourier

Weekly Provide otherstakeholderabout whatotherstakeholderneed

ProjectManager

Project Manager mustreceive input from ProjectTeam members about theprogress of the project. Healso needs informationfrom internal and externalstakeholders about theirinformation andcommunicationsrequirements, determinethe best and most costeffective way in which therequirements can be met,and record the informationin a formal, approveddocument.

Bycourierandmeeting

Weekly Communicatewith otherstakeholder andcoordinate withproject teammember

Project TeamMember

Project Team Memberneeds the detailed task from Project manager andmaterial from otherstakeholder

Bymeeting

Weekly Provideinformation toprojectmanager andotherstakeholderabout theprogress hasbeen made.

OtherStakeholder

Needs informationespecially on projectprogress report, and otherinformations

Meetingandcourier

Weekly Provide dataand otherinformations tootherstakeholder

8.1 Existing Systems

Halaman 15 dari 20

Currently University of Indonesia uses electronic system such as telephoneand also uses courier from its internal employees. But the use of internet ore-mail has not so common.

8.2 Method for Updating the Communications PlanWe suggest the use of internet facility such as email as method ofcommunication, besides the conventional methods such as meeting. But ifthe meeting cannot be held , we suggest the use of video conferencetechology as a method of communication.

8.3 Other Communications InformationOther kinds of information are the responsibility of the project manager. Soproject manager must often inform other stakeholders especially on theprogress 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 16 dari 20

We will adopt the Software Institutes seven principles of effective riskmanagement. They are global perspective, forward-looking view, opencommunication, integrated management, continuous process, sharedproduct vision, and teamwork.

• Global perspective.Viewing software development within the context of the largersystems-level definition, design, and development. Recognizing boththe potential value of opportunity and the potential impact of adverseeffects.

• Forward looking viewThinking toward tomorrow, identifying uncertainties, anticipatingpotential outcomes. Managing project resources and activities whileanticipating uncertainties.

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

• Integrated managementMaking risk management an integral and vital part of projectmanagement. Adapting risk management methods and tools to aproject's infrastructure and culture

• Continuous processSustaining constant vigilance and identifying and managing risksroutinely through all phases of the project's life cycle.

• Shared project visionMutual 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 managementsystem that would identify all the risks that might effect our project. Wethen prioritized all the risks and sorted them as to their priority. The firstthing we did was to create a risk category table that would bound all the riskinto one category or another. The main subjects that bounded are risksproduct size, business impact, customer characteristics, process definition,development environment, technology to be built, scheduling risks, and staff

Halaman 17 dari 20

size and experience (Pressman 1997). Each subject of risks was then brokendown into all the potential risks (appendix). We found that 11 risks wereworth further investigation with three of the these standing out from theothers.

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 ratedthis risk as critical and with a very high chance of occurring. Therelative inexperience of the programmers also play apart in thisassessment.

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

• Unfamiliar areas of the product take more time than expected todesign and implement We rated this area as marginal also since the programmers areexperienced with Java programming and learning Internet interfaceprogramming 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 therelative 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 Javapackages and interfaces.

• Development of the wrong software functions requires redesign andimplementation Rated as a marginal risk only as the programmers are relying on theexpertise 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 Javaprogramming on the part of the programmers.

• Strict requirements for compatibility with existing system require moretesting, design, and implementation than expected Rated as marginal since this is a new systems development andintegration with existing systems is not within the scope for the initialrelease of the product.

• Operations in a unfamiliar software environment causes unforeseenproblems Rated as negligible as both developers and programmers have

Halaman 18 dari 20

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

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

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

10.2 Impact Assessment Table

CATEGORY /COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE

CATASTROPHIC

1Failure to meet would result inmission failure

Failure results in increasedcosts and schedule delayswith expected values inexcess of Rp 500M

2

Significantdegradation tonon-achievementof technicalperformance

Non-responsive orunsupportablesoftware

Significant,financialshortages,budgetoverrunlikely

Unachievabledelivery date

CRITICAL

1

Failure to meet the requirementwould degrade system performanceto a point where mission success isquestionable

Failure results in operationaldelays and/or increasedcosts with expected value ofRp 100M to Rp 500M

2Some reduction intechnicalperformance

Minor delaysin softwaremodifications

Someshortage offinancialresources,possibleoverruns

Possibleslippage indelivery date

MARGINAL

1

Failure to meet the requirementwould result in degradation ofsecondary mission

Costs, impacts, and/orrecoverable schedule slipswith expected value ofRp 1M to Rp 100M

2

Minimal to smallreduction intechnicalperformance

Responsivesoftwaresupport

Sufficientfinancialresources

Realistic,achievableschedule

CATEGORY /COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE

Halaman 19 dari 20

NEGLIGIBLE

1

Failure to meet the requirementwould create inconvenience or non-operational impact

Error results in minor costand/or schedule impact withexpected value of less thanRp 1M

2

No reduction intechnicalperformance

Easilysupportablesoftware

Possiblebudgetunder run

Earlyachievabledate

10.3 Risk TableRisks Category Probability Impact

Estimated size of project in LOC or FP PS 80% 2Lack of needed specialization increasesdefects and reworks

ST 50% 2

Unfamiliar areas of the product take moretime than expected to design and implement

DE 25% 3

Does the environment make use of adatabase

DE 35% 3

Components developed separately cannotbe integrated easily, requiring redesign

DE 25% 3

Development of the wrong softwarefunctions requires redesign andimplementation

DE 25% 3

Development of extra software functionsthat are not needed

DE 20% 3

Strict requirements for compatibility withexisting system require more testing,design, and implementation than expected

DE 20% 3

Operation in unfamiliar softwareenvironment causes unforeseen problems

EV 25% 4

Team members do not work well together ST 80% 2Key personnel are available only part-time ST 20% 4

10.3.1 CategoriesPS / project size riskTE / technology riskDE / development riskST / personnel or staff riskEV / environment

10.3.2 Probability This is the chance of the risk coming to fruition.

10.3.3 Impact 1. Catastrophic2. Critical3. Marginal

Halaman 20 dari 20

4. Negligible

11 Appendixes• Project Schedule• Gantt Chart• Detailed Work Breakdown