Final Report

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader                       Gole, Steven                      8002

 

 

 

 

            Final Project Leader           Gole, Steven                     8002

Members                              Aftab, Sheikh                    0856

                                                          Amjad, Salman                 0170

                                                          Hile, Joe                            0673

                                                          Acton, Nick                       1169

 

 

 

 

 

Haworth College of Business

Western Michigan University

Spring 2006

 

Overall Table of Contents

 

              Project                                                                                              Completed     

 

Overall Executive Summary                                                                            4/24/2006

Project #1: Team Formation Report                                                               2/2/2006

Project #2: Project Identification and Planning Report                                  3/7/2006

Project #3: Project Analysis Report                                                                3/23/2006

Project #4: Project Design Report                                                                  4/4/2006

Project #5: Project Implementation and Maintenance Report                      4/13/2006

Closing Project Comments                                                                              4/24/2006
Overall Executive Summary

The residence life inventory problem affects everyone working and living at Western Michigan University.  The inability to maintain inventory locations, and update work progress has impaired a well equipped staff.   Our group took this problem and by fallowing the SDLC waterfall steps we completed a system that with minimal improvements can remedy Western Michigan University’s inventory problem. 

First we formed a team, assigned roles, and built chemistry.  The strong chemistry shows how motivated all members are and greatly helped the project in the future.

Secondly, we identified the ResLife inventory problems as the most worthy of our time compared to other possible projects.  Residence Life was chosen because we could interact best with them, while having the ability to solve their problem.

Third, we analyzed the current system that Residence Life was using.  They used a paper system that lacked immediate update.  As a result productivity and ability was slowed and lowered.

Upon analyzing we designed a new system.  Through the implementation of a database, handheld computers, and a software program we can greatly improve their system.

            Finally we completed a prototype, calculated cost analysis, completed project documentation, and formulated what was needed for system testing.

            With minimal improvements and investment the Western Michigan Residence life program can be improved.  The fallowing projects dictate each step of the SDLC waterfall and how our system came to be.
Report 1: Team Formation

 

 

 

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader                          Gole, Steven                        8002

 

 

 

 

            Group 1 Leader                      Gole, Steven                        8002

Members                                    Aftab, Sheikh                   0856

                                                           Amjad, Salman                0170

                                                          Hile, Joe                          0673

                                                          Acton, Nick                      1169

 

 

 

 

 

 

Haworth College of Business

Western Michigan University

 

 

Table of Contents

 

Executive Summary………………………………………….……………………………3

Hierarchy Chart……………………………………………………….…….……………..4

Communication Links……………………………………………………….……….……5

Schedule of Meetings……………………………………………….……….…………….6

Responsibility Spectra………………………………………….…………………………7

Due Dates for Future Reports……………………………………………….…………….9

Gnatt Chart………………………………………………………………….……………10

Meeting Minutes…………………………………………………………………………11

References…………………………………………………….……………………….....12

Comments Sheet………………………………………………….……………………...13

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Executive Summary

 

           

This report determines our group formation to best succeed with the systems analysis and design project.  We determined group roles based on personal nomination and by whom we felt was best suited for a position.  We delegated a captain, secretary, timekeeper, spokesperson, and writer.

            We gathered possible communication links and discussed the best times to meet in the future.  After reviewing future due dates for reports we constructed a possible Gantt chart we could use to visually display our time table for each report.  Also we constructed a chart to catalog future meetings.

            There are five project proposals which are presented.  They were graded on five categories by each person.  We used this information to determine which system to analyze and formulate a new design. 

Finally we recorded our personal comments on the meeting and our continual group progress, which will help ourselves chart our growth throughout this project.

 

 

Communication Links

 

Steven Gole                  248-721-2022                         s3gole@wmich.edu

Joe Hile                        574-215-5020                         j2hile@wmich.edu

Salman Amjad              269-873-0418                         mr_salmans@yahoo.com

Sheikh Aftab                269-267-0371                         sheikh.aftab@wmich.edu

Nick Acton                  248-563-0845                         nick.acton@wmich.edu

 

Schedule of Meetings

 

 

 

Responsibility Spectra

 

 

 

Steven Gole: Captain:  As the captain my role is to help all members maintain a product of high quality.  I will do this by fallowing up on group members and helping with team communication and cohesiveness.  I also must help to maintain a productive group and ensure all meetings are constructive.  It is important for me to maintain a high level of contact with fellow members to ensure the all members are making high quality progress. 

Joe Hile: Spokesperson: My role in the group will be that of the spokesperson.  It will be my role to communicate between the group and the professor and questions or concerns that our group might have.  I would also serve as a means of communication between members of the group as well, if necessary. When needed, I will contact any needed company to fulfill our project responsibility.

Salman Amjad: Timekeeper: I am supposed to be a timekeeper. My duty is to gather every body for the group meeting and record our progress.  I am in charge of keeping meeting time notes and sharing it with the group.

Sheikh Aftab: Secretary: The responsibilities of mine as a secretary are to keep all the record and present the hard copy when needed to all the members as well as professor. We are still deciding more on it.

Nick Acton: Writer: I will be in charge of the writing portion of the group assignments.  After group discussion I will gather up all of the information the team has come up with and put it all into a free flowing report.  I will contribute as much as I can to help the group obtain as much information as possible to complete our assignments.  As the team writer I hold the responsibility to formulate the ideas and thoughts of the group the best way possible to help others understand them and get our point across easily.

Due Dates for Future Reports

 

Report 1: Team Formation:                                           1/17/2006

Report 2: Project Review:                                             2/2/2006

Report 3: Project Management:                         2/23/2006

Report 4: Project Planning:                                            3/7/2006

Report 5: Project Analysis:                                            3/23/2006

Report 6: Project Design:                                              4/4/2006

Report 7: Project Implementation:                                 4/13/2006

Project Presentation:                                                     4/20/2006

Final Documentation                                                     4/25/2006 by 10:00 am

 

Meeting Minutes

 

 

 References

Best Buy, “ Best Buy Inc.”, www.bestbuy.com, 1/30/2006;

 

Edgewood Electric Inc., “Edgewood Electric Inc”, www.edgewoodelectric.com, 1/19/2005;

 

(Hoffer, Jeffrey; George, Joey; Valacich, Joseph), “Modern Systems Analysis and Design: Fourth Edition”, 2005, Pearson Education. Upper Saddle River NJ. Pp.449

 

