Facility Maintenance Management System
Jeremias Tanamal Yudha Sanyoto L. Didi Andrianto A. Sasmito Adibowo Moh Aditya MH
Project Description Problem Statement
’Sub-optimal facility maintenance ’Lost/damaged items went unnoticed. ’Difficulty in procurement of equipment. ’Under-depreciated equipment value. ’Poorly-maintained equipment leading to lower use-life expectancy.
Project Description Proposed Solution
’Computerized information system targeted for facility management ’For use by janitors, students, staffs, and managers ’To be sold as a commercial product
Project Description Additional Benefits
’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.
Project Stakeholders Project Sponsors
’University of Indonesia's Rectorate ’Quality for Undergraduate Education ’Indonesian Directorate of High Education
Project Stakeholders Resource Providers
’Faculty of Computer Science ’Faculty of Engineering ’Faculty of Psychology ’Faculty of Economics
Project Stakeholders Candidate Users
’Maintenance Staff ’Administrative Staff ’Management Staff ’Students
Project Team ’Project Manager ’Technical Writer ’System Analyst ’System Architect ’Programmers ’Testers ’Trainers
Project Schedule Gannt Overview ID 1
Task Name Meetings
14
Product Documentation
19
Requirements
24
Training/Orientation
32
Preliminary Design/Prototyping
35
Detailed Design
42
Construction
50
Change Management
54
Deployment
57
Closeout
61
Project Complete
March 02-03
30-03
May 27-04
25-05
July 22-06 20-07
September November January March 17-08 14-09 12-10 09-11 07-12 04-01 01-02 29-02
28-03
May 25-04
23-05
July 20-06
18-07 27-02
22-06
Project Schedule Milestones
’Start: April 21, 2003 ’Final Requirements Document: August 8, 2003 ’Final Design Document: October 17, 2003 ’Code Complete: February 26, 2004 ’Team Certification: June 16, 2003 ’Final Product Documentation: March 18, 2004 ’Project Complete: June 22, 2004
Quality Plan Policies ’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.
Quality Plan Quality Assurance ’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.
Communication Plan Project Sponsor ’Message/Information Need
’ Project sponsor needs infornation from project manager about project documents and also about progress report.
’Delivery Vehicle ’ By Courier
’Frequency ’ Weekly
’Feedback
’ Provide other stakeholder about what other stakeholder need
Communication Plan Project Manager ’Message/Information Need
’ 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.
’Delivery Vehicle
’ By courier and meeting
’Frequency ’ Weekly
’Feedback
’ Communicate with other stakeholder and coordinate with project team member
Communication Plan Project Team Member ’Message/Information Need
’ Project Team Member needs the detailed task from Project manager and material from other stakeholder
’Delivery Vehicle ’ By meeting
’Frequency ’ Weekly
’Feedback
’ Provide information to project manager and other stakeholder about the progress has been made.
Communication Plan Other Stakeholders
’Message/Information Need
’ Needs information especially on project progress report, and other informations
’Delivery Vehicle
’ By meeting and Courier
’Frequency ’ Weekly
’Feedback
’ Provide data and other informations to other stakeholder
Risk Identifications ’ImpactEstimated 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
Risk Identifications ’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
Risk Identifications ’Operation in unfamiliar software environment causes unforeseen problems ’Team members do not work well together ’Key personnel are available only part-time
Thank You Any Questions?