CS351/ IT351 Modeling and Simulation Software Engineering Dr. Jim Holten
Jan 12, 2016
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