ARCC

Document Sample
ARCC Powered By Docstoc
					Senior Design Documentation Library                          Project Charter




   Department of Computer Science and Engineering
         The University of Texas at Arlington


                                      ARCC

                                                      Team ALVIS
                                                Team Members:
                                               Rachit Aggarwal
                          Sankar Kulathuaiyer Sundareswaraaiyer
                                                Pranusha Ravula
                                                    Aakash Tuli
                              Late Updated: 26 November 2012 @ 11:12:00 PM
                              Copy Printed: 26 November 2012 @ 11:12:00 PM




                                  Project Charter
Senior Design Documentation Library                                                                                        Project Charter




                                             Table of Contents
1     General Organization ........................................................................................................1
      1.1       Project Manager .................................................................................................................. 1
      1.2       Project Oversight ................................................................................................................ 1
      1.3       Roles and Responsibilities .................................................................................................. 2
      1.4       Project Constraints .............................................................................................................. 4
      1.5       Project Assumptions ........................................................................................................... 4
      1.6       Preliminary Schedule and Cost Estimates .......................................................................... 5
2     Scope Statement .................................................................................................................6
3     Cost Management Plan......................................................................................................8
      3.1       Materials Management ....................................................................................................... 8
      3.2       Labor Management ............................................................................................................. 9
4     Earned Value Management ............................................................................................10
      4.1       Tracking Earned Value ..................................................................................................... 10
5     Scope Management Plan .................................................................................................11
6     Work Breakdown Structure ...........................................................................................12
7     Quality Management Plan ..............................................................................................20
      7.1       Purpose.............................................................................................................................. 20
      7.2       Components of Plan .......................................................................................................... 20
8     Communications Plan ......................................................................................................22
      8.1       Team Communication....................................................................................................... 22
      8.2       Communication with Sponsor, Department Manager and Other Stakeholders ................ 23
9     Change Management Plan ..............................................................................................24
      9.1       Purpose of Integrated Change Management Plan ............................................................. 24
      9.2       Roles and Responsibilities ................................................................................................ 24
      9.3       Review and Approval Process .......................................................................................... 25
      9.4       Change Identification, Documentation, Implementation and Reporting .......................... 25
      9.5       Re-base lining ................................................................................................................... 26
10    Risk Management Plan....................................................................................................27
      10.1      Purpose of Risk Management Plan ................................................................................... 27
      10.2      Roles and Responsibilities ................................................................................................ 27
      10.3      Risk Identification............................................................................................................. 28
      10.4      Risk Triggers..................................................................................................................... 28

26 November 2012 @ 11:12:00 PM                                         i                                                Table of Contents
Senior Design Documentation Library                                                                                       Project Charter

      10.5      Risk Analysis .................................................................................................................... 28
      10.6      Risk Severity ..................................................................................................................... 30
      10.7      Risk Response Planning.................................................................................................... 31
      10.8      Risk Documentation and Reporting .................................................................................. 32
      10.9      Risk Control ...................................................................................................................... 32
11    Staffing Management Plan ..............................................................................................33
      11.1      Purpose of the Staffing Management Plan........................................................................ 33
      11.2      Roles and Responsibilities ................................................................................................ 33
      11.3      Project Organization ......................................................................................................... 33
      11.4      Resource Requirements .................................................................................................... 33
      11.5      Resource Staffing Plan...................................................................................................... 33
      11.6      Resource Constraints ........................................................................................................ 33
      11.7      Staffing Reports ................................................................................................................ 34
      11.8      Staffing Contingency Plans............................................................................................... 34
      11.9      Training Requirements ..................................................................................................... 34
12    Procurement Management Plan .....................................................................................35
      12.1      Purpose of the Procurement Management Plan ................................................................ 35
      12.2      Roles and Responsibilities ................................................................................................ 35
      12.3      Required Project Procurements and Timing ..................................................................... 35
      12.4      Description of Items/ Services to be acquired .................................................................. 36
      12.5      Hardware/Software Acquisition Process .......................................................................... 36
      12.6      Solicitation Planning ......................................................................................................... 37
      12.7      Applicable Conditions ...................................................................................................... 37
13    Project Closeout Report ..................................................................................................38
      13.1      The following are suggested sections for the Project Closeout Report: ........................... 38
      13.2      Purpose of Closeout Report .............................................................................................. 38
      13.3      Administrative Closure ..................................................................................................... 38




26 November 2012 @ 11:12:00 PM                                       ii                                                Table of Contents
                             Senior Design Documentation Library




                          1 General Organization
1.1   Project Manager
Team ALVIS has chosen Rachit Aggarwal to be the project manager for this project. Hence, he
will be responsible for overall project management.
In order to successfully manage the project, he is assigned responsibilities that include
administrative tasks, such as setting meetings agendas, recording meeting minutes, assigning
tasks, reviewing individual work, assuring quality, setting internal deadlines for deliverables and
milestones, and ensuring deliverables are ready on-time. Additionally, he will act as the
communication manager to convey team’s thoughts to other stakeholders and negotiate project
requirements.
Rachit is an effective leader who understands the strengths and weaknesses of individual team
members and hence, is able to assign roles and tasks efficiently. Moreover, we believe that his
good communication skills will help our team to effectively convey the team’s messages to the
stakeholders.


1.2   Project Oversight
The department manager for our project is Professor Mike O’Dell. His responsibilities include,
setting final delivery dates for deliverables, supervising the team progress, providing feedback
and providing support.
The project manager is entrusted with the responsibility to maintain internal control of the
project. He coordinates team meetings, assigns tasks, sets internal deadlines, and assures quality
of the deliverables. To ease project management, team ALVIS is using “Live Mesh” as the
online repository for all project related documents, which will be overlooked and managed by
the project manager. Furthermore, team ALVIS is using email as its primary method of
communication to keep all the stakeholders informed and up to date.
Besides the department manager, our project sponsor will be responsible for external oversight of
the project. The project sponsor, Mr. Matt Middleton, is expected to have a bi-weekly meeting
with the team that is arranged by the project manager. The project sponsor will primarily help to
keep the team on track relative to customer requirements. His role also includes reviewing the
work done, and ensuring that the team and project is heading in the right direction.
To keep the department manager informed, team presents a bi-weekly status report. The report
states the project’s status, discusses the work done during the period, and discusses the work
planned for future. Also, team will be providing the department manager with major deliverables


26 November 2012 @ 11:12:00 PM                   1                         General Organization
                               Senior Design Documentation Library

   on set due dates. Before submission, these deliverables will be reviewed by the project manager
   to ensure their overall quality.

   1.3   Roles and Responsibilities
   The responsibilities for development of the project have been divided evenly and assigned to the
   team as appropriate to every individual’s strength. While additional roles and responsibilities
   will be defined on as-needed basis over the course of the project, the preliminary assignments are
   as follows.

   Team Leader:           Rachit Aggarwal
   Team members:          Sankar KS
                          Pranusha Ravula
                          Aakash Tuli


      Roles/Responsibility                  Resource                       Description
Department Manager / Project      Mike O’Dell                           Provide support and
Supervisor                                                               feedback
                                                                        Supervise team’s progress
                                                                        Set dates for major
                                                                         deliverables
                                                                        Approve major decisions
                                                                         like materials to be
                                                                         procured etc.
Project Sponsor                   Matt Middleton                        Provide customer
                                                                         requirements
                                                                        Ensure that all customer
                                                                         requirements are met as
                                                                         specified
                                                                        Responsible for external
                                                                         oversight of project
Technical Advisor                 Matt Middleton                        Responsible for external
                                                                         oversight of project
                                                                        Provide help and
                                                                         suggestions regarding
                                                                         materials to be acquired
                                                                        Provide technical help
                                                                         regarding the project
