CS 351 IT 351 Lecture 07 Software Engineering

CS 351/ IT 351 Lecture 07 Software Engineering Dr. Jim Holten

Overview A Little History Project Needs The Roadmap A View from Afar

History In the beginning. . .

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. . ? ?

History Order out of chaos

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.

History Formalized approaches to software engineering

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

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

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

History Getting less formal

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

Developer Impatience Too much documentation! Squelches creativity! Frustrating!

Alternatives Rapid prototyping Extreme programming Rapid development Empower the programmer

History Losing it

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!!!

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

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

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

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

Project Needs How shall we do it? -- a plan

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

Project Needs Getting down and dirty -- the coding

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

Project Needs Does it work? -- testing, testing goals

Testing “Unit” testing Integration testing Acceptance testing Test plans

Project Needs You want what? -- merging changes

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

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

Project Needs Bugs? New features? -- new releases

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

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

Project View from Afar

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