1 / 40

Evolution of Software Engineering: From Chaos to Structure

This overview by Dr. Jim Holten explores the historical development of software engineering, detailing its chaotic beginnings with machine code to the establishment of formalized processes. It emphasizes the challenges faced in early coding practices, the evolution of project management approaches like Waterfall and Spiral, and contemporary trends toward rapid prototyping and self-organizing teams. The necessity for clear vision, planning, coding standards, and effective testing is stressed, ultimately guiding teams toward more efficient and orderly software delivery.

autumn-levine
Télécharger la présentation

Evolution of Software Engineering: From Chaos to Structure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Dr. Jim Holten CS351/ IT351Modeling and Simulation

  2. Overview • A Little History • Project Needs • The Roadmap • A View from Afar

  3. In the beginning ... History

  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. Order out of chaos History

  6. Development Process • Describe the problem in written language. • Refine the concepts toward algorithms in theavailable instructions. • Write the code. • Translate to machine code. • Put the program into the machine and run it.

  7. Formalized approaches to software engineering History

  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 of top-downs and bottom-up • 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. Getting less formal History

  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. Losing it History

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

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

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

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

  22. Project View from Afar

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

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

  25. Project View from Afar

  26. Getting down and dirty -- the coding Project Needs

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

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

  29. Project View from Afar

  30. Testing • “Unit” testing • Integration testing • Acceptance testing • Test plans

  31. You want what? -- merging changes Project Needs

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

  33. Project View from Afar

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

  35. Bugs? New features? -- new releases Project Needs

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

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

  38. Project View from Afar

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

  40. Project View from Afar

More Related