CS351/ IT351Modeling and Simulation

Software Engineering

Dr. Jim Holten

Overview

A Little History

Project Needs

The Roadmap

A View from Afar

History

In the beginning ...

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

History

Order out of chaos

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.

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 of top-downs and bottom-up

Objects

Patterns

Data Flow Diagrams, SADT, HIPO, state diagrams, flow charts, ER diagrams, ...

UML

Tools

IDEs

CASE

Blah 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 engineeringGetting less formalLosing it

Project View from Afar

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

Vision statement

High level testable requirements

Subdivision into modules

Detailed testable requirements for modules

Project View from Afar

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 View from Afar

Project Needs

Getting down and dirty -- the coding

The Coding

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

Project View from Afar

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 View from Afar

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 visionHow shall we do it? -- a planGetting down and dirty -- the codingDoes it work? -- testing, testing goalsYou want what? -- merging changesHow do I install and use this thing? -- deliveryBugs? New features? -- new releases

A Roadmap -- Landmarks

VisionRequirementsDesignsInterface definitionsImplementation plansCoder assignmentsTest plansTests and test results

Project View from Afar

View From Afar

StoryboardingIterative and stepwise refinementMaking the project “flow”Taking control of what is importantAbility to judge relative significance of tasksAbility to easily shift resources and focus

Project View from Afar