CS 221/ IT 221 Lecture 14 Software Engineering Dr. Jim Holten.

34
CS 221/ IT 221 Lecture 14 Software Engineering Dr. Jim Holten
  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    216
  • download

    0

Transcript of CS 221/ IT 221 Lecture 14 Software Engineering Dr. Jim Holten.

CS 221/ IT 221Lecture 14

Software Engineering

Dr. Jim Holten

Overview

A Little HistoryProject NeedsThe RoadmapA View from Afar

History

In the beginning ...

Machine code

Machine code is crypticIt was a new concept, so people had to train themselvesThere 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 codingBottom up design and codingMixturesObjectsPatternsData Flow Diagrams, SADT, HIPO, state diagrams, flow charts, ER diagrams, ...UML

Tools

IDEsCASEBlah 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 prototypingExtreme programmingRapid developmentEmpower the programmer

History

Losing it

Self-organizing Developers?

Seven blind men and the elephantWhose 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

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 statementHigh level testable requirementsSubdivision into modulesDetailed testable requirements for modules

Project Needs

How shall we do it? -- a plan

A Plan

Project planDesign overview – subdivide into modulesInterface specificationsDetailed designs – each moduleProgrammer assignmentsSchedulesRisk assessment

Project Needs

Getting down and dirty -- the coding

The Coding

Coding standardsVersion controlStandardized environmentsAssignmentsProblem reporting and resolution proceduresUnit testing – internal implementation correctUnit delivery

Project Needs

Does it work? -- testing, testing goals

Testing

“Unit” testingIntegration testingAcceptance testingTest plans

Project Needs

You want what? -- merging changes

Changes

Requirements change requestsInvestigation, scoping, planning, and reportingMerging it into the workflowUpdating 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 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 importantAblility to judge relative significance of tasksAbility to easily shift resources and focus