Presentation on theme: "Waste Management Inspection Tracking System (WMITS)"— Presentation transcript:
1 Waste Management Inspection Tracking System (WMITS)
2 Software Project PlanThe main purpose of WMITS is to help automate the entire process that the Department of Environmental Quality (DEQ) Waste Management Division (WMD) staff members perform throughout an inspection
3 Goals of WMITS To minimize the time span of any inspection To minimize the amount of paper work requiredTo provide a searchable database of all past inspectionsTo provide an automated channel for the public to request information
4 General RequirementsA way in which DEQ could add new facilities to the database.A way in which DEQ could generate electronic checklists.A search on all electronic checklists.A way in which they could generate letters to be sent out to facilities based on inspection results.A way in which all letters and checklists could be stored electronically.A way to search for existing facilities.A way to print blank checklists and staff reports.A way in which they could view data which was entered into the database prior to our software.DEQ wanted a product that would allow them to easily add new checklists and letters or change existing checklists and letters.
5 System Context Multiple users will be using the product simultaneously Concurrent connection will be an issue for implementationThis is a pilot product that hopefully, if successful, can be used in other locations as wellThis leads to issues about future support for a larger user base.
6 Major ConstraintsTime - Two months to finish all documentation, software creation and enhancementsFunding - Funding to buy at least one Palm Pilot
8 Project ResourcesPeople - This project will require three programmers in order to be finished in timeMinimal Hardware RequirementsThree IBM PC or compatibles with the following configurationsIntel Core i52 GB RAM500MB Hard disk spaceInternet Connection
9 User Client-side User Server-side IBM PC or compatibles with the following configurationsIntel Pentium i5 processor2 GB RAM500 GB Hard disk spaceUser Server-sideIntel Pentium i7 processor8 GB RAM1 TB Hard disk space
10 Minimal Software Requirements DevelopmentWindows 7 / 8Windows 2012 ServerVisual Basic 6.0 (three user licenses)Microsoft Access 2010Microsoft Word 2010
11 User Client-side User Server-side Windows 7/8 Microsoft Access 2010 (optional)Microsoft Word 2010 (optional)User Server-sideWindows 2012 Server
12 Risk Management Risk management organizational role Software development can avoid having risk by double-checking their schedule, product size, estimates regarding costs of the development etc.Customer can help avoid risk by providing all necessary software information during the early phase of the development.Software development team can avoid risk by getting all the details of the equipment that are provided or are accessible to them.Client can avoid risk by making all necessary business changes before initiating request for the software.
13 Risk Description Business Impact Risk Customer Risks If the software produced does not achieve its goals or if it fails to help the business of clients improve in special ways, the software development basically fails.Customer RisksIf the client fails to attend meeting regularly and fails to describe the real need of the business the produces software will not be one that helps the business.
14 Development Risks Employee Risk Process Risks If all the requested resources are not provided to the software development team odds for the software development to fail rises greatly.Employee RiskIf one or more members of the software development team are not putting in all the effort required to finish the project it will cause the project to failProcess RisksIf the product developed does not meet the standards set by the customer or the development team it is a failure
15 Product Size Technology Risk If the customer fails to provide the proper size of the product that is to be developed it will cause major problems for the completion of the projectTechnology RiskTechnology risk involves using technology that already is or is soon to be obsolete in development of the software
16 Risk Table Category Risks Probability Impact Employee Risks Lack of training and experience40%1Process RiskLow product quality35%Product SizeWhere size estimates could be wrong30%2Development RisksInsufficient resourcesCustomer RiskCustomer may fail to participate20%3Technology RiskObsolete technology10%Business ImpactProduct may harm the business
17 Deliverable Completion Date Project ScheduleStage Of DevelopmentStage Completion DateDeliverableDeliverable Completion DatePlanning01/21/00Quality Assurance PlanProject PlanMilestone01/15/0001/20/00RequirementsDefinition02/25/00Draft Requirements SpecificationDraft Design SpecificationProject Test PlanRequirements Specification (final)02/09/0002/15/0002/22/00Design(Functional &System)03/01/99Draft Training PlanProgram and Database SpecificationsDesign Specification (final)02/23/0002/26/0002/29/0003/01/00Programming04/02/00Software (frontend and backend)System Test PlanUser's GuideOperating Documentation03/31/0003/10/0003/20/0003/28/00Integration & Testing04/15/00Test ReportsTraining Plan (final)Acceptance ChecklistUser’s Guide (final)04/03/0004/10/0004/14/0004/12/00Installation & Acceptance04/20/00Maintenance PlanAcceptance Test Report04/16/0004/20/00 04/20/00
18 Project Team Organization Team StructureDue to the small size of the project team, the team will be organized in an egoless structure, where the entire group will make most of the decisions together.
19 Tracking and Control Mechanisms Quality Assurance MechanismsTight Change ManagementExtensive before implementation Design using Rapid PrototypingClose Contact with Clients, meeting every two weeks and regular contactsPlenty of Research on PalmPilot platform before development
20 Change Management and Control For changes affect the user experiences we will have to notify all clientsFor changes that do not affect the user experiences we will notify a client representativeDue the size of the team, internal control panel will be used. One member of the team suggests a change, it will need to be approved by the other two membersFormal version numbering will be used. All version changes must be documented in a common document accessible to all team members before a new version number can be released. Version number will be structured as follows:<Major Release>.<Minor Release><Bug fix>