Office of Residence Life, “Welcome to Residence Life”, http://www.reslife.wmich.edu/, 1/30/2006

           

Panera Bread Co., “The Panera Bread Co.”, www.panerabread.com, 1/30/2006;

 

Comments Sheet

 

 

 

Report 2: Project Identification and Planning

 

 

 

 

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader                          Gole, Steven                        8002

 

 

 

            Group 2 Leader                        Aftab, Sheikh                   0856

Members                                   Gole, Steven                    0856

                                                               Amjad, Salman                0170

                                                               Hile, Joe                           0673

                                                               Acton, Nick                      1169

 

 

  

 

Haworth College of Business

Western Michigan University

Table of Contents

 

Executive Summary………………………………………………………...…………………..3

Project Overview………………………………………………………………………………...4

Identification and Selection……………………………………………………...……………..7

Corporate Strategic Planning…………………………………………………………………..9

Information System Planning………………………………………………………..….……11

Project Scope and Risk…………………………………………………………..….……….16

Management Procedures……………………………………………………………...……..19

Data Descriptions…………….…………………………………….…………………..……...23

Process Descriptions………………………….……………………………………………....24

Team Correspondence……………………………………………………………….……….26

Statement of Work…………………..………………………………………………………...27

References…………………………………………………………......................................28

Comments Sheet………………………………………..………….....................................29

 

  

Project Overview

1.0  Introduction

A.     Project Overview- To design and establish a inventory product tracking and information management system to allow residence life employees to easier locate and install products.  This is justified because of the difficulty and lack of efficiency as expressed by the employees.  This system will require heavily upon the OIT wireless network that is installed.  Implementation is expected to begin May, 2006.

B.     Recommendation- It is important to include all necessary data, thus interviews of employees for data types is crucial.

________________________________________________________________________

2.0  System Description

A system with a central server with all information stored with-in it.  Managers will be able to alter the database when needed.  Employees will have handheld computers that will be able to wirelessly access information for the server and display it for their benefit.  They will also be able to enter information depending on the situation

________________________________________________________________________

3.0 Feasibility Assessment

A.  Economic Analysis- Once the equipment reaches the break-even point profits will be steadily shown.  Profits will come from the decrease in human hours and employees.

B.  Technical Analysis- The main factor is the already in place wireless system.  The main challenge is acquiring and implementing the server and handheld computers.

C.  Operational Analysis- This solves a major inventory and efficiency problem and presents the opportunities to increase productivity which will decrease costs.

D.  Legal and Contractual Analysis- No legal problems as all inventory is owned by residence life department.

E.   Political Analysis- Upper level university heads may not feel the project is of high importance, or worth the initial cost and additional training.

F.  Schedules, Time Line, and Resource Analysis- Project must be ready for implementation by May 1, 2006

________________________________________________________________________

4.0 Management Issues

A.  Team Configuration and Management- All team members report are responsible for an equal part of the project.  Steven Gole is the captain, Joe Hile is the spokesperson, Nick Acton is the writer, Sheikh Aftab is the secretary, and Salman Amjad is the time keeper.

B.  Communication Plan- All members will be communicating with each other and Steven Gole will be in charge of group communication.

C.  Project Standards and Procedures-deliverables will be evaluated after all goals are met and a system has been established and in action for over a year.

 

Identification and Selection

Residence Life Department– Project Proposal

Business Background: Western Michigan University has 14 different dorms for the students. Students from different states stay in the dorms. To deal with students there is a special department who work for them. Running this system is not an easy job. Assigning rooms, delivering nice furniture, security systems, maintenance of rooms and different other jobs controlled by residence life. A special crew work for Residence life called Bronco movers. Residence Life is fully equipped with technology.

Fourteen different halls controlled by different hall directors. Hall director’s takes work orders from the students and transfer them over to residence life department.  Under residence life moving crew work for them.  Moving crew people takes order from the hall director and tries to solve it on time.

Business Problem:  System works properly but problem arises when a new employee gets hired by the department. Moving crew people face problems when they get hired first time. Each hall has at least ten different storages. Counting them all calculation comes up to 140 but these numbers are not fixed it could reach up to 160.there are some storages assigns to dinning services, IT labs, MacDonald’s, and some other departments. In this situation if a new employee gets hired and received some works order which says please move computer table from Davis Room 102 to storage P101.Storage Code words are hardily to understand for the new employee. At this time employee will waste his time by asking hall director.

Solving the Problem:  There should be some software which will make it easy for him to find the location.  Software shouldn’t be developed in modern language. There are no restrictions for the software. Software can be developed in VB easily. All storages will be mentioned with different departments. Residence Life, Dinning Services, Maintenance and others will be used as assigned links for them. Suppose a person belongs to residence life can just hit Residence life then can enter in to another link called storages.  GUI (graphical user interface will be so simple) Residence Life----àstorages--à and then directions. It should be easy so that new employee could learn it in seconds

Total Proposal Ranking’s

 

            Based on these total ranking, and with other circumstances and professor permission we chose to pursue the Residence Life Inventory proposal brought to the group by Salman Amjad. It received the highest accessibility, necessity, and ease of implementation score which ensured our group would pursue it.

 

 

Corporate Strategic Planning

 

Corporate strategic planning as defined in our text is referred to as, “The process of developing and refining models of the current and future enterprise as well as a transition strategy”[1].  In order to do this most corporations or organizations come up with a mission statement, a statement of future corporate objectives, and a competitive strategy, or the way that the organization intends on reaching these objectives.

            The mission statement is usually a brief declaration of what kind of business that the organization is in and their vision of their work.  This is no different for the WMU Residence Life organization.  Their mission statement is to create educational communities which engage students in learning and personal development.  Their mission is to engage students in learning and personal development.  Their vision is to be a premier learning-oriented student affairs division.  [2]

            The statement of objectives is a wide array of steps that the organization is trying to take in order to reach their main goal.  Many of the objectives will not state specifically how they will be reached, but the objectives are the steps needed in order to achieve the task of their mission statement.  The WMU Residence Life lists these 10 objectives:

