1. CS351/ IT351 Modeling and Simulation Software Engineering Dr. Jim Holten

2. Overview  A Little History  Project Needs  The Roadmap  A View from Afar

3. History  In the beginning...

4. Machine code  Machine code is cryptic  It was a new concept, so people had to train themselves  There were no design and development procedures to follow, so they invented their own.  Code development was slow and unreliable.  Good coders needed EXTREME discipline.  Coordinating multiple efforts was....??

5. History  Order out of chaos

6. Development Process  Describe the problem in written language.  Refine the concepts toward algorithms in the available instructions.  Write the code.  Translate to machine code.  Put the program into the machine and run it.

7. History  Formalized approaches to software engineering

8. Project Management Approaches  Waterfall...  Formal reviews.  Sign-offs.  Engineering Change Proposals........?  Spiral...  Waiting while we get sign-off....

9. Software Developer Approaches  Top down design and coding  Bottom up design and coding  Mixtures of top-downs and bottom-up  Objects  Patterns  Data Flow Diagrams, SADT, HIPO, state diagrams, flow charts, ER diagrams,...  UML

10. Tools  IDEs  CASE  Blah blah blah....  Nice concepts and features, but not “complete”.  Buggy too!  Heavy overhead – slows development.

11. History  Getting less formal

12. Management Impatience  Takes too long!  Want results right away!  Must invest too much before we see any results!  Frustrating!

13. Developer Impatience  Too much documentation!  Squelches creativity!  Frustrating!

14. Alternatives  Rapid prototyping  Extreme programming  Rapid development  Empower the programmer

15. History  Losing it

16. Self-organizing Developers?  Seven blind men and the elephant  Whose vision do I follow?  Each doing their own “right thing”  Why won't they include this essential item in their interface for me?  Who's in charge here?  HELP!!!

17. History  In the beginning...  Order out of chaos!  Formalized approaches to software engineering  Getting less formal  Losing it

18. Project View from Afar

19. Projects  What does a project NEED?  How should it be organized?  Who should decide?  How do we coordinate priorities and choices made?

20. Project Needs  What are we supposed to be doing? -- a vision

21. Vision  Vision statement  High level testable requirements  Subdivision into modules  Detailed testable requirements for modules

22. Project View from Afar

23. Project Needs  How shall we do it? -- a plan

24. A Plan  Project plan  Design overview – subdivide into modules  Interface specifications  Detailed designs – each module  Programmer assignments  Schedules  Risk assessment

25. Project View from Afar

26. Project Needs  Getting down and dirty -- the coding

27. The Coding  Coding standards  Version control  Standardized environments  Assignments  Problem reporting and resolution procedures  Unit testing – internal implementation correct  Unit delivery

28. Project Needs  Does it work? -- testing, testing goals

29. Project View from Afar

30. Testing  “Unit” testing  Integration testing  Acceptance testing  Test plans

31. Project Needs  You want what? -- merging changes

32. Changes  Requirements change requests  Investigation, scoping, planning, and reporting  Merging it into the workflow  Updating documents, code, and tests

33. Project View from Afar

34. Project Needs  How do I install and use this thing? -- delivery

35. Project Needs  Bugs? New features? -- new releases

36. Project Needs  What are we supposed to be doing? -- a vision  How shall we do it? -- a plan  Getting down and dirty -- the coding  Does it work? -- testing, testing goals  You want what? -- merging changes  How do I install and use this thing? -- delivery  Bugs? New features? -- new releases

37. A Roadmap -- Landmarks  Vision  Requirements  Designs  Interface definitions  Implementation plans  Coder assignments  Test plans  Tests and test results

38. Project View from Afar

39. View From Afar  Storyboarding  Iterative and stepwise refinement  Making the project “flow”  Taking control of what is important  Ability to judge relative significance of tasks  Ability to easily shift resources and focus

40. Project View from Afar