Capstone Presentation 4/20/2001

Team Information Team SCRAT: Phil Dudas pmd2@cet.nau.edu Bryan Schnebly Bryan.Schnebly@nau.edu Sponsor: Harlan Mitchell harlan.w.mitchell@intel.com Intel Corp.

Manufacturing Station

Station Controller

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

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

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

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

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

SCST Screenshot

CSCP Screenshot

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

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

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

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)

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

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

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

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

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

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

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

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

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

Any Questions?