Project Manager /                 Rachit Aggarwal                       Maintains internal control
Team Leader                                                              of the project

   26 November 2012 @ 11:12:00 PM                   2                         General Organization
                         Senior Design Documentation Library


                                                              Responsible for major
                                                               administrative tasks like
                                                               coordinating meetings,
                                                               assigning tasks, setting
                                                               internal deadlines etc.
                                                              Responsible for quality
                                                               assurance
                                                              Primarily responsible for
                                                               communications with
                                                               other stakeholders


Research                    Aakash Tuli                       Conduct extensive
                            Pranusha Ravula                    research for finding out
                                                               right technologies and
                                                               applications for the
                                                               implementation of project
Project Plan                Sankar KS                         Responsible for planning
                            Rachit Aggarwal                    and assigning tasks
                                                              Update Microsoft Project
                                                               file regularly
Risk Managers               Aakash Tuli                       Monitor the existing
                            Sankar KS                          risks regularly and watch
                                                               for new risks
                                                              Alert and inform the team
                                                               in case of a risk trigger
                                                              Initiate discussions to
                                                               plan strategy for newly
                                                               found risks
Hardware Development        Rachit Aggarwal                   Responsible for leading
                            Aakash Tuli                        and helping the team in
                                                               the hardware
                                                               development of the
                                                               project
Software Development        Pranusha Ravula                   Responsible for leading
                            Sankar KS                          and helping the team in
                                                               the software aspects of
                                                               the project
Documentation               Rachit Aggarwal                   Maintain, edit and
                            Pranusha Ravula                    compile all documents to
                                                               make sure that all
                                                               documents are versioned
                                                               properly

   26 November 2012 @ 11:12:00 PM             3                     General Organization
                                   Senior Design Documentation Library


Treasurer                            Pranusha Ravula                        Responsible for
                                                                             maintaining and updating
                                                                             all financial records




Change Manager                       Aakash Tuli                            Coordinate and manage
                                                                             all aspects related to the
                                                                             change in the project
Procurement Manager                  Sankar KS                              Responsible for
                                                                             coordinating procurement
                                                                             of materials
                                                                            Maintain and update the
                                                                             inventory and details of
                                                                             hardware and software
                                                                             products procured
                                                   Table 1-1



   1.4       Project Constraints
             Time – The deliverables’ deadlines are set by the project supervisor. All project deadlines
              must be met and the project must be completed and delivered by May 2010. The entire
              project will span over two 16-week semesters and thus the team members will have
              limited amount of time to work on the deliverables.
             Staffing – The team consists of four members. Personnel will not be added or replaced
              during the project.
             Budget – The CSE department will provide the team with an $800 budget.
              Implementation of the project involves assembling many components including an RC
              Car, a high resolution camera, a microcontroller and sensors. Research on these
              components has shown that they are fairly expensive and thus the development team
              must take special care to stay within budget.


   1.5       Project Assumptions
             The system will be operated indoors in a controlled environment.
             The system will operate in a dry and dust free environment.
             The system will operate at room temperature
             The system will travel on a path that is continuous.
             The system will operate on a smooth terrain.
             The path will not have any obstacles that are not predefined.




   26 November 2012 @ 11:12:00 PM                      4                          General Organization
                               Senior Design Documentation Library

1.6       Preliminary Schedule and Cost Estimates
Preliminary Schedule and tentative deadlines for major deliverables and milestones:
          First Draft of SRD - 10/19/2009 (As per Class syllabus)
          First Draft of charter – 10/26/2009 (As per Class syllabus)
          Final Project Charter – 12/02/2009 (As per Class syllabus)
          Final Baseline Project File – 12/02/2009 (As per Class syllabus)
          Final SRD – 11/16/2009 (As per Class review)
          ADS - 2/8/2010 (Estimated based on tentative SDII schedule)
          DDS – 3/12/2010 (Estimated based on tentative SDII schedule)
          Testing plan – 4/12/2010 (Estimated based on tentative SDII schedule)
          Final delivery – 5/7/2010 (As per tentative SDII schedule )
          Project wrap-up – 5/10/2010 (As per tentative SDII schedule )

Cost estimates:
           Only the following costs can be estimated at this stage of development of the project:
                 Camera - $50
                 Image analysis software application (MATLAB or LabView) - $100
                 Small computer - $200
                 Vehicle with micro controller - $250
                 Other accessories: $100
Some of the above mentioned components will be borrowed free of cost from either the Senior
Design lab inventory or from other possible sources. However, this depends on the availability of
sources.
Man hours: Based on the Baseline Project plan file, the team has estimated 1892 man-hours to
complete the project. This figure has been approximated based on the assumption that each team
member can devote approximately sixteen hours per week for the project during the two
semesters. Also, the tasks will be assigned as per the skills of the team members.




26 November 2012 @ 11:12:00 PM                     5                          General Organization
                             Senior Design Documentation Library




                              2 Scope Statement
The autonomous RC vehicle will use image analysis to find its way around in a controlled
environment. The mobile system mounted on the vehicle will process a continuous stream of
images from the path on which the vehicle travels and analyze them to locate any known custom
traffic signs. Every image will be examined to look for and match various traffic signs with the
repository of traffic signs in the mobile system. ALVIS assumes that images will be captured at
the rate of 10 frames per second and the vehicle will travel at most two mile per hour. However,
this assumption is subject to change during the design phase of the project. Once an image has
been completely processed and a custom traffic sign recognized, the mobile system will
command the vehicle to act as per the actions defined in the mobile system repository. These
actions will include commands to slow down, speed up, stop or steer the vehicle left and right.
The mobile system will be designed to understand some basic colors and shapes of custom built
traffic signs. Also, this product will include a line sensor which will allow the vehicle to follow a
pre designated, laid out path. This is being done to ensure that the vehicle remains on track.
The vehicle can be controlled from a base station, providing the user ultimate control of the
vehicle as and when required. The scope of the project includes designing a GUI for the base
station so that users can interact with the mobile system and vehicle.




26 November 2012 @ 11:12:00 PM                    6                                Scope Statement
                      Senior Design Documentation Library




                                      Slide Show 1
                        Note: Double click slide show 1 to run the animation.




…
                                      GUI Interface


26 November 2012 @ 11:12:00 PM               7                                  Scope Statement
                                Senior Design Documentation Library




                           3 Cost Management Plan
The project is estimated to be completed within two semesters. Efforts will be made to ensure
project gets completed within the 1892 man hours, as per the estimation in the project file. This
estimation has been arrived considering the skills of resources and allocating tasks based on
skills and also based on the assumption that each member can devote around sixteen hours per
week for the project. A labor management plan will be followed to keep track of the hours
worked by team members.


3.1       Materials Management
The budget provided by UTA will serve as the main source of funds to acquire components
pertaining to the project. This project is comprised of expensive parts. So, to stay within budget,
efforts will be made to obtain components from the Senior Design lab, the sponsor or third party
sources. A materials management plan will be followed to acquire resources in an efficient and
beneficial manner.
The materials management plan will follow the steps below.
          Research will be done to verify the requirement(s) for and establish the functionality of
           each component before deciding to obtain it.

          Senior Design Lab, the sponsor or a third party will be contacted to check if any of them
           are willing and able to donate any of the components required.

          Reviews of each product will be read and some research will be done to acquire the
           cheapest and most efficient components and finally the components will be purchased, if
           necessary.

          All product acquirements will first go through the project manager and then through the
           department manager for approval using the Purchase Request for specified from CSE
           Senior Design. Disapproval from any of them will result in rejection of the product under
           consideration.

          An excel sheet will be maintained, by the procurement manager, to keep track of all the
           acquisitions or purchases. The sheet will have:
              o Name of component
              o When to acquire
              o Description of component