1. Create conditions that enhance student learning and personal development.
2.  Create purposeful, open, just, disciplined, caring and celebrative environments.
3.  Make people matter.
4.  Advance diversity within community.
5.  Teach effective citizenship.
6.  Forge collaborative partnerships with students, faculty, staff and others to enhance student learning.
7.  Allocate resources to encourage student learning and personal development.
8.  Integrate expertise on students, their environments and teaching and learning processes into practice.
9.  Base policies and programs on best practices from the research on student learning and development and on institution-specific assessment data.
10.  Involve students in all facets of the University to enhance student learning and personal development.

 

The method by which an organization attempts to achieve its mission and its objectives are by way of the competitive strategy.  From what I can tell I am under the assumption that the Residence Life organization is trying to establish a Product Differentiation strategy.  The ResLife organization believes that they can offer a unique living experience through student involvement and planned activities and programs that many apartments and houses can not offer.  It is also touted as a very friendly environment where students can easily meet other students and begin friendships.  The ResLife organization also stresses student involvement by means of having a student government for every dorm building.  They also employee students to work at the front desk and to take care of mail as well as answering general questions.  They are also required to check IDs after a certain time for security issues.

 

 

Project Scope and Risk

The problem associated with Western Michigan University Residence Life deals with inventory management and information management related to the stored inventory.  This provides a design to manage the location of inventory used for various tasks associated with the residence halls.  There are 28 storage areas in dormitories and other university buildings.  The employees have trouble finding the necessary products as they are often moved and not accounted for.  Another opportunity is the information associated with each product.  This includes instructions for assembly, storage, and operation.  A system needs to be designed for these problems in order to improve the employee’s efficiency and operation.

Results to Be Achieved

1. Increase in Efficiency- With the organized system involved there will be less searching for a desired inventory and will allow for a faster retrieval and setup of that inventory.
2. Decline in documented errors- With a more organized system less errors will be committed and over time they will decrease as more information is added to the system.
3. Decrease in service calls- Service calls should be decreased as less time will be needed to implement a inventory and less errors will occur.  As a result of these two decreases, there will be a proven decrease in service calls.
4. Decrease in employee’s hired and retained- As there will be an increase in productivity, and efficiency, and with the size of residence life inventory maintaining the same size; there will be an opportunity for a decrease in employees.

Success will be measured with….

·          Increase in overall efficiency

·          Decline in employee error

·          Decline in service calls

·          Decrease in the number of employees retained

·          Break-even achieved

The project will be complete upon the fulfillment in two areas.  The first area is when all success measures are fulfilled.  Upon the completion of these measures a break even will be achieved and an efficient and productive system will be in place and profitable for the future.  The second measure is when all information on all products is entered in the system.  This is a time consuming process that will be done in two stages.  The first process being, a one time inclusion and implementation for all known instructions and locations related to product inventory.  The second will be found and added to a system by experience and discovery.

Risks to the Project

1. Locations of products-all products will have to be inventoried to correctly formulate an inventory system.  Once a product is located it needs to be entered into the system. A risk would be an organized discovery of all products
2. Inclusion of needed instructions- Instructions of all needed products must be located, improved upon and added to the system database.  It may be difficult to locate instructions.
3. Training of employees- Training new employees to use the new system could have a time and cost curve associated with it.
4. Security- Security protection will be needed to insure any non-users do not alter the inventory system of information associated with it.

 

 

 

Management Procedures

 

Management procedures play an important role in managing different aspects of project. Every phase of a project comes under management procedure. There are several things involves in management procedures

Project Management Procedures: - Details of a project proposal are considered and reviewed by the Business Development Manager (BDM) and Project Leader. They meet with client to discuss proposed project ensuring the following have been taken into consideration

§                     the University has sufficient recourses to undertake the proposed project

§                     the time period required to complete the project can be achieved

§                     the return to the University as a result of undertaking the project

§                     the expected income from the project

§                     the expected expenditure associated with the project

Project review meetings and planning: - The procedures assumes that the cost centre operates under an annual business plan that defines

§                     mission and values

§                     business and business objectives

§                     performance measures

§                     monthly income and expenditure targets

The annual business plan would normally constitute the first of a 3-5 year plan. The purpose of the monthly meeting is to ensure that each month's results meet or exceed requirements of the business plan. It is suggested that the following positions attend (the attendees are recommendations only therefore the attendees at a local level should be the appropriate project management staff for that particular area)

§                     Director/Head of School

§                     Business Development Manager (BDM)

§                     Divisional Finance Officer

Customer supplied items: -The University will identify, verify and safeguard customer supplied items provided for use or incorporation into a product/service. If any customer property is lost, damaged or otherwise found unsuitable for use, this shall be reported to the customer and records maintained. Please note that customer property can also include intellectual property.

Document control, quality records and filing: - Quality records are collated and maintained for ongoing reference in a safe readily accessible file or archive. Quality records are according to clients' requirements, or as designated by each division. Obsolete quality records are periodically removed from the file or archive and destroyed under the control of the Business Development Manager (BDM). The Business Development Manager has primary responsibility of ensuring that quality records relating to proposals and projects are kept. However, these records can be kept by other appropriate staff (e.g. BDM, Project Leader, Admin Support resources) according to the relevance of their role in undertaking the project activity and what is considered to be essential. Whilst it is acceptable that a single file is not required, the BDM must have accessibility to all project files on request. All records relating to a proposal and project are to be clearly marked for identification. It is recommended that PQS project ID number or cost centre number methodology be used for file order. Proposal and project quality records include

§                     proposal documentation

§                     project records, including proposal documentation, standard university contracts and copies of non-standard contracts, project information form, milestone and final reports and other essential correspondence

§                     assessment of subcontractors/suppliers and client feedback

Electronic versions of quality records, which may include large databases, multimedia reports etc should be referenced on the file and named/indexed such that a unique reference is dedicated to the particular file. Electronic files should be stored on an appropriate system, which is subject to backup and archiving

Closing projects: - Upon receipt of the final financial statement the Business Development Manager (BDM) should ensure that the closed project file is complete with all essential records. The whole project file should then be archived.

Handling, storage, packaging and delivery: - Handling issues will remain the same but we will become more efficient in storing and delivering the inventory after putting everything on handheld technology.

Training: - After implementing our technology we don’t have to train any Moving Crew Residence Life worker to find out the storage rooms and bring the required inventory as needed. This will also eliminate the time in finding the inventory needed to do the operation.

Back up of electronic files: - The University database will be backed up daily. Back up is carried out by Information Strategy and Technology Services Unit. Each back up tape is kept for a period of at least three weeks.

 Process Descriptions

