1. Capstone Presentation
4/20/2001

2. Team Information Team SCRAT: Phil Dudas pmd2@cet.nau.edu
Bryan Schnebly
Sponsor:
Harlan Mitchell
Intel Corp.

3. Manufacturing Station

4. Station Controller

5. Problem Statement New stations require new station controllers
Gathering requirements is time consuming
Perhaps the requirement gathering phase can be sped up with new software tools

6. Value of Technology Solution
Developer productivity
Less time spent gathering requirements
Tool user productivity
Most efficient station controller
Improved information flow
Medium for developer – user communication
-         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

7. Product Description SCST CSCP Station Controller Survey Tool
Customizable Station Controller Prototype

8. SCST Developer creates list of questions
Questions presented to user like a “Wizard”
Answers can be saved to be retrieved and changed later
Answers used to create list of requirements for developer

9. CSCP Customize a prototype station controller
Fields and menu items can be changed to maximize efficiency
User can step through a simulated production run
Can save and retrieve different prototype configurations

10. SCST Screenshot

11. CSCP Screenshot

12. Key Issues Easy to use (desired user is not a Computer Scientist)
Small footprint
The system must run on Windows 98, 2000, and NT version 4.0

13. SCST Design Methodology
Requirements Phase
We used the classic
Waterfall method:
Reason:
Requirements well known
Design Phase
Implementation Phase
Test Phase

14. CSCP Design Methodology
Requirements Phase
Waterfall with
Prototyping:
Reasons:
Requirements could have changed (new SC GUI)
Highly GUI-centric program
Design Phase
Prototype
Implementation
Phase
Prototype
Prototype
Prototype
Test Phase

15. CSCP Methodology Issues
Plan
Return to Requirements or Design after Prototype feedback or change in requirements
Actual
Prototypes served as milestones in development (not much feedback)
Requirements didn’t change (new GUI similar)

16. Development Issues
CSCP Prototyping would have been more effective with more detailed sponsor feedback
A structured iterative approach would have been more effective for both tools
Better task allocation (who’s doing what) would have helped

17. Research Language Choices: Issues Considered: Visual C++ Visual Basic
Java 2
Issues Considered:
Drag and Drop
Possible web deployment
File I/O

18. Design Decisions Language: Java 2 Separate components (SCST and CSCP)
Availability
Familiarity
Satisfied language requirements
Separate components (SCST and CSCP)
Design as a stand-alone app, leave room for web implementation

19. SCST Architecture
Three main components SCST(the GUI), Parser, and Questions
SCST
Parser
Questions
Questions
Text
Radio
Check
Parser

20. CSCP Architecture
Four main components: CSCP (the GUI), Prototype, Demo, and Toolkit
CSCP
Prototype
Demo
Toolkit
Demo
-Demo States
Prototype
Text Fields
Menu Items
Toolkit
Text Fields
Trashcan

21. Architecture Issues Design was left at too high a level
Better component design wasn’t done until implementation
Original design didn’t have logical components correct
The lesson - more detailed detailed design

22. Schedule and Differences
Research: 12/15-1/16
Done on time
Design: 1/31-2/12
About a week late, but was too high level
Implementation: 2/15-3/28
CSCP was about two weeks late
SCST was about four weeks late
Testing: 3/29-4/11
Most testing done during implementation

23. Schedule Issues Schedule was optimistic in beginning
Needed firmer deadlines with real penalties
We counted on slip time and shouldn’t have
More defined resource allocation

24. Final Comments Start implementation (in earnest) when we scheduled it
Schedule as well as possible and then readjust the schedule often
Go further with detailed design

25. Any Questions?