1. As-Built Presentation 4/11/2001

2. Team Information Team SCRAT: Phil Dudas Bryan Schnebly Sponsor: Harlan Mitchell, Intel Corp.

3. Introduction Project Description Project Description Design / Development Paradigms Design / Development Paradigms Tools / Languages Used Tools / Languages Used Requirements and Specifications Requirements and Specifications Architecture Issues Architecture Issues Schedule / Resources Schedule / Resources Final Comments Final Comments

4. Project Description Goal: Help station controller developers gather requirements Goal: Help station controller developers gather requirements –SCST (Station Controller Survey Tool) »SC developers write SCST question list file »SCST produces executable “Wizard” for tool users »Tool users answer questions, sending results back to SC developers –CSCP (Customizable Station Controller Prototype) »Tool users manipulate a clone of real SC »The finished custom SC will be used by SC developers to provide the desired functionality

5. SCST Screenshot

6. CSCP Screenshot

7. Design / Development Paradigms SCST SCST –We used the classic Waterfall method (OOP) –Reason: »Requirements well known from start of project CSCP CSCP –Waterfall with Prototyping (OOP) –Reasons: »Requirements could have changed (new SC under Development) »Highly GUI-centric program

8. Development Issues CSCP Prototyping would have been more effective with more detailed sponsor feedback CSCP Prototyping would have been more effective with more detailed sponsor feedback A structured iterative approach would have been more effective for both tools A structured iterative approach would have been more effective for both tools

9. Tools / Languages Used Language: Java 2 Language: Java 2 Forte Forte JAR files JAR files –CSCP Version control –CSCP Prototype Delivery – executable JAR Books Books –Professional Java Programming –Java in a Nutshell –Java Foundation Classes in a Nutshell –Problem Solving with Java Java API Java API

10. Requirements and Specifications Requirements didn’t change much Requirements didn’t change much New SC GUI is in development still, but looks just like the old one – didn’t affect us New SC GUI is in development still, but looks just like the old one – didn’t affect us Web implementation not a requirement Web implementation not a requirement –Prototype didn’t work for “Intel special” IE –Did work on all required platforms –So … we didn’t need to worry about it

11. SCST Architecture and Changes Original Components: Original Components: –Parser, Saver, QuestionList, QUI, DocWriter Final Components: Final Components: –QUI remained the same –QuestionList became just a vector of Question objects in the QUI –Question types do their own parsing –DocWriter simplified

12. CSCP Architecture and Changes Original Components: Original Components: –GUI, TextFieldList, MenuItemList, DemoScripts, Reader, Saver, DocWriter Final Major Components: Final Major Components: –GUI (with file I/O – no more Reader and Saver) –Toolkit (source of new text fields for Prototype) –Prototype (contains text fields, menu items, table, and message area) –Demos (DemoStates, DemoDialogs, created from text script) –DocWriter dropped for now – not a requirement

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

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

15. Schedule Issues Schedule was optimistic in beginning Schedule was optimistic in beginning Needed firmer deadlines with real penalties Needed firmer deadlines with real penalties Shouldn’t have been planning on slip time Shouldn’t have been planning on slip time More defined resource allocation More defined resource allocation

16. Final Comments Start implementation when we scheduled it Start implementation when we scheduled it Schedule correctly and then follow it Schedule correctly and then follow it Go further with detailed design Go further with detailed design

17. Any Questions?