The process has different stages before it comes to Department of Residence Life

1. The student who is facing problem reports to RA (Residence Assistant.)
2. The RA then requests the Hall director to send it to Residence Life Department.
3. The Coordinator at Department of Residence prioritizes it and then sends a copy to Moving Crew to fulfill the Needs of the Work Order.
4. Sometimes moving crew don’t find inventory because different shift people put different things in different locations.
5. If this happens then that work goes onto next day and its done according to priority.

 

 

Statement of Work

 

Residence Life                                                                                            02/20/06

 

Project Name:                                               Residence Life Inventory Problem

 

Project Manager:                                          Steven Gole

 

Customer:                                                      Residence Halls at Western Michigan     University

 

Project Sponsor:                                           Sheikh Aftab

 

Project Start/End (projected):                      1/17 – 4/13

 

Goals                                                              To give a system to Residence Life Department to reduce timing issue in delivering and finding the inventory

 

 

References

 

1. http://www.unisa.edu.au/res/busadmin/procedures.asp  Retrieved February 22, 2006.
2. Kerzner, Harold. http://books.google.com/books?ie=UTF-8&vid=ISBN0471225770&id=_X1JKShscPcC&dq=definition++of+management+procedures&pg=PP1&printsec=0&lpg=PP1&sig=emkt_a7VdMJljjM1njXKbtt2QIw. Retrieved February 22, 2006
3. www.reslife.wmich.edu/general/mission.htm . Retrieved February 22, 2006

 

 

Comments Sheet

 

 

 

 

Report 3: Project Analysis Report

 

 

 

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader                          Gole, Steven                        8002

 

 

 

 

            Group 3 Leader                        Gole, Steven                    8002

Members                                   Aftab, Sheikh                   0856

                                                               Amjad, Salman                0170

                                                               Hile, Joe                           0673

                                                               Acton, Nick                      1169

 

 

 

  

 

Haworth College of Business

Western Michigan University

Table of Contents

 

Executive Summary……………………………………………………………………….3

Information Collected From Observation………………………………………………....4

Existing Written Information…………………………………………………………...…4

Context Data Flow Diagram…………………………………………………………..…..5

Current Physical Data Flow Diagram…………………………………………..…………6

Current Logical Data Flow Diagram……………………………………………..……….7

New Logical Data Flow Diagram………………………………………………..………..8

Data Flow Diagram Component Description……………………………………..………9

Structured English Representation of Process Logic…………………………….………10

Decision Table Representation………………………………………………………..…12

Decision Tree Representation……………………………………………………………12

E-R Diagram of Data Needed………………………………………………………...….13

E-R Diagram for Inventory System Being Replaced…………………………………….14

E-R Diagram of New Database……………………………………………………….….15

E-R Diagram of the Whole Database…………………………………………………….16

Meeting Minutes……………………………………………………………………..…..17

References………………………………………………………………………….…….18

Comments………………………………………………………………………………..19
Executive Summary

 

During this project we analyze and examine the current structure of the Western Michigan Residence Life Inventory Program.  We had a meeting in which we visited and observed operations and documented existing information.  From our visit we formulated a context diagram along with all data flow diagrams.  To explain the process logic we formulated a structured English representation and make a decision table and tree.  We formulated an E-R diagram to prepare us for the coming design phase.  Overall the project is progressing well, and with this phase I feel we are well prepared to continue with the design phase.
Information Collected from Observation

 As we know that we are in the middle of the project and we learned a lot from observations that how to manage inventory. It is our observation that we should put the same kind of furniture at a same place for each dormitory. Observations also say that we need to do inventory of every thing which are in the storage room of the dorms. For doing this we have to organize everything that it can be countable and can be easily excess able for the new people who are just hired. It will help the office of residence life to get done with their project in timely manners. Our observations also say that before starting any project all the people who are going to be involved in it should meet each other and discuss the entire problem which can occur during it.

Existing Written Information sections

Right now the existing written information sections have the following information.

1. The number of storages.
2. The size of storages in length and width.
3. The space empty in all the storages.
4. What kind of furniture is placed in those storages?
5. We also know now what kind of furniture is going to trash to empty out the storage space.
6. We also know now that what important furniture is sitting in the storage.
7. The most important information is that we can forecast what we will use in near future and what will stay in the storage.

 

 

Context Data Flow Diagram

 

 

 

 

 

 

New Logical Data Flow Diagram

 

 

Data Flow Diagram Component Description

 

 

Assign- This describes the process of assigning a work order to a delivery team.  This is done by the manager or the new inventory program.

Delivery Manager- This describes the employee in charge of the delivery team and all related processes to ensure all invoice requests are fulfilled and in an orderly manner.

Hall/ Building Director Request- This describes a request or denial made by the residence hall or building director for the repair or implementation of an inventory item. 

Implementation- The installation or repair of an inventory product to be done by the delivery team.

Inventory Database- This describes the database that the new inventory program will use to catalog products and all associated information relating to them.  Adding, changing, deleting, and using of data on this database is permissible.

Inventory File- Current paper based file system used to store inventory information.

Inventory Form Request- This is the current form used to request implementation or repair of a product.  A manager fills out an inventory form and the delivery team uses it to complete the installation.

Inventory Program- This describes the program to be used to better manage inventory and assign inventory forms to delivery teams.  This system is dependent on the inventory database.

Inventory System- All related inventory tasks in the physical data flow model that describes what is done to implement a new product.  This concerns the receiving of an inventory form, location of inventory product, assignment to a delivery team, and the delivery of a product.  After complete an update to the inventory file is done. 

Locate Inventory- Searching of inventory by delivery teams in order to proceed to the implementation process.

Requestor- This describes the original person requesting repair or implementation of an inventory product.

Residence Advisor Request- This describes requests made by the residence advisor on behalf of the residence hall student for repairs or implementation of an inventory product.  This is made to the hall/ building director.

Residence Hall Student Request- This describes a request made by a student in a residence hall or building for the repair or implementation of an inventory product.  This request is made to the residence advisor.

Update Inventory File- This is done by the delivery team to update the location of the moved inventory.  It is updated to the inventory file.

 

Structured English

 

Modified form of the English language used to specify the logic if information system processes. Although there is no single standard, structured English typically relies on action verbs and noun phrases and contains no adjectives or adverbs.

To get a special form of the project structure English plays an important role. We explain code in a form of structure English.

 

 

  

 

Structure English for Residence Life

 

 

 

Decision Table

 

Conditions/Courses of Action					Rules
					1	2	3	4	4
Inventory Function					O	O	A	U	C
Inventory On Hand					<	>	-	-	-
Find Matching Inventory Record					X	X	X	X	X
Order Inventory					X
Subtract Quantity Used From Quantity On Hand								X
Add Quantity Added To Quantity On Hand							X
Type of Inventory Function:				Inventory On Hand:
O = Order Inventory				<   = less than minimum required in stock
A = Update Inventory Added				>  = minimum required is fulfilled
U = Update Inventory Used
C = Check Current Item Inventory

 

 

 

 

Decision Tree

 

 

 

 E-R Diagram of Data Needed

 

 

Note: Hall Director Represents Manager in New Inventory System
E-R Diagram for Inventory System Being Replaced

 

 

E-R Diagram of New Database

 

E-R Diagram of the Whole Database

 

Note: Red Dictates the Old Inventory System

Note2: Blue Dictates the New Inventory System
Meeting Minutes

 

 

References

 

1.               “Project management procedures”, Research and Innovation Services, Available at: http://www.unisa.edu.au/res/busadmin/procedures.asp  Retrieved February 22, 2006.

2.               Kerzner, Harold. “Project Management: A Systems Approach to Planning, Scheduling, and Controlling “Available: http://books.google.com/books?ie=UTF-8&vid=ISBN0471225770&id=_X1JKShscPcC&dq=definition++of+management+procedures&pg=PP1&printsec=0&lpg=PP1&sig=emkt_a7VdMJljjM1njXKbtt2QIw. Retrieved February 22, 2006

3.               “Residence Life Mission”, Western Michigan University Available: www.reslife.wmich.edu/general/mission.htm .  Retrieved February 22, 2006

 

Comments

 

Report 4: Project Design Report

 

 

 

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader:                        Gole, Steven                8002

 

 

 

 

            Group 4 Leader:                   Acton, Nick                      1169

           Members:                               Aftab, Sheikh                   0856

                                                           Amjad, Salman                0170

                                                           Hile, Joe                           0673

                                                           Gole, Steven                    1169

 

 

 

  

 

 

Haworth College of Business

Western Michigan University

Table of Contents

 

Executive Summary……………………………………………………………………….3

Overall System Description…………….………………………………………………....4

System Features:

1. Narrative Overview………………………….……………………………..…..5

2. Sample Design…………………………...…………………………..…………6

3. Testing and Usability Assessment…...…………………………………..……10

Nonfunctional Requirements………...…………………………………………..………13

Meeting Minutes………………………………………………………………………....16

References……………………………………………………………………………..…17

Comments…………………………………………………………………..……………18

 

Executive Summary

 

During this section of the project we put our project analysis into effect by actually designing the future Western Michigan Residence Life Inventory Program.  We had meetings to go over our previous observations and existing information from our analysis to create the best design possible for the Residence Life Inventory Program.  We developed all of the system features including the sample design, testing and usability overview, and the nonfunctional requirements needed for the system to work.  After finishing the design phase in this project, we are now at the point where we are ready to code the program and implement the system into use.

 

Overall System Description

 

The Western Michigan Residence Life Inventory System has been designed to be an effective and reliable way to make the entire workplace for the Residence Life department more efficient.  Creating files and databases will help them become more organized making it as easy as possible to change information, reference their resources, and create inventory reports.  The graphical user interfaces that were designed using Visual Basic were designed in a user-friendly fashion to make the implementation process easier.  The database design has been designed through Microsoft Access and then transferred to SQL to increase coherence with Visual Basic.  The whole system itself will be web based through Visual Studio so it can be implemented on all wireless devices that will be available to their workers.  Overall, we have designed a free flowing program to make sure inventory tracking can be more effective and efficient for the Residence Life department.

System Features

 

            This describes the main building blocks and structure of the Residence Life Inventory System.  Included is a sample design of what the database and user program will resemble.  A Testing and Usability assessment will discuss why the implemented features are important as well as how the testing procedures will be performed.

 

Narrative Overview

 

The Residence Life Inventory System is created for the hall/ building directors, inventory managers, and the delivery crew.

The managers and directors system will consist of desktop computers with our inventory program loaded upon it.  This will allow the directors the ability to enter in needed inventory with out relaying it to the managers, as was previously done.  By entering it in the system, they will request inventory.  They will need to enter the location identity, facility, building, and their information.  Their information includes their Identification and phone number.  This will ensure the location and all needed information is accessible for the situation.

            The delivery crews will be equipped with hand held computers which will primarily run the new inventory program.  This will allow them flexibility when constantly moving between locations.  When a job is completed they will be able to update inventory instantly.  Delivery crew will enter information on the task they have just completed.  This will aid the rotating shift of crews so that no time is wasted in the rotation.  The will have to enter the work order number, location identification, building, facility, and their information.  Delivery crew members are assigned an employee identification number, which will be required to be entered. 

            All entered information will be stored and organized on a central database.  The database created and managed in Microsoft Access will be able to accurately organize all important information related to an inventory item, location, or assigned task.  Managers can create reports to verify all inventory locations and show an overview of the inventory situations.  This is important in determining appropriate inventory level as well as estimated time of task completion. 

            The entire system will interact wirelessly utilizing the already in place wireless network access Western Michigan University provides.   

Sample Design

 

Sample design includes iconic outputs of what prospective director/ manager and delivery crew program will resemble; as well as the database inventory reports.  All Functions are described below the graphics.

 

 

Manager / Director Inventory Program

Requestors Name and Phone Number:  The name and office phone number of the manager or hall/ Building director.

 

Future inventory Location Information: This describes the intended location of the inventory.

Building:  The Formal Name of the building with the inventory shortage.

Facility:  Location with in the building with the inventory shortage.

 

Inventory Item Information:  Inventory description to be entered into the database. 

Name: The assigned name of the inventory product.

Description: Description of the inventory product and what the delivery crew is to do with the intended inventory.

Urgent: Checkbox that allows for urgent inventory needs to be processed first by delivery crews.

 

The submit button will enter the information into the database which assigns the task to a work crew.  The gathered information will be prepared for the crew to most efficiently complete their task.  Clear will delete previous information so that the user may enter other inventory requests.  Help button will open a description section for the program, building codes, and inventory codes for the user to rely upon.

 

 

A successful update of the database will reveal a notification graphic, showing the user has entered their desired information.

 

Delivery Crew Program

       

Inventory Addressed: Refers to the inventory which the delivery crew had worked with to accomplish their task. 

Name: Assigned name of inventory which was required.

Description: The task description and how the inventory is used are recorded for future experiences.

 

Inventory Location: Refers to the location the inventory was moved to or installed at.

            Building: The assigned name of the building where the inventory is located.

            Facility: Where in the building is the inventory installed or used.

 

Work Completed by: Section for the employees to sign off on their work, so a record is shown of when it was finished and who worked on the task.

            Employee ID: Refers to an ID given to each employee.

            Name: the given name for the employee.

Date and Time: Date and Time the task was completed for chronological reference

 

The Submit button will update the database with the completed task, new inventory location, and the employee which performed the work.  The help function will provide a written system help, and names for buildings and inventory items.

 

Testing and Usability Assessment

 

Testing

Before our software can be fully implemented we will have to run a series of various tests to insure the system is operating at its full potential and that the software itself is easy for the user to understand.  The first type of testing we will do will be inspections.  During this process we will be looking through all of the programming code in VB and we will be trying to find any errors in the code that could foresee ably cause problems.  For example, if the manager typed in their phone number where their name should have been, we need to make sure that the proper code is in place to catch that error and then notify the user that he/she has made the mistake.

            After the inspections we would then conduct a walkthrough of our code.  During the walkthrough we would have the project manager and/or the chief programmer hold a meeting where all of the code that was inspected would be presented to the rest of the team.  The programmer would walk through our code in detail and then we could ask him to walk through specific scenarios and if any problems should arise the programmer would then be assigned to re-write the code to correct the problems. 

            The final manual testing phase which we would conduct would be the desk checking phase.  In this phase the programmer or any our case, any one of use could sit down and go through the code with a paper and pencil, and execute each instruction or task that would be needed to be run from our system. 

            There are several automated tests that would need to be run as well to make sure that the code works on the computer system.  The first would the unit testing.  In these tests we would have to test each individual module in our code separately.  This way we know that the basic tasks can be accomplished. 

            From there we would need to start integration testing.  In this process we would begin to combine all of the separate modules in to larger groups with the other modules that they interact with to make sure that when the program is being executed, all of the tasks can be carried out without any conflicts of code.  For example we would only be testing the part of our software that called for sending the service request to the main server.  Then we would test modules that involved sending the request to the individual employees.

            Then we would execute a final system test where we would combine all of the groups of modules into our final system structure and simulate scenarios that would be similar to real life situations for the ResLife organization. 

 

Usability

            Once the testing has been completed by the implementing team, we will then like to find out how our system will behave in the environment that it is intended to be implemented into.  This is where acceptance testing will take place.  There are three separate phases to the acceptance testing with the first being the Alpha stage.

            During alpha testing, actual users of the system will be using simulated data that will be similar to that of real world situations.  Also during alpha testing there will be recovery testing, where the system will be forced by the user to fail in order to see if the system can automatically recover to an operating state.  We will also do various performance tests by switching out different types of hardware, as well as various OS and other variables.  We would also run stress tests as well as security tests to insure that the system is protected from harmful intruders from outside the system. 

            After all of those tests are completed it is time for the most important testing phase, the Beta testing.  During beta testing, the users of the system will be using actual data from the ResLife organization and will enter it into the system just as if the system was already implemented to see if all aspects of the system work properly in real-time.  Finally, once all of the alpha and beta testing has been complete, and the users are satisfied with the system’s usability, it then can be implemented.

 

   

Non-Functional Requirements

 

1.       User Interface and Human Factors

1.1.      What type of user will be using the system?

1.2.      Will more than one type of user be using the system?

1.3.      What sort of training will be required for each type of user?

1.4.      Is it particularly important that the system be easy to learn?

1.5.      Is it particularly important that users be protected from making errors?

1.6.      What sort of input/output devices for the human interface are available and what are their characteristics?

 

2.       Documentation

2.1.      What kind of documentation is required?

2.2.      What audience is to be addressed by each document?

 

3.       Hardware Considerations

3.1.      What hardware is the proposed system to be used on?

3.2.      What are the characteristics of the target hardware, including memory size and auxiliary storage space?

 

4.       Performance Characteristics

4.1.      Are there any speed, throughput, or response time constraints on the system?

4.2.      Are there size or capacity constraints on the data to be processed by the system?

 

5.       Error Handling and Extreme Conditions

5.1.      How should the system respond to input errors?

5.2.      How should the system respond to extreme conditions?

 

6.       System Interfacing

6.1.      Is input coming from systems outside the proposed system?

6.2.      Is output going to systems outside the proposed system?

6.3.      Are there restrictions on the format or medium that must be used for input or output?

 

7.       Quality Issues

7.1.      What are the requirements for reliability?

7.2.      Must the system trap faults?

7.3.      Is there a maximum acceptable time for restarting the system after a failure?

7.4.      What is the acceptable system downtime per 24-hour period?

7.5.      Is it important that the system be portable (able to move to different hardware or operating system environments)?

 

8.       System Modifications

8.1.      What parts of the system are likely candidates for later modification?

8.2.      What sorts of modifications are expected?

 

9.       Physical Environment

9.1.      Where will the target equipment operate?

9.2.      Will the target equipment be in one or several locations?

9.3.      Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibration, and magnetic fields)?

 

10.    Security Issues

10.1.   Must access to any data or the system itself be controlled?

10.2.   Is physical security an issue?

 

11.    Resources and Management Issues

11.1.   How often will the system be backed up?

11.2.   Who will be responsible for the back up?

11.3.   Who is responsible for system installation?

11.4.   Who will be responsible for system maintenance?

 

These are the basic non-functional environment requirements every system has no matter if it’s an inventory system or an ERP system.  The non-functional environment of a system consists of everything outside the use of machines which means downtime, installation, usage, quality, security issues, management, error handling, and GUI comes in the non-functional environment.  After a system is built, the following questions arise: who will use the system, how the system will be used, what is the range of the system. This all comes in the non-functional environment whether it is Western Michigan University Residence Life or a big warehouse for Wal-Mart.

 

Meeting Minutes

 

 

References

 

1.               “Project management procedures”, Research and Innovation Services, Available at: http://www.unisa.edu.au/res/busadmin/procedures.asp  Retrieved February 22, 2006.

2.               Kerzner, Harold. “Project Management: A Systems Approach to Planning, Scheduling, and Controlling “Available: http://books.google.com/books?ie=UTF-8&vid=ISBN0471225770&id=_X1JKShscPcC&dq=definition++of+management+procedures&pg=PP1&printsec=0&lpg=PP1&sig=emkt_a7VdMJljjM1njXKbtt2QIw. Retrieved February 22, 2006

3.               “Residence Life Mission”, Western Michigan University Available: www.reslife.wmich.edu/general/mission.htm .  Retrieved February 22, 2006

4.               Mitchell, Susan. "Nonfunctional Requirements.” http://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html. Retrieved April 2, 2006.

Comments

 

Report 5: Project Implementation and Maintenance Report

 

 

 

 

 

 

 

 

 

 

 

Residence Life Inventory Problem

Dr. Athappilly

T-R 12:30 – 01:45

 

 

 

Team Members:                               (Last, First)                       WIN#

            Team Leader                         Gole, Steven                        8002

 

 

            Group 5 Leader                      Gole, Steven                        8002

Members                                 Aftab, Sheikh                       0856

                                                             Amjad, Salman                    0170

                                                             Hile, Joe                               0673

                                                             Acton, Nick                          1169

 

 

 

 

 

Haworth College of Business

Western Michigan University

 

Table of Contents

 

Executive Summary………………………………………...……………………………………..3

Implementation Plan…………………………………………………..…………………………..4

Coding

            Interface Coding……………………………………………….…………………………..5

            Database Reports and Tables…………………………………...………………………..16

Testing

            Test Plan and Data……………………………………….………………………………17

Installation

            User Guide…………………………………………………...…………………………..19

            User Training Program……………………………………….………………………….27

            Installation and Conversion Plan………………………………….……………………..28

Cost Analysis…………………………………………………………………………………….30

Maintenance Activity Plan……………………………………………..………………………..32

Meeting Minutes…………………………………………………………...…………………….35

References………………………………………………………………………………………..36

Comments………………………………………………………………..………………………37

 

Executive Summary

 

 

During the implementation and maintenance report performed several steps to make our inventory system fully functional.  We created an implementation plan for which all implementation and maintenance activities would be dictated from.  First we coded the user interfaces and incorporated them to an access database.  Tables and reports were completed as an example of actual data.  A testing plan and estimated results were documented and discussed.  A user’s guide and training plan we designed along with a conversion plan for the system implementation.  A rough cost analysis was formulated.  This plan takes into effect future maintenance activities which are described.  This final project brings our inventory system full circle into a working prototype.  With further system development this has the practical ability to be implemented by Western Michigan University Residence Life to transform their current system to a more productive and cost efficient system.
Implementation Plan

Implementation plan takes into effect the prototyping, testing, installation, documentation, training, and support.

Prototyping will be done first using a Microsoft Visual Basic for the user interfaces and Microsoft Access for the associated database.  The Database will be created first from the relating E-R diagram of the new logical database from report three.  The interface will be coded from the database and will be designed for the delivery drivers and hall managers.

Testing will be described for which steps the employees need to take in assessing the system.  Test Data will be provided and users will use real life data to test the limits of the system.  Expected results are shown and described to our expectations and the expectations of the employee users.

Installation is described in a conversion plan.  A schedule is given a data conversion plan is shown.  Before the new system can be implemented the inventory information must be entered in the new database.  This can be done by data entry operators and the delivery personnel while working with the inventory. 

Documentation is provided in the form of an user guide and program documentation.  User guide is for the employees to use as a reference or for help.  The program documentation is for the developers as the prototype will need further development before implementation.

Training is shown through a user training plan.  The interface was designed to be simple to cut down on training time and costs.  The most difficult area of training is concerning managers.  It may be necessary to improve their overall technical skills to improve their system proficiencies.

Support is shown through maintenance activities.  We anticipate the most maintenance for the database as well as the hardware which will take considerable abuse.

 
 

            As with previous screens, enter the Inventory ID, Quantity needed.  Then enter the building and facility codes from which the inventory is being requested and click SUBMIT.

Adding Inventory

            When new inventory has been ordered to replace the used inventory, it must be recorded when it has been replenished.  This can be done by accessing the Add Inventory menu by clicking the link to the left.  This will bring you to the screen on the following page;

            This screen is exactly identical to the request inventory screen except it is used to add new inventory to the database.  First enter the ID of the inventory being added.  Below type in the quantity of inventory being added into the Quantity text box.  Then enter the building and facility codes below and click SUBMIT and the inventory will be added to the database.

 

Installation of the System

 

            When it comes to the installation of the system, we don’t want to just completely remove the old system and replace it with the new one right away.  This would make absolutely no sense from a usability standpoint.  This is why we will be implementing a Parallel installation strategy. 

            With this method of installation, we can leave the old system in place and then install the new system to work along side of if for the first few weeks.  Since there is no technology used with the old system, there really isn’t anything to remove besides filing cabinets.  With this type of installation, the employees of residence life can still use their old methods for tracking inventory, but they will also be using the new system alongside the old.  This will ensure that the new system is doing everything that it should and the staff can compare their hard data with the data from our system to see if they match.  This way, errors discovered on the new system will not cost Residence Life anything because they can continue using the old system until the new one is fully operational.  The downside of this method of installation is that because all of the work is being done twice, that means that in some cases, twice the amount of staff is going to be needed to run both systems but with our system, it shouldn’t be much more of a burden for one employee to enter data in 2 systems because the new one is very simple to use.

Site and Facility Remodeling Plan

 

            As far as site and Facility remodeling is concerned, there really will not be a whole lot that will be changed.  The first changes that we will make is that we will be installing our inventory tracking software on all of the computers that are used in the Residence Halls, as well as any of the other locations in which our system will be needed. 

All of the employees will also be carrying wireless devices that will be used to track inventory and add/remove inventory from the database when they are out on the field.  These wireless devices will also be pre-loaded with a version of our software and all of the data will be accessible through Western Michigan University’s already existing wireless network.  This will eliminate the need to install any extra wireless routers, and WiFi hotspots around the campus.

Instead of forms being used to keep track of all of the data, now the inventory levels will be kept on a main server using a central database created and managed with Microsoft Access.  When the employee enters any data from the computers or from the wireless devices, it will be automatically sent to the server where it will update the inventory levels automatically.

As far as the location of the central server is concerned, we will have to find a location that is free from any abnormal heat sources, as well as moisture and electrostatic interference.  We will most likely have to build a new room for this server that will have proper ventilation, as well as a surrounding barrier preventing any static or moisture from getting near the server. 

Data Conversion Plan

 

            In this section of the report, we will explain how the data is interpreted by the system and how it is moved within the database. 

When the employee first logs onto the system they will have to enter their employee ID as well as their password.  After they have entered the appropriate information they will click the submit button at which point the data which they have entered will first have to be validated by our software.  If the data entered is of the wrong type an error message will come up, but assuming the data is correct it will be then transferred from the computer, over the wireless internet and then be verified by the information on the server’s database.  If it checks out, then the page will be sent back to the user allowing them to continue and use the rest of the software.  The user can then use their personal computing device to request the amounts of inventory or add/remove the inventory that has been used. 

            When the employee wants to check the amount of inventory the data is entered into their wireless device and then is sent through the existing wireless network where it will access the central server which is constantly being updated by the other employees.  The appropriate inventory levels will then be relayed back to the computer or wireless device from which the information was accessed.

 

Cost Analysis

 

A rough cost analysis is given if the Western Michigan Residence Life program would implement the system.  The price for the inventory system and the hardware for ten managers and delivery employees are given.

Software and database improvements, mobile hardware, and server will be the highest implementation costs.  The training and maintenance will prove to be the majority of the maintenance phase costs.

Software and database will need to be improved to be more stable and accurate then the current prototype is. We have budgeted $1000 for software and database improvement.  This should be done in a reasonably quick time as the complete ground work is completed.

Mobile hardware would consist of 10 Palm Treo Smart phones that would operate over the wireless network at western.  They are equipped with internet access which would provide access to the inventory interface.  At a cost of $299 each, we budgeted $3500 for mobile hardware.  Mobile hardware is the majority of the cost of the project.

The server will run Microsoft server 2003 and will have the Microsoft Access database on it.  The server may also be used for other university and residence life functions.  We budgeted $1500 for a bare bones server.  This is a cost factor as other programs will be able to leech off its services.

The user interface is very user friendly and we anticipate a very short training session for management and delivery employee use.  We budgeted $1000 for training.  This includes any training materials and the salary lost to the training time.

A yearly maintenance of $700 will be budgeted.  This is a very generous amount for maintenance and will likely be much lower the longer the system is in use, as problems are discovered and remedied.

 

Spread Sheet Showing the Cost Analysis from implementation through first year maintenance.

 

We figured the money saved will mostly be shown in saved hours from increased productivity.  With the increased productivity less time will be needed to perform inventory tasks.  Also, fewer employees will be needed.  The saving on their salary and job costs will make this system worth while investment.
Maintenance

Maintenance is an important part of the life-cycle of embedded systems. System development starts from the design stage and ends up with testing and implementation. It must be considered from the design stage through the end-of-life stage of the system. Maintenance covers two aspects of systems - operation and performance.

Operation and performance are the most important parts in the development of the system life cycle. Question arises here what is maintenance. Maintenance is generally performed in anticipation of, or in reaction to, a failure. Maintenance is performed to ensure or restore system performance to specified levels.

Improperly performed or timed maintenance can make worse problems because of faulty parts, maintainer error or errors in coding. A systematic and structured approach to system maintenance, starting during the design process, is necessary to ensure proper and cost-effective maintenance.

Types of Maintenance          

Maintenance of the system contains different categories such as predictive, preventative, corrective and fault-finding.

Corrective Maintenance

Corrective maintenance refers to change program errors in the system. Discussing about maintenance in the book there is a wonderful example of daily life routines for example when we buy a house. In a furnished house you can have electric heat and cooling system. Sometimes some error occurs in the installation. In a corrective maintenance without removing a whole system we deal with errors. We simply focus in removing the errors. The need for corrective maintenance can be beneficial or detrimental depending on the product and the profit model used during the design phase of the product. On the most obvious level, corrective maintenance is detrimental to operation because it means that something failed, and the system is (probably) not available during the time needed to perform the maintenance. On the other hand, it may be that the economics and planned functionality of a system are such that using a cheaper, replaceable device for which failure is anticipated, makes sense.

Perfective Maintenance

Perfective maintenance involves the enhancement in to the residence life inventory system planned about embedded system technology. For example if a company employee stores some inventory from somewhere in the storage. To get confirmation he needs to verify with the department. Instead of using wireless phone there should be some combined interface for that specific system. How it will process employee will send information through the text message and receive will receive the information then information will be sended to the inventory database system. Inventory database system will send message back to the sender. For example “request accepted” or” request denied”. In this case we are dealing with two different technologies wireless and database inventory system. Simply you can take the example of adding one room in to the building.

Adaptive Maintenance

Changes made to a system to evolve its functionality to changing business needs or technologies. (From book). Let’s talk about this in details. Adaptive maintenance is less urgent than the corrective maintenance or in other sense we can say adding more values to the system.

Preventive Maintenance

Changes made to a system to reduce the chance of failure in future. Some times to reduce the failure effects in to the system. System analyst does some changes to prevent system errors. On the other hand whenever we upload some data online then for the backup we store our data somewhere in the hard drive. At this point hard drive is acting like a prevention of the system. For the residence life inventory system we will have a same setup for the backup.

 

 Meeting Minutes

 

 

References

 

1.                     “Project management procedures”, Research and Innovation Services, Available at: http://www.unisa.edu.au/res/busadmin/procedures.asp  Retrieved April 14, 2006.

2.                     Kerzner, Harold. “Project Management: A Systems Approach to Planning, Scheduling, and Controlling “Available: http://books.google.com/books?ie=UTF-8&vid=ISBN0471225770&id=_X1JKShscPcC&dq=definition++of+management+procedures&pg=PP1&printsec=0&lpg=PP1&sig=emkt_a7VdMJljjM1njXKbtt2QIw. Retrieved April 11, 2006

3.                     “Residence Life Mission”, Western Michigan University Available: www.reslife.wmich.edu/general/mission.htm .  Retrieved April, 11 2006

 

Comments

 

 

 

Final Report Comments