Team Members Email Addresses
Phil
Bryan
Sponsor: Harlan
November 29, 2000
Version 1.5
Table of Contents
Table of Contents
Table of Figures:
1.0Introduction
1.1Purpose
1.2Making Changes to this Document
2.0Problem Statement
2.1Background / History
2.2Business Issues
2.3Value of a Technology Solution
2.4Business Environment
3.0Product / Solution Statement
3.1Product Descriptions
4.0Requirements
4.1Functional Requirements
4.1.1Customizable Prototype Station Controller (CPSC)
4.1.2Station Controller Survey Tool (SCST)
4.2Non-Functional Requirements
4.3Constraints
5.0Cost / Benefit Analysis
5.1Estimated Life Cycle Costs
5.2Tangible Benefits
5.3Intangible Benefits
6.0Risk Assessment
7.0Organization and Management
7.1Team Roles
7.1.1Leader
7.1.2Communicator
7.1.3Recorder
7.2Team Meetings
7.3 Status Reports Every week during the semester, the team will produce a status report documenting the activities of that week. This status report will go to each team member, the sponsor, and the professor. The report will consist of two main sections one for team activity and another for individual accomplishments. These reports will be used to keep every up to date on what is being done for the project, as well as who is doing it.
7.4 Document Standards
7.5Self Evaluation Method
7.6Standards of Behavior
8.0The Design and Development Processes
8.1Design Processes
8.1.1Design Process for the CSCP
8.1.2Design Process for the SCST
8.2Deliverables
8.2.1Deliverables for the CSCP
8.2.2Deliverables for the SCST
9.0Project Schedule
10.0The Technical Concept
10.1High Level Architecture
10.1.1CSCP Architecture
10.1.2SCST Architecture
Appendix B: Gantt Chart
Table of Figures:
Figure 1: Screenshot of station controller 6
1.0Introduction
1.1Purpose
This document will detail our proposal for the tools we will provide for station controller requirements acquisition. We will review the requirements, including specifications. We will analyze the costs and benefits of our products. We will discuss the risks involved with the project, as well as our plans to mitigate those risks. We will cover our team organization and management plan. We will outline our design/development processes. We will lay out a schedule, including milestones, deliverables, and final product delivery. We will also include a high level architecture identifying areas for further investigation.
1.2Making Changes to this Document
Changes to this document can be requested by the sponsor, or by members of Team SCRAT. Changes to the proposal will be negotiated between the team and the sponsor, and must be signed off on by both parties before being committed to.
2.0Problem Statement
2.1Background / History
This product will help station controller developers do their job. Currently, with each new manufacturing tool, a station controller has to be developed to control that tool according to the user’s guidelines. A station controller developer sends a requirements questionnaire to the tool user. The results of this questionnaire are used to generate a list of requirements for a station controller for the tool. Then a requirements document is produced for the station controller. After document approval, the developer can then begin implementing the station controller according to the requirements agreed upon. Currently, there is no input from the user as to the look and feel of the station controller interface before its implementation.
2.2Business Issues
In this section we will outline some of the business issues that are driving the development of this product.
-Developer Productivity
Station controller developers now spend a good deal of time doing requirements acquisition. This product will shorten that time dramatically.
-Tool User Productivity
Tool users will have a station controller that they had a direct impact on designing. The controller will be produced to the users specifications, which will have a number of beneficial effects. Being able to see and touch a life like prototype will reduce changes to the look, feel, and functionality of the alpha version of the product. The prototype will also better allow users to define features and functionality.
-Improved Information Flow
One area where the process can be improved upon is the time it takes to get requirements from the users. Our tool will allow faster and better communication of requirements between users and developers.
2.3Value of a Technology Solution
A solution produced by us will be highly valuable. Since we don’t get paid, any use of the system we produce will be infinitely valuable (something / nothing = infinity). Automating the process of requirements acquisition will save the developers a lot of time. This product will also produce better station controllers, due to the end-user’s direct influence in the design.
2.4Business Environment
The station controller users and developers are distinct groups. To gather requirements, a developer needs go to the users group either physically or electronically. Our software provides a new means of interaction between the two groups.
3.0Product / Solution Statement
3.1Product Descriptions
Our toolkit will consist of two separate programs. One tool is a station controller survey tool (SCST). The other tool is a customizable prototype station controller (CPSC).
The survey tool will allow a developer to write a list of questions. The survey tool will present these questions to the user, allowing them to enter answers. The answers will be used to create a list of requirements for the developer.
The CPSC will enable the user to customize a prototype station controller. The fields (size and position) and menu items can be changed to let the user get the most efficient use of the tool. The CPSC will look like an actual station controller. The following screenshot shows what the CPSC will be modeled after.
Figure 1: Screenshot of station controller
4.0Requirements
4.1Functional Requirements
4.1.1Customizable Prototype Station Controller (CPSC)
-Change size of text fields
-Change position of text fields
-Change items in pull down menus
-Save current configuration (field and menu properties)
-Run a demo of SC through all states in a production run
-Look like a functional station controller
4.1.2Station Controller Survey Tool (SCST)
-Load list of questions
-Produce form from question list
-Collect answers from form
-Generate an MS Word requirements document from answers
4.2Non-Functional Requirements
-Easy to use (desired user is not a Computer Scientist)
-Easy to get to users
-Small footprint
4.3Constraints
- The system must run on Windows 98, 2000, and NT version 4.0
5.0Cost / Benefit Analysis
5.1Estimated Life Cycle Costs
We estimate that there will be only minimal costs involved with this product over a three to five year life cycle.
The only costs projected to be involved with the development of the product will be costs incurred in communication between the team and the sponsor.
Once the development is complete, the only costs involved with the project will come from the time spent by the users learning to use it. We anticipate that the time required to learn to use the product will be minimal. Users should be proficient with the CSCP after 30 minutes of use. The SCST will also take a similar amount of time to learn to use.
5.2Tangible Benefits
We anticipate that these products will reduce the time spent on requirements gathering. This will have two major benefits.
Firstly, it will allow the station controller developer to be more productive since there will be less time involved waiting for responses from the user community.
Secondly, it will allow the station controller to go online quicker, allowing the manufacturing tool that it controls to begin production sooner. The sooner production begins, the more chips can be made, the more revenue will be generated.
5.3Intangible Benefits
The intangible benefits come mostly from worker satisfaction. Both the station controller developers and users will be happier with their jobs. Happier employees are more productive employees and are less likely to leave the company.
The developers will be happier because this product will help them do their job more quickly and accurately. The will be able to see a visual representation of what the user wants the station controller to look like and what functions are needed.
The users will be more satisfied because they will feel that they had a more direct impact on the design of the station controller. Even though they now tell the developers what they need the station controllers to do, there is no direct visual confirmation that what they said had any affect on the final design. With the CSCP, they will be able to see that the station controller looks and acts how they specified.
6.0Risk Assessment
-Learning new technology
This project will entail technologies that team members have little to no experience with. These technologies may include but are not limited to: MFC Visual C++, Microsoft Visual Basic, Swing components of Java, and drag and drop technologies. At this point, we don’t know what techniques we will need to use.
To mitigate this risk, we have scheduled a month of individual research time, to look into each of these things, learn how to use them, and decide what will best suit the needs of this project.
-Changing requirements
At the beginning of this project, we were told that the requirements would be a moving target. We haven’t as of yet had any of our requirements change, but are planning on that as a possibility.
In our preliminary visit with the sponsor, he informed us that Intel is in the process of redesigning the station controllers. This redesign could change the project requirements at any point in the project.
To mitigate this risk, we are using an incremental design process. This process is more able to accommodate any changes that might occur during development.
-Sponsor changing divisions
When we first met with our sponsor, he told us that he will possibly be changing divisions and moving away from station controller development. This poses a big risk to the success of our project because he is our only contact with Intel. If he changes divisions without informing other station controller developers of our project, it will never get used.
To mitigate this risk, we are going to keep in contact with our sponsor and make sure that if he does change divisions, that he continues to support our project.
-Interfacing with proprietary software
One of the requirements of the project is that the SCST produces a document in Microsoft Word format. We still don’t know if this is possible, and if it is possible, we don’t know how to do it.
To mitigate this risk, we are going to devote a part of our research time to answering this question. If we find out that it is not possible, then we will ask the sponsor to change the requirement to accept a text document.
-User aptitude unknown
We are assuming that the station controller users are fairly proficient with computers, but we cannot be sure of this. It is possible that the users cannot use computers well.
To mitigate this risk, we are designing the components of our product to be simple to use and very intuitive. This simplified design should make the product usable for anybody that has ever used windows. If the product still ends up being too complex, the station controller developers will become the primary users. The use of the software will change from that of customization to that of prototype demonstration.
-Time constraints
The project has a fixed end point, and unlike most real world applications, this end point cannot be slipped to accommodate for delays in any stage of the development process.
To mitigate this risk, we have made a schedule that will meet the end of the semester deadline. A portion of each team meeting is dedicated to reviewing the schedule and assessing our progress against it. This will allow us to know when we are falling behind our schedule and allow us to redouble our efforts in order to keep on track. It will also allow us to adjust our schedule within certain limits.
-Small team
Our team is made up of only two people. This means that each member has a lot of responsibilities in the project. If for some reason a teammate fails to live up to his responsibilities, there is nobody to take over for him.
To mitigate this risk, we have each recognized that this is a potential problem and will work to carry our own weight. We have also agreed to try to help each other fulfill our responsibilities as much as we can.
-Other work
This is our last year of school, and we each have other classes to attend. These classes will give us work to do so our time cannot be monopolized by one project alone.
To mitigate this risk, we have made a schedule to follow. This schedule will help us focus the necessary amount of time on the project without letting other classes fall too far behind.
7.0Organization and Management
7.1Team Roles
7.1.1Leader
Phil Dudas: Team leader responsibilities include scheduling meetings in addition to weekly meetings, running meetings, assigning tasks to team members.
7.1.2Communicator
Bryan Schnebly: The communicator is responsible for all communications between the team and the outside entities, including class professor and project sponsor.
7.1.3Recorder
Bryan Schnebly: The recorder is responsible for maintaining the team notebook.
7.2Team Meetings
Team meetings will be held weekly in the Sun lab (Rm. 137) of the Engineering building. Other meetings will be scheduled and located as necessary.
Each meeting will start with a review of the upcoming deadlines and schedule. After this each team member will review the status of his assignments from the previous meeting, asking for input if needed. After this, the assignments for the next week will be given out and any other issues will be discussed. The meeting will then be adjourned until the next scheduled meeting time.
Decisions will be based on a full agreement between all team members.
Attendance is very important, and if a team member is planning on missing a meeting he must make it known at least one day in advance. Any meeting can be rescheduled by common consent of the group for attendance purposes.
7.3 Status ReportsEvery week during the semester, the team will produce a status report documenting the activities of that week. This status report will go to each team member, the sponsor, and the professor. The report will consist of two main sections one for team activity and another for individual accomplishments. These reports will be used to keep every up to date on what is being done for the project, as well as who is doing it.
7.4 Document Standards
Team documents will be written in Microsoft Word 2000 format. All document standards are subject to revision depending on sponsor requirements.
Both team members will work on each document. When anything written by one person is merged into the group document, both team members must be present. All team members will assemble each document together; this will incorporate a review of the material at the same time.
The version of each document will be controlled by having the last revision date in the name of the file. A version number will also be written at the bottom of the title page of each document.
Each document will be written using 12-point Times New Roman font. Each document will be in block format and single-spaced. The headings of major sections of each document will be bold 14-point font. Headings of subsections will be bold 12-point font. All headings will be numbered hierarchically.
7.5 Self Evaluation Method
Team self evaluation will take place at the time of each scheduled peer evaluation. This team self evaluation will take the form of an informal talk that assesses team goals and progress made towards them.
7.6 Standards of Behavior
Meeting behavior will be governed by common sense. Common rules of meeting etiquette will apply. If any breach of etiquette occurs, the offending party will be reminded by the rest of the team that his behavior is unacceptable. If this does not work, then a third party will be called in to deal with the situation.
8.0The Design and Development Processes
8.1Design Processes
8.1.1Design Process for the CSCP
We are going to use an incremental prototyping methodology for the development of the CSCP. Since the CSCP is highly user interface oriented, prototyping will be a useful method to help with the design and implementation.
We are considering three languages to program the CSCP. We will further investigate Java (including Swing), Visual C++ (including MFC), and Visual Basic to determine the proper choice for the job.
8.1.2Design Process for the SCST
We will use the waterfall method for the SCST development. The requirements are fairly straight forward, and known upfront, which makes the waterfall method feasible.
We haven’t decided which language to use for the SCST, but it will likely be the same language we choose for the CSCP.
8.2Deliverables
8.2.1Deliverables for the CSCP
-Design Document
This document will detail the design of the CSCP including, but not limited to: overall architecture, use cases and scenarios, and class diagrams.
-Code
This will be the documented source code of the CSCP.
-Application
This is the program in executable form, or in an installable package.
-User Guide
This will accompany the application with information on installation and use. It will detail program functionality completely.
8.2.2Deliverables for the SCST
-Design Document
This document will detail the design of the SCST including, but not limited to: overall architecture, use cases and scenarios, and class diagrams.
-Code
This will be the documented source code of the SCST.
-Application
This is the program in executable form, or in an installable package.
-User Guide
This will accompany the application with information on installation and use. It will detail program functionality completely.
9.0Project Schedule
Our proposed schedule includes the following tasks and milestones: Proposal Document, Proposal Presentation, Research Phase, Design Phase, Design Document, Design Presentation, Implementation Phase, Documentation, Testing Phase, Capstone Presentation, Capstone Design Conference, Product Delivery, and the Post-Mortem Phase.