CS 221 IT 221 Lecture 14

1
CS 221/ IT 221Lecture 14

• 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 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
• 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
Projects

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

19
Project Needs

• What are we supposed to be doing? -- a vision

20
Vision

• Vision statement
• High level testable requirements
• Subdivision into modules
• Detailed testable requirements for modules

21
Project Needs

• How shall we do it? -- a plan

22
A Plan

• Project plan
• Design overview subdivide into modules
• Interface specifications
• Detailed designs each module
• Programmer assignments
• Schedules
• Risk assessment

23
Project Needs

• Getting down and dirty -- the coding

24
The Coding

• Coding standards
• Version control
• Standardized environments
• Assignments
• Problem reporting and resolution procedures
• Unit testing internal implementation correct
• Unit delivery

25
Project Needs

• Does it work? -- testing, testing goals

26
Testing

• Unit testing
• Integration testing
• Acceptance testing
• Test plans

27
Project Needs

• You want what? -- merging changes

28
Changes

• Requirements change requests
• Investigation, scoping, planning, and reporting
• Merging it into the workflow
• Updating documents, code, and tests

29
Project Needs

• How do I install and use this thing? -- delivery

30
Project Needs

• Bugs? New features? -- new releases

31
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

32
A Roadmap -- Landmarks

• Vision
• Requirements
• Designs
• Interface definitions
• Implementation plans
• Coder assignments
• Test plans
• Tests and test results

33
Project View from Afar
34
View From Afar

• Storyboarding
• Iterative and stepwise refinement
• Making the project flow
• Taking control of what is important
• Ablility to judge relative significance of tasks
• Ability to easily shift resources and focus