26 November 2012 @ 11:12:00 PM                      8                        Cost Management Plan
                               Senior Design Documentation Library

              o Date of purchase or acquisition
              o Name of supplier
              o Price, if applicable

3.2       Labor Management
The project is estimated to be completed within two semesters. Efforts will be made to ensure
project gets completed within the 2000 man hours. A labor management plan will be followed to
keep track of the hours worked by team members.
The labor management plan will comprise of the steps below.
          Tasks will be assigned based on individual team members’ strengths in order to minimize
           time required to complete the tasks.
          Microsoft project file will keep information about the estimated time required to
           complete each task.
          Earned Value will be used to keep track of the hours worked by each team member.
          Individual status reports will be evaluated to ensure team members are contributing their
           share to the project.
          Team meetings will be held each week to track progress and to ensure each team member
           is doing the assigned job. Discrepancies or complaints of unfair distribution of work will
           be addressed. The project manager will take decisions to ensure that tasks are assigned
           fairly, and reassignments of tasks are done, whenever necessary.




26 November 2012 @ 11:12:00 PM                     9                        Cost Management Plan
                                Senior Design Documentation Library




                        4 Earned Value Management
Earned value is the measure of progress of the project. For ALVIS, earned value is also used to
measure the correctness of the estimates of the project. The management of earned value is as
follows:
          Earned value is measured in terms of the hours spent for each task and its sub tasks.

          Each task and sub task is initially allocated some planned hours to be completed. The
           earned value for a task will be 0% until it is completed and there is no intermediate
           measure for earned value. And once the task is completed, the earned value will be the
           hours planned for the task, irrespective of the actual hours spent. Earned value of a task at
           any point will be the sum total of the earned value of all its sub tasks.

          The planning of tasks can be refined by analyzing the variance of earned value hours
           from the actual hours spent. The variance is analyzed by calculating the ratio of earned
           value hours to the actual hours. If this value is greater than 1, it indicates that the
           performance is more efficient than estimated, whereas if the value is less than 1, the
           performance is less efficient than estimated. Initially the team refines the plan for future
           tasks based on this ratio and the goal will be to reallocate resources to tasks and hours of
           tasks so that the ratio is 1 and this is achieved within the schedule.

4.1       Tracking Earned Value
Planned hours will be estimated and allocated to each task and sub task in the Work Break down
Structure of Microsoft Project file of the project. Until the task is completed, the earned value for
the task will be 0%. Each team member is responsible for correctly tracking and recording
his/her individual accrued hours for every task assigned. These will be reported to the project
plan managers at least twice a week and then, these actual hours will be recorded in the project
file and the earned value for the task will have the value equal to the planned hours for the task.




26 November 2012 @ 11:12:00 PM                      10                   Earned Value Management
                            Senior Design Documentation Library




                     5 Scope Management Plan
The scope of the project will only change during the requirements gathering phase of
development. To start, the scope will consist of minimum requirements for the product to be
acceptable. Any request for further changes of scope in the requirements gathering phase (either
by the sponsor or by the development team) will go through rigorous feasibility study before
being accepted. Once the System Requirements Document has been finalized, no changes to
scope and no feature creep will be allowed.




26 November 2012 @ 11:12:00 PM                 11                      Scope Management Plan
                           Senior Design Documentation Library




                   6 Work Breakdown Structure

The work for this project is broken down to the following tasks and subtasks for assigning the
tasks to resources and scheduling them over the time. Each task is assigned a WBS number and
will be referred to using this number during assigning and communicating with team members.
    1 ARRC
        1.1     SRD
            1.1.1 Requirements Elicitation
                1.1.1.1 Product services and summary
                1.1.1.2 Development Environments
                1.1.1.3 External Interface and Data
                1.1.1.4 Customer Requirements
                1.1.1.5 Localization Requirements
                1.1.1.6 Marketing and Sales Requirements
                1.1.1.7 Administrative Requirements
                1.1.1.8 Development Requirements
                1.1.1.9 Quality Assurance Requirements
                1.1.1.10        Safety Requirements
                1.1.1.11        Standards Compliance
                1.1.1.12        Maintenance Requirements
                1.1.1.13        Support Requirements
                1.1.1.14        Performance Requirements
                1.1.1.15        System Constraint Requirements
                1.1.1.1 Exception Conditions and Handling
                1.1.1.2 Early Subsets and Implementation Priorities
                1.1.1.3 Foreseeable Modifications and Enhancements
                1.1.1.4 Acceptance Criteria
                1.1.1.5 Design Guidelines
                1.1.1.6 Assumptions
                1.1.1.7 Sources of Information
                1.1.1.8 Use Cases
                1.1.1.9 Glossary
            1.1.2 Initial Draft
                1.1.2.1 Product services and summary
                1.1.2.2 Development Environments
                1.1.2.3 External Interface and Data
                1.1.2.4 Customer Requirements

26 November 2012 @ 11:12:00 PM                12                  Work Breakdown Structure
                         Senior Design Documentation Library

             1.1.2.5 Localization Requirements
             1.1.2.6 Marketing and Sales Requirements
             1.1.2.7 Administrative Requirements
             1.1.2.8 Development Requirements
             1.1.2.9 Quality Assurance Requirements
             1.1.2.10       Safety Requirements
             1.1.2.11       Standards Compliance
             1.1.2.12       Maintenance Requirements
             1.1.2.13       Support Requirements
             1.1.2.14       Performance Requirements
             1.1.2.15       System Constraint Requirements
             1.1.2.16       Exception Conditions and Handling
             1.1.2.17       Early Subsets and Implementation Priorities
             1.1.2.18       Foreseeable Modifications and Enhancements
             1.1.2.19       Acceptance Criteria
             1.1.2.20       Design Guidelines
             1.1.2.21       Assumptions
             1.1.2.22       Sources of Information
             1.1.2.23       Use Cases
             1.1.2.24       Glossary
             1.1.2.25       Compiling and editing
             1.1.2.26       Group reviewing, compiling and editing
         1.1.3 Final Draft
             1.1.3.1 Product services and summary
             1.1.3.2 Development Environments
             1.1.3.3 External Interface and Data
             1.1.1.1 Customer Requirements
             1.1.1.2 Localization Requirements
             1.1.1.3 Marketing and Sales Requirements
             1.1.1.4 Administrative Requirements
             1.1.1.5 Development Requirements
             1.1.1.6 Quality Assurance Requirements
             1.1.1.7 Safety Requirements
             1.1.1.8 Standards Compliance
             1.1.1.9 Maintenance Requirements
             1.1.1.10       Support Requirements
             1.1.1.11       Performance Requirements
             1.1.1.12       System Constraint Requirements
             1.1.1.13       Exception Conditions and Handling
             1.1.1.14       Early Subsets and Implementation Priorities
             1.1.1.15       Foreseeable Modifications and Enhancements
             1.1.1.16       Acceptance Criteria
             1.1.1.17       Design Guidelines
             1.1.1.18       Assumptions
             1.1.1.19       Sources of Information

26 November 2012 @ 11:12:00 PM             13                 Work Breakdown Structure
                          Senior Design Documentation Library

              1.1.1.20       Use Cases
              1.1.1.21       Glossary
              1.1.1.22       compiling and editing
              1.1.1.23       Group reviewing, compiling and editing
          1.1.2 Presentation
          1.1.3 Final editing for base line document
      1.2     Project Charter
          1.2.1 Initial Draft
              1.2.1.1 General Organization
              1.2.1.2 Scope Statement
              1.2.1.3 Cost Management Plan
              1.2.1.4 Earned Value Management
              1.2.1.5 Scope Management Plan
              1.2.1.6 Work Breakdown Structure
              1.2.1.7 Quality Management Plan
              1.2.1.8 Communications Plan
              1.2.1.9 Change Management Plan
              1.2.1.10       Risk Management Plan
              1.2.1.11       Staffing Management Plan
              1.2.1.12       Procurement Management Plan
              1.2.1.13       Project Closeout Report
              1.2.1.14       compiling and editing
          1.2.2 Final Draft
              1.2.2.1 General Organization
              1.2.2.2 Scope Statement
              1.2.2.3 Cost Management Plan
              1.2.2.4 Earned Value Management
              1.2.2.5 Scope Management Plan
              1.2.2.6 Work Breakdown Structure
              1.2.2.7 Quality Management Plan
              1.2.2.8 Communications Plan
              1.2.2.9 Change Management Plan
              1.2.2.10       Risk Management Plan
              1.2.2.11       Staffing Management Plan
              1.2.2.12       Procurement Management Plan
              1.2.2.13       Project Closeout Report
              1.2.2.14       compiling and editing
              1.2.2.15       Group reviewing, compiling and editing
      1.3     Administrative Tasks
          1.3.1 Team Meetings
              1.3.1.1 Team Meetings 1
              1.3.1.2 Team Meetings 2
              1.3.1.3 Team Meetings 3
              1.3.1.4 Team Meetings 4
              1.3.1.5 Team Meetings 5

26 November 2012 @ 11:12:00 PM              14                  Work Breakdown Structure
                         Senior Design Documentation Library

             1.3.1.6 Team Meetings 6
             1.3.1.7 Team Meetings 7
             1.3.1.8 Team Meetings 8
             1.3.1.9 Team Meetings 9
             1.3.1.10       Team Meetings 10
             1.3.1.11       Team Meetings 11
             1.3.1.12       Team Meetings 12
             1.3.1.13       Team Meetings 13
             1.3.1.14       Team Meetings 14
             1.3.1.15       Team Meetings 15
             1.3.1.16       Team Meetings 16
             1.3.1.17       Team Meetings 17
             1.3.1.18       Team Meetings 18
             1.3.1.19       Team Meetings 19
             1.3.1.20       Team Meetings 20
             1.3.1.21       Team Meetings 21
             1.3.1.22       Team Meetings 22
             1.3.1.23       Team Meetings 23
             1.3.1.24       Team Meetings 24
             1.3.1.25       Team Meetings 25
         1.3.2 Meeting with Sponsor
             1.3.2.1 Meeting 1
             1.3.2.2 Meeting 2
             1.3.2.3 Meeting 3
             1.3.2.4 Meeting 4
         1.3.3 Team Status Report
             1.3.3.1 Team Status Report - 1
             1.3.3.2 Team Status Report - 2
             1.3.3.3 Team Status Report - 3
             1.3.3.4 Team Status Report - 4
             1.3.3.5 Team Status Report - 5
             1.3.3.6 Team Status Report - 6
             1.3.3.7 Team Status Report - 7
             1.3.3.8 Team Status Report - 8
             1.3.3.9 Team Status Report - 9
             1.3.3.10       Team Status Report - 10
         1.3.4 Individual Status Reports
             1.3.4.1 Individual Status Report - 1
             1.3.4.2 Individual Status Report - 2
             1.3.4.3 Individual Status Report - 3
             1.3.4.4 Individual Status Report - 4
             1.3.4.5 Individual Status Report - 5
             1.3.4.6 Individual Status Report - 6
             1.3.4.7 Individual Status Report - 7
             1.3.4.8 Individual Status Report - 8

26 November 2012 @ 11:12:00 PM             15             Work Breakdown Structure
                           Senior Design Documentation Library

              1.3.4.9 Individual Status Report - 9
              1.3.4.10        Individual status Report - 10
          1.3.5 Project Planning
              1.3.5.1 Project Planning 1
              1.3.5.2 Project Planning 2
              1.3.5.3 Project Planning 3
              1.3.5.4 Project Planning 4
              1.3.5.5 Project Planning 5
              1.3.5.6 Project Planning 6
              1.3.5.7 Project Planning 7
              1.3.5.8 Project Planning 8
              1.3.5.9 Project Planning 9
              1.3.5.10        Project Planning 10
              1.3.5.11        Project Planning 11
              1.3.5.12        Project Planning 12
              1.3.5.13        Project Planning 13
              1.3.5.14        Project Planning 14
              1.3.5.15        Project Planning 15
              1.3.5.16        Project Planning 16
              1.3.5.17        Project Planning 17
              1.3.5.18        Project Planning 18
              1.3.5.19        Project Planning 19
              1.3.5.20        Project Planning 20
              1.3.5.21        Project Planning 21
              1.3.5.22        Project Planning 22
              1.3.5.23        Project Planning 23
              1.3.5.24        Project Planning 24
              1.3.5.25        Project Planning 25
              1.3.5.26        Project Planning 26
              1.3.5.27        Project Planning 27
              1.3.5.28        Project Planning 28
              1.3.5.29        Project Planning 29
              1.3.5.30        Project Planning 30
              1.3.5.31        Project Planning 31
              1.3.5.32        Project Planning 32
      1.4     Implementation Research
          1.4.1 Image Processing
              1.4.1.1 Lab View
              1.4.1.2 Matlab
              1.4.1.3 Algorithms
          1.4.2 Product Research
              1.4.2.1 Line sensor
              1.4.2.2 Camera
              1.4.2.3 Vehicle
              1.4.2.4 Embedded System

26 November 2012 @ 11:12:00 PM                 16             Work Breakdown Structure
                         Senior Design Documentation Library

              1.4.2.5 Computer Base Station
              1.4.2.6 Computer Mobile System
              1.4.2.7 Wireless Communication Device
              1.4.2.8 Equipment feasibility study
          1.4.3 Software Development
              1.4.3.1 Embedded language
              1.4.3.2 "C#, Java"
              1.4.3.3 GUI
          1.4.4 Networking
              1.4.4.1 Wireless communication
      1.5     ADS
          1.5.1 Architectural design
              1.5.1.1 Compatibility study
              1.5.1.2 External layers and interfaces
              1.5.1.3 sub components
              1.5.1.4 data flows
              1.5.1.5 inputs and outputs
              1.5.1.6 Combine and review
          1.5.2 ADS documentation
              1.5.2.1 Overview
              1.5.2.2 Layers and interfaces
              1.5.2.3 Sub systems
              1.5.2.4 Inter-subsystem and dataflow
              1.5.2.5 Architecture dataflow
              1.5.2.6 compiling
              1.5.2.7 Group compiling and review
          1.5.3 Presentation
          1.5.4 Final editing after review
      1.6     DDS
          1.6.1 Detailed design
              1.6.1.1 Architecture overview
              1.6.1.2 Detailed component design
              1.6.1.3 Detailed Sub-Component Design
              1.6.1.4 Detailed Interfaces
              1.6.1.5 Combine and review
          1.6.2 DDS Documentation
              1.6.2.1 Overview
              1.6.2.2 Components Designs & Diagrams
              1.6.2.3 Sub Components Design and Diagrams
              1.6.2.4 Interfaces and data flows
              1.6.2.5 Compatibility with SRD
              1.6.2.6 Compiling
              1.6.2.7 Group compiling and review
              1.6.2.8 Presentation
          1.6.3 Final editing after review

26 November 2012 @ 11:12:00 PM            17               Work Breakdown Structure
                          Senior Design Documentation Library

      1.7     Implementation
          1.7.1 Base Station
              1.7.1.1 Graphical User Interface
              1.7.1.2 Wireless Communication
              1.7.1.3 Integration- GUI and Wireless
          1.7.2 Mobile System
              1.7.2.1 Hardware
                  1.7.2.1.1 Embedded System
                  1.7.2.1.2 Line Sensor
                  1.7.2.1.3 Integration
              1.7.2.2 Software
                  1.7.2.2.1 Computing System- Installation
                  1.7.2.2.2 Image processing software
                  1.7.2.2.3 Vehicle control software
                  1.7.2.2.4 Base station communication software
                  1.7.2.2.5 Wireless communication
                  1.7.2.2.6 Other interfaces
                  1.7.2.2.7 Integration- all software components
              1.7.2.3 Integration- hardware and software
          1.7.3 Integration- Wireless (BS) and Wireless (MS)
          1.7.4 Final Modifications after testing
      1.8     Testing
          1.8.1 Testing Implementation
              1.8.1.1 Unit Hardware Testing
              1.8.1.2 Unit Software Testing
              1.8.1.3 Sub component Testing
              1.8.1.4 Component Testing
              1.8.1.5 Integration Testing
              1.8.1.6 Complete System Testing
                  1.8.1.6.1 Verification
                  1.8.1.6.2 Validation and Acceptance
          1.8.2 Test Plan Documentation
              1.8.2.1 Overview
              1.8.2.2 Unit Testing
              1.8.2.3 Component Testing
              1.8.2.4 Integration Testing
              1.8.2.5 Verification
              1.8.2.6 Validation
              1.8.2.7 Test Strategies and Methodology
              1.8.2.8 Test Guidelines
              1.8.2.9 Pass/Fail Criteria
              1.8.2.10        Compiling
              1.8.2.11        Group Compiling and review
              1.8.2.12        Presentation
          1.8.3 Final editing after review

26 November 2012 @ 11:12:00 PM              18                 Work Breakdown Structure
                          Senior Design Documentation Library

      1.9     Project Wrap up and Final Presentation
      1.10 Final Documentation
          1.10.1 User Manual
          1.10.2 Closeout Report
          1.10.3 Future enhancement documentation
          1.10.4 Debug and Error Log documents




26 November 2012 @ 11:12:00 PM               19            Work Breakdown Structure
                               Senior Design Documentation Library




                        7 Quality Management Plan
7.1       Purpose
The purpose of the quality management plan is to ensure the project meets all specifications and
is reliable. This plan will be followed by the team throughout the project development process.

7.2       Components of Plan
Documentation
          The documentation will be reviewed for consistency. While the project manager will
           compile all the documents, each individual team member will be responsible for
           reviewing the compiled documents and correcting any inconsistencies.
          Each team member will also review the documents to verify that they are specific,
           detailed, complete and well written.
          All documents and source code will be maintained in Live Mesh.
Software
          The coding standards of the language(s) used will be followed. Uniform naming
           conventions for variables, classes, methods etc. will be used to maintain consistency.
           Headers and comments will be included throughout the code to describe parts of code
           whenever necessary.
          The code written will be tested and debugged to fix errors and inconsistencies.
          The code will be reviewed by at least two team members before integrating it with the
           rest of the project, to ensure reliability.
          The code and any changes made to the code will be documented.
          Source and change control will be rigorously executed on code to ensure versioning.
Hardware
          The components will be individually tested to ensure they perform necessary
           functionality. Integration of various components will be done only when individual
           components work properly.
Design
          Architecture Design Specifications and Detailed Design Specifications will be followed
           during the development of product to ensure good design.
          Modular structure shall be followed. So, there will be classes and functions which can be
           developed, tested and modified individually.
          The modular structure should be such that changes made in one particular module shall
           have no impact on other modules outside its defined scope.

26 November 2012 @ 11:12:00 PM                     20                   Quality Management Plan
                            Senior Design Documentation Library

      Modular structure will also ensure maximum reusability of each software module like
       functions and classes. This will be done to increase the performance of the product.
Test Plan
      Each unit, hardware and software will be individually tested to make sure that all the
       required functionalities are performed correctly.
      Each integrated component will be tested to ensure functionality.
      After integration of all components, multiple tests runs will be done to ensure
       dependability and reliability of the product by running the vehicle on different paths or
       providing it with different sequences of traffic signs to recognize.
      Completely integrated product will be tested to ensure that it meets the acceptance
       criteria.
Error Log
      Each performance issue or error noticed during the implementation or testing will be
       recorded in the error log.
      Error log will be referred to help enhance the product and remove bugs.




26 November 2012 @ 11:12:00 PM                  21                    Quality Management Plan
                            Senior Design Documentation Library




                        8 Communications Plan
The purpose of the communications plan is to keep the stakeholders informed and updated about
the project activities, events, deliverable deadlines and project progress.

8.1   Team Communication

8.1.1 Team Meetings
Team ALVIS will meet every Wednesday at 7:00pm and on as-needed basis in the Senior
Design Lab. Team meetings will be used to assign tasks, discuss work completed, prepare team
presentations and keep members up to date about team deliverables. Also, each team member
will provide a weekly informal status report to the project manager to ensure that all assigned
deadlines are being met.

8.1.2 Email
Team ALVIS will primarily communicate through email. The project manager will use emails to
notify team members of any changes in team meeting times, work assignments and sponsor
meeting times. Team members can discuss any issues about the project through email. A copy of
each email will be forwarded to every team member for future references.

8.1.3 Cell Phones
Team ALVIS will use cell phones as a secondary means of communication. Team members will
text message or call each other in case of any last minute changes to schedule.

8.1.4 Windows Live Mesh
Team ALVIS will use Windows Live Mesh as a primary repository where all new and updated
documents will be stored. While acting as source control, Live Mesh will also be used to update
other team members of the tasks that have been completed and the ones that remain to be
completed.

8.1.5 Error Logs
Team ALVIS will use error logs to communicate errors, bugs, and performance issues noticed by
team members.




26 November 2012 @ 11:12:00 PM                 22                        Communications Plan
                            Senior Design Documentation Library

8.2   Communication with Sponsor, Department Manager and Other Stakeholders

8.2.1 Email
Team ALVIS will primarily use email to communicate with the sponsor and the department
manager. Emails will be sent to the sponsor to set up appointments, gather information and
requirements, confirm requirements and send updates about the progress of the project. Emails
will be sent to the department manager to clarify deadlines and to address any concerns about the
project, when necessary.

8.2.2 Status Reports
Team status reports and individual status reports delivered every other week would be the
primary means of communication with the department manager. These reports will keep him
updated and will provide information about team’s tasks completed, tasks planned, lessons
learned and problems encountered.

8.2.3 Documents
Team ALVIS will also use major documents such as SRD, Project Charter, Project Plan, ADS,
DDS, and Test Plan etc. to communicate with the department manager.

8.2.4 Gate Reviews and Other Presentations
Team ALVIS will present various important components of the project such as SRD and ADS
before the department manager, TAs and peers. This will be used to explain the component of
the project and take in reviews from the involved stakeholders.




26 November 2012 @ 11:12:00 PM                 23                        Communications Plan
                            Senior Design Documentation Library




                     9 Change Management Plan
9.1   Purpose of Integrated Change Management Plan
This project is a complex undertaking and thus, change is an inevitable part of the project.
Changes can originate from various sources including the sponsor, the department manager or
team members. Accepting change and adapting the project to accommodate changes during the
various phases of development is a challenging and risky task. Changes can be suggested during
requirements gathering, design as well as the implementation phase.
The purpose of the integrated change management plan is to define all processes, practices, tools,
review bodies, and authorities necessary to monitor and control project performance, identify
change and the potential impact of change on project objectives. These changes include changes
throughout the life cycle of the project. Change can be suggested during the requirements
gathering, design as well as the implementation stage. The plan serves as a guideline that will
allow the development team to decide if the change should be accepted or rejected.

9.2   Roles and Responsibilities
      Project Sponsor
      Project sponsor can suggest changes at anytime during the requirements gathering phase of
      the project and also provide reasoning for this action.
      Project Manager
      The project manager will be responsible for arranging meetings with sponsor, team
      members and other stakeholders. This meeting will serve as a platform where the attendees
      can discuss the reasons for supporting or not supporting the change. The project manager
      will take notes of the discussions for future references.
      Project Team
      The team will be responsible for discussing the pros and cons associated with adopting the
      change suggested. The team members will also be responsible for doing vigorous
      feasibility study in order to evaluate whether the change should be approved.
      Other Stakeholders
      The other stakeholders will be able to suggest a change if they think it is suitable. The
      stakeholder’s input will be considered when the team makes the final decision. The team is
      responsible for informing the stakeholders of any changes it approves.




26 November 2012 @ 11:12:00 PM                 24                    Change Management Plan
                                    Senior Design Documentation Library

9.3    Review and Approval Process
Changes suggested by any stakeholder will be reviewed and analyzed before approval. These
suggestions will be discussed in weekly team meetings and its impact on budget, schedule and
workload will be estimated. If the team thinks the change could be necessary to the project, the
project manager will inform the sponsor by emailing him the change approval form. The project
manager will set up a meeting with the sponsor and other team members to discuss the change
suggested, if changes are related to requirements or features. Meetings with technical advisors
will also be arranged by the project manager if design changes are suggested. If every team
member and sponsor agrees that the change will be essential and feasible, the change will be
approved. If one or all of them are strongly against the change, and can justify their reasoning,
the change will be rejected.

9.4    Change Identification, Documentation, Implementation and Reporting
The changes that have been approved will be documented on the change approval form. The
document will be emailed to the sponsor, team members and other stakeholders. After discussing
the change, team members will make an effort to integrate the change into the project without
altering a great deal of the original plan.

Once the impact the change has on the project is estimated, the WBS will be updated to
accommodate for the change being implemented.
                                              CHANGE REQUEST FORM
Date:
Team Name:
Sponsor Name:

Change:
         Details:




Change Suggested By:
Approved/Rejected:
Reasoning for approval/Rejection:



Signature of Project Manager



---------------------------------

26 November 2012 @ 11:12:00 PM                      25                Change Management Plan
                            Senior Design Documentation Library




9.5   Re-base lining
Base lining is setting certain plan in the WBS for schedule and costs. Base lining is done in the
beginning of the project. This is expected to remain throughout the project unless a change
suggested has a significant effect on it. Once a change is approved, the change will be analyzed
to understand its impact on the project budget and schedule. If it is decided the change is
significant and requires re-base lining, then a team meeting will be arranged by the project
manager. The new task assignments and hours for each assignment will be discussed and the
WBS will be re structured to accommodate the new change. The sponsor and other stakeholders
will be informed if re-base lining of the project is done.




26 November 2012 @ 11:12:00 PM                  26                   Change Management Plan
                             Senior Design Documentation Library




                      10 Risk Management Plan
10.1 Purpose of Risk Management Plan
Over its lifecycle, a project faces many uncertainties and problems that need to be tackled in a
correct and timely manner to finish the project with quality, in time and within budget. These
uncertainties and problems are called “Risks”, and we will tackle these risks using our Risk
management plan.
The steps of a risk management plan are: to identify risks, to analyze their effects, and to form a
plan to avoid them or minimize their effects on the project. Moreover, the risk management plan
will include the assignment of the risk managers who would monitor and manage potential risks.
Hence, a good risk management plan is absolutely critical for the success of our project. Since,
identification of risks beforehand will provide us an opportunity to analyze them and come up
with a tackle plan that would either eliminate the risk or minimize its effect, and hence, avoid a
compromise in project quality, schedule delay, or budget overrun.

10.2 Roles and Responsibilities
      Project Sponsor
       The project sponsor will be responsible for notifying team ALVIS of any situation that he
       can think of and that is a potential risk to the project lifecycle.
      Technical Advisor
       The technical advisor will notify the team with all possible risks that lie in his domain of
       knowledge. The team will also communicate all the appropriate risks and their
       avoidance/mitigation plans to the technical advisor and will value his feedback.
      Project Manager
       The Project manager will coordinate with the risk manager to identify and plan for risks
       related to management and administrative tasks, such as assigning work, scheduling and
       setting deadlines. He will also be responsible to communicate the risk management plan
       to project sponsor.
      Project Team
       Team members will work individually and collectively to identify risks and plan for their
       avoidance or mitigation. All team members will notify the risk manager of any new risks
       or changes in plan.
      Project Stakeholders

26 November 2012 @ 11:12:00 PM                  27                        Risk Management Plan
                            Senior Design Documentation Library

       The project team and the project sponsor will be notified about the risk plan in the weekly
       or bi-weekly meetings. Additionally, the department manager will be notified during the
       bi-weekly team presentations. Input about risk identification and planning would be taken
       from all stakeholders throughout the life cycle of the project.
      Risk Manager
       Project Team has assigned Aakash Tuli and Sankar KS to be the risk managers. Their
       major responsibility will be to identify new risks, monitor existing risks, maintain risk
       avoidance/mitigation plan, and communicate any changes to the team. Furthermore, they
       will take input from all stakeholders about risk management and planning.

10.3 Risk Identification
The first step of risk management plan is to identify new risks. These new risks can arise from
project design, requirements, existing plan, changes in plan, schedule etc.
Thus, Project Team has formed an identification plan to identify the risks in a timely manner. A
session in every team and sponsor meeting is assigned to brainstorm possible new risks. During
this session, input is taken from the team members and sponsor. These inputs are used to identify
and review the possible new risks, which are later added to the data repository (Live Mesh) by
the risk managers.

10.4 Risk Triggers
Risk triggers are events that notify the team that the risk event has happened. The risk managers
are responsible for monitoring these triggers, getting the plan ready, and informing stakeholders
of the event.
Following are some triggers set by team ALVIS:
      Deadline missed
      Changes in requirements
      Cross internal budget threshold
      Hardware/Software component not working as expected

10.5 Risk Analysis
Once we are done with the risk identification process, we will perform risk analysis to find their
impact on the project. Firstly, we will use betting method among team members to assign each
risk with a probability that it will happen and a size of loss that it will incur. Then, we will
multiply the probability of loss with size of loss, to give us the risk exposure.
Risk Exposure = Probability of loss * Size of loss (in weeks)
Risk exposure gives us the impact of the risk on the project. Higher the risk exposure, higher will
be the severity of the risk.




26 November 2012 @ 11:12:00 PM                  28                        Risk Management Plan
                            Senior Design Documentation Library

Note: In betting method, we take the bets of individual team members on probability of loss and
size of loss for a risk, and then, average out these values. Bets are usually based of individual
experience and knowledge of the team members.



Risk                            Probability of          Size of Loss (in     Risk Exposure (in
                                Loss                    weeks)               weeks)
Lack of experience with                           0.8                      3               2.4
image analysis and
working with hardware
Schedule conflicts within                         0.5                      2                1
stakeholders
Budget overflow due to                            0.5                      2                1
expensive components
Inefficient project planning                      0.3                      3               0.9
and estimation due to lack
of experience
Inadequate architectural                          0.3                      3               0.9
design
Hardware/Software                                 0.4                      2               0.8
components not working as
expected
Insufficient risk                                 0.3                      2               0.6
management
Over dependence on                                0.2                      2               0.4
certain technologies and
applications during
planning phase
Abandonment of plan                              0.25                  1.5               0.375
under pressure
Inefficient communication                        0.35                      1              0.35
among stakeholders
Change in requirements                            0.1                  2.5                0.25
during life cycle of the
project
Unreliable source control                        0.02                      8              0.16

Feature Gold-Plating                             0.04                      3              0.12

Abandonment of project                           0.02                      4              0.08
by a team member
Team conflicts                                   0.15                  0.5               0.075




26 November 2012 @ 11:12:00 PM                    29                           Risk Management Plan
                              Senior Design Documentation Library

Total Schedule Loss (in                                                                     9.41
weeks)
                                               Table 10-1




10.6 Risk Severity
After we are done with the risk analysis, i.e., we have assigned and calculated probability of loss,
size of loss, and risk exposure. We would sort these risks according to the decreasing order of
risk exposure to give us a list of risks in order of their decreasing priority. This list is called Risk
Severity Grid (table 10.6), and it helps us develop risk containment strategies.

Risk                                    Priority        Strategy     Description of Action

Lack of experience with image           High            Mitigation   Personnel appraisement
analysis and working with                                            will be done and each team
hardware                                                             member will be educated if
                                                                     they lack needed skills.
Schedule conflicts within               High            Mitigation   Plan accordingly
stakeholders
Budget overflow due to                  High            Avoidance    Extensive research will be
expensive components                                                 done to find cheaper
                                                                     alternatives which includes
                                                                     borrowing components
                                                                     from possible sources
Inefficient project planning and        Moderate        Mitigation   Project plan will be refined
estimation due to lack of                                            regularly based on lessons
experience                                                           learnt

Inadequate architectural design         Moderate        Avoidance    Team will consult all
                                                                     stakeholders and do
                                                                     research to correct any
                                                                     issues before
                                                                     implementation
Hardware/Software components            Moderate        Avoidance    Research will be done
not working as expected                                              before procurement of any
                                                                     product
Insufficient risk management            Moderate        Mitigation   Extensive risk analysis and
                                                                     risk management will be
                                                                     done throughout the life
                                                                     cycle of the project by
                                                                     following hybrid waterfall
                                                                     development cycle


26 November 2012 @ 11:12:00 PM                     30                        Risk Management Plan
                             Senior Design Documentation Library

Over dependence on certain            Moderate        Avoidance    Avoid tendency to restrict
technologies and applications                                      planning around a certain
during planning phase                                              applications
Abandonment of plan under             Low             Mitigation   Set smaller milestones to
pressure                                                           ensure consistent progress
                                                                   throughout the
                                                                   development of the project
Inefficient communication             Low             Avoidance    Regular status reports will
among stakeholders                                                 be provided to stakeholders
                                                                   to keep everyone updated.
Change in requirements during         Low             Mitigation   Any requested changes will
life cycle of the project                                          go through rigorous
                                                                   feasibility study before
                                                                   being accepted
Unreliable source control             Low             Avoidance    Online repository will be
                                                                   backed up on regular basis
                                                                   to ensure it's failure has
                                                                   minimum impact.
Feature Gold-Plating                  Low             Avoidance    Any enhancement to
                                                                   product features will be
                                                                   reviewed by the team and
                                                                   compared to requirements
                                                                   to avoid gold plating.
Abandonment of project by a           Low             Acceptance   Major roles have been
team member                                                        assigned to at least two
                                                                   team members to remove
                                                                   any single point of failure.
Team conflicts                        Low             Mitigation   The project manager will
                                                                   coordinate all team
                                                                   meetings to prevent major
                                                                   conflicts among team
                                                                   members.
                                            Table 10-2



10.7 Risk Response Planning
Risk response planning is performed to find strategies that would minimize the effects of risks on
the project’s schedule, time and quality. We will employ one of the following four different
strategies to respond to the risks. Firstly, we will try to avoid the risk by researching new ideas,
and hence, change plans, change requirements, or remove requirements if necessary. Secondly,
we will try to mitigate or reduce effects of the risk with help of a careful plan that would reduce
its probability and size of loss. Thirdly, project team can plan to transfer the risk from a high
priority system to a low priority system. Finally, if none of the above strategies work or the risk
is insignificant then team will prepare a plan to accept the risk.


26 November 2012 @ 11:12:00 PM                   31                       Risk Management Plan
                             Senior Design Documentation Library

To identify the above strategies for the risks, project team will work collectively and the risk
managers will record these plans to the repository.


10.8 Risk Documentation and Reporting
New risks identified by any of the stakeholders are to be immediately informed to the risk
managers. The risk managers, are thereafter, required to actively inform other stakeholders of the
risk through email and add the risks to a excel spreadsheet that would contain the risks’
description, loss of probability, size of loss, and risk exposure. This excel sheet is maintained on
‘Live Mesh’ which is available to all team members.

10.9 Risk Control
The risk managers will be promptly informed of any newly identified risks and they will
consequently address the risks during weekly team meetings, get input from the stakeholders,
and update the response plan in the data repository. Moreover, triggers for the existing risks will
be regularly monitored by the risk managers, who, in case of trigger initiation, will get the plan
ready, and inform stakeholders of the event.




26 November 2012 @ 11:12:00 PM                   32                        Risk Management Plan
                             Senior Design Documentation Library




                   11 Staffing Management Plan
11.1 Purpose of the Staffing Management Plan
It takes people to run a project. The project manager needs a team to produce the deliverables
and maintain control over the project. Project Team members need certain skills to become truly
productive. The project manager needs to ascertain when new people will be required on the
project or when existing team members will be able to leave. This Staffing Management plan
provides the project manager with a framework to identify and justify human resource needs and
provide an effective work force to accomplish the project work.

11.2 Roles and Responsibilities
Refer to Section 1.3 – Roles and Responsibilities


11.3 Project Organization
Refer to Section 1.3 – Roles and Responsibilities


11.4 Resource Requirements
The comprehensiveness of this project requires excellent written and verbal communication
skills which must be practiced throughout the project life cycle. Since this project involves
extensive knowledge of both software and hardware, any team member who may lack certain
development skills will be required to learn them. Also, all project participants are expected to
have knowledge of the organization, policies, and procedures. Other soft skills, such as team
dynamics, negotiation, and facilitation will be beneficial for the development of the product.

11.5 Resource Staffing Plan
As per section 1.3 – Roles and Responsibilities, every team member has been assigned tasks and
thus their presence will be required throughout the development of the product. Except the four
team members and other stakeholders of the project, no outside personnel shall be involved to
any extent throughout the project life cycle.

11.6 Resource Constraints
The team will consist of only four members from the start to the end of the project.



26 November 2012 @ 11:12:00 PM                  33                    Staffing Management Plan
                             Senior Design Documentation Library

11.7 Staffing Reports
Every team member will provide regular status updates to the project manager and the whole
team will give bi-weekly team status representations to the department manager. Also, every
team member will submit a bi-weekly individual status report to the department manager.

11.8 Staffing Contingency Plans
Except the four team members and other stakeholders of the project, no outside personnel shall
be involved to any extent throughout the project life cycle. Absence of any team member will
involve splitting his or her responsibilities among the rest of the team.

11.9 Training Requirements
The comprehensiveness of this project will require a considerable knowledge of software and
hardware during the architectural design and implementation phase. Any team member who
lacks required skills will need to train himself to assure efficient completion of any task assigned
to him. All project stakeholders will be available for assistance and guidance to help the
individual as and when needed.




26 November 2012 @ 11:12:00 PM                   34                    Staffing Management Plan
                            Senior Design Documentation Library




              12 Procurement Management Plan
12.1 Purpose of the Procurement Management Plan
The organization is unable to create or supply all the products and services necessary to complete
the project and therefore needs to use external sources that have the expertise in certain areas to
assist in completing all required project deliverables. Procurement planning gives the project
team knowledge and confidence to obtain quality products and services from qualified vendors
in a timely manner.

12.2 Roles and Responsibilities

12.2.1 Technical Advisor
Our technical advisor, Mr. Matt Middleton, will advise us on the suitable hardware and software
components that we might need for the project. As a technical advisor, he might help us to
acquire some of the products as well.

12.2.2 Project Manager
Project manager, Rachit Aggarwal, will be representing the whole team in terms of
communicating and contacting the sponsor and other stake holders for procurement related
procedures.

12.2.3 Project Team
All details regarding procurement will be discussed during team meetings and will be decided by
all team members together. Total participation of the whole team is required while making any
decision.

12.2.4 Project Stakeholders
Mr. O’Dell’s approval will be required before any commitments are made to purchase a
component. The team will also seek the advice of other stakeholders for suitable software and
hardware procurement. All stakeholders will be informed after a consensus has been reached.

12.3 Required Project Procurements and Timing
Project procurements will be decided during the design phase. Especially by detailed design
phase, it will be necessary to decide the hardware and software components, as design will be
dependant to a large extent on the type of components used. Moreover there will be sufficient
time to obtain the items by the implementation phase. Also, if alternative decisions need to be
made, there will be adequate time to decide and procure before implementation.

26 November 2012 @ 11:12:00 PM                  35              Procurement Management Plan
                             Senior Design Documentation Library

12.4 Description of Items/ Services to be acquired
The project involves making and implementing an autonomous vehicle that recognizes custom
made traffic signs and responds appropriately. The computing system uses the camera to capture
images at continuous intervals, processes them, and instructs the vehicle to move as per the
traffic signs identified in an image. It also sends images and pieces of code to a base station for
debugging purposes. To successfully produce the product, following items/services will be
required:
      Camera
      Radio Controlled Vehicle(Car)
      Radio Controller
      Two Computer systems
      Radio transmitter
      Radio receiver
      Cables
      Battery
      Power Supplier
      Micro controllers
      Software Application for image analysis / development
      Line sensor

12.5 Hardware/Software Acquisition Process

   IT acquisition process involves going through the following process:

   1. Initially a list of components will be made by the team, followed by meeting with sponsor
      to get his advice and approval.
   2. Then the team will discuss with TAs and Mr. O’Dell to find out the components that are
      available for use from the Senior Design Lab.
   3. The above list will be updated after getting the approval from the sponsor for the
      components acquired from the SD lab.
   4. If any software application needs to be acquired form OIT or UTA, a written approval
      will be acquired from Mr. O’Dell and after following the necessary procedure, the
      application may be installed in the computer in SD lab.
   5. If the sponsor or third party lends us any components, Mr. O’Dell will be sought to get
      approval for using the components for developing the prototype of the product and steps
      will be taken to ensure that the acquired components are returned to the owner after the
      final demo.
   6. Every time a component is confirmed, the list will be updated and finally the products
      that need to be purchased will be decided after consulting with all the stakeholders and
      the approval will be forwarded to Mr. O’Dell. Once approved, the purchase will be made
      immediately.
   7. Since the budget is $800, the components purchased will be limited to $400, so as to
      allow buffer budget, in case of any replacement or return.
   8. All stakeholders will be notified if any obtained components need replacement.

26 November 2012 @ 11:12:00 PM                  36              Procurement Management Plan
                             Senior Design Documentation Library

   9. An account of expenditures made will be tracked by the treasurer and will be updated on
      time. Moreover the details of items borrowed will also be maintained properly and
      updated in the repository of the project (Live Mesh)

12.6 Solicitation Planning
The sponsor and team will identify and list all the required components and discuss the cost and
other liabilities associated with each one of them. This list will be refined to ensure that
resources are not wasted and only bare necessities to make the product acceptable are purchased.
The final list will be forwarded to Mr. O’Dell by the project manager for approval.
Only after it is approved, the product will be procured.
The treasurer and the procurement manager will be responsible for maintaining and updating the
expenditure accounts and the inventory of the items procured.

12.7 Applicable Conditions
The budget of purchase of components cannot exceed $800.
If any item is borrowed from any one or any department, it should be returned back to the owner
after the final demo of the prototype. Approval from Mr. O’Dell will be necessary for borrowing
items from third parties.




26 November 2012 @ 11:12:00 PM                  37             Procurement Management Plan
                             Senior Design Documentation Library




                     13 Project Closeout Report
13.1 The following are suggested sections for the Project Closeout Report:

13.2 Purpose of Closeout Report
The closeout report insures that personnel, contract, administrative, and financial issues are
resolved, that documents are archived, and lessons learned are captured.


The closeout report involves providing a complete and detailed record of steps taken during the
lifecycle of this project. This report will include all the documents and other project related
artifacts specified in the following sections of this chapter.

13.3 Administrative Closure

13.3.1 Were the objectives of the project met?
After the completion of the project, the performance of the prototype shall be compared with the
SRD to evaluate the objectives of the project. Any deviation from the baseline will be recorded.

13.3.2 Archiving Project Artifacts
All the documents will be prepared and maintained from the beginning of the project. Everything
will be versioned and archived in the repository (Windows Live Mesh).Following are the
important documents that will be maintained:
      Financial records
      Cost and schedule performance reports and records
      Correspondence
      Meeting Notes
      Status Reports
      Risk Log
      Change Requests
      Acceptance records
      System Requirements Document
      Project Charter
      Project Plan
      Architectural Design Specifications
      Detailed Design Specifications
      Test Plan

26 November 2012 @ 11:12:00 PM                  38                       Project Closeout Report
                            Senior Design Documentation Library

      Other Technical documents


13.3.3 Final Project Notebook
       The final project notebook provided at the end of the development of the project will
       include the following artifacts to ensure that all details are properly recorded and can
       serve as an example to future Senior Design students.

              Final System Requirements Document
              Final Architectural Design Specifications
              Final Project Charter
              Final Project Plan
              Final Detailed Design Specifications
              Final System Test Plan
              Source code files, build instructions and scripts
              Product installation and set-up instructions
              User’s manual
              Follow-on project instructions (if project is not completed)

       Along with providing the final project notebook, team ALVIS will take the following
       actions as a final wrap-up:

              Demonstrate the final product (if project is completed)
              Clean up lab computers
              Clean up the cubicle

13.3.4 Lessons Learned
Each team member will be responsible to record the lessons they learnt during the course of the
project in their individual status reports. All these will be compiled and documented for future
projects. Moreover the risks encountered and how they were avoided and tackled will also be
included in the documentation. The lessons learnt will be discussed during weekly meetings to
avoid repeating them during project development.

13.3.5 Plans for Post Implementation Review (PIR)
After the project is completed, a post implementation review will be made by comparing the
functionalities with the SRD. Also the performance and quality of the product will be assessed at
the end. The feedback from the sponsor and Mike O’Dell will also be considered and
documented.

13.3.6 Final Customer Acceptance
After the completion, the team will compare the acceptance criteria section of the SRD with the
prototype. A demo of the prototype of the product will be conducted in the presence of the
sponsor and other stakeholders after the completion. If the sponsor is not satisfied or in case of

26 November 2012 @ 11:12:00 PM                  39                       Project Closeout Report
                            Senior Design Documentation Library

any other issues, it will be handled appropriately and any incomplete part may be considered for
future enhancement.

13.3.7 Financial Records
The team lead or chosen team member will be responsible for maintaining all financial records.
This will be updated and maintained in the repository (Live Mesh).

13.3.8 Final Project Performance Report
The final project performance report will be created after assessment of the product by the team
members and after getting the feedback from all the stakeholders and sponsor. The performance
will be assessed on the following items:
      Meeting the schedule
      Quality of the product
      Meeting all requirements
      Budget violations (if any)
      Risk management
All variations form cost or schedule and the reasons for them will be documented, which will
serve as a guideline for future projects.




26 November 2012 @ 11:12:00 PM                 40                      Project Closeout Report

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:11/27/2012
language:English
pages:43