Insights from NATO Software Engineering Conferences and The Software Crisis of the Seventies

Exploring the challenges faced in software engineering during the 1970s, including issues such as project delays, inefficiencies, and the critical need for reliable, high-quality software. Insights from the NATO Software Engineering Conferences shed light on the struggle to meet increasing modern society's demands and the necessity for software modularity, testing, and code reuse to address the software crisis. The era's lessons continue to resonate today in the quest for better software development practices.

• Software Engineering
• NATO
• Seventies
• Modularity
• Software Crisis

kush_51 Follow

Uploaded on Sep 28, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Concerning Modules The Lost Wisdom of the Seventies

2. NATO Software Engineering Conference NATO Science Committee Garmisch, Germany 7-11 Oct 1968

3. NATO Software Engineering Conference We build systems like the Wright brothers built airplanes build the whole thing, push it off the cliff, let it crash, and start over again. Robert M. Graham

4. NATO Software Engineering Conference The problems of achieving sufficient reliability in the data systems which are becoming increasingly integrated into the central activities of modern society. The difficulties of meeting schedules and specifications on large software projects.

5. NATO Software Engineering Conference The Software Gap The Software Crisis

6. NATO Software Engineering Conference The Software Gap The Software Crisis

7. The Software Crisis Projects running over-budget. Projects running over-time. Software was very inefficient. Software was of low quality. Software often did not meet requirements. Projects were unmanageable and code difficult to maintain. Software was never delivered.

8. BUGS!

9. Software design is unlike engineering because it lacks the constraints and comforts of reality. A single bug can cause a system to fail.

10. BUGS Severe Trivial Obvious Subtle

11. Modularity Confinement of errors Large team development Testing Portability Secure Boundaries Code Reuse What makes a good software module?

12. The Lost Wisdom of the Seventies

13. Edsger Dijkstra The Humble Programmer. [1972]

14. The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

15. William Wulf A Case Against the GOTO. [1972]

16. More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason including blind stupidity.

17. David Parnas On the Criteria to be Used in Decomposing Systems into Modules. [1972]

18. Information Hiding A module hides a design decision.

19. Glenford Myers Larry L. Constantine Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design with Ed Yourdon [1979] Reliable Software through Composite Design [1975] Composite/Structured Design [1978]

20. Cohesion Relatedness Coincidental Logical Temporal Procedural Communicational Sequential Functional Weak Strong

21. Coupling Connectedness Tight Content Common External Control Stamp Data Loose

22. Alan Kay Smalltalk [1971]

23. Object Oriented Programming Everything is an object Objects communicate by sending and receiving messages Objects have their own memory

24. Object Oriented Programming Objects and Messages

25. Object Oriented Programming Objects and Messages Classes and Members

26. Object Oriented Programming Objects and Messages Classes and Members Unfortunately, inheritance though an incredibly powerful technique has turned out to be very difficult for novices (and even professionals) to deal with. [1993]

27. Object Oriented Programming Objects and Messages Classes and Members Exception Coupling Banana Coupling Inheritance Coupling

28. Object Oriented Programming Objects and Messages Classes and Members Member Coupling Getter/Setter Coupling Type Coupling

29. Carl Hewitt Actor Model [1973]

30. Guy L. Steele Gerald Jay Sussman Scheme [1975]

31. Higher Order Functions

32. Modular Levels Services. Processes. Packages. Objects. Subroutines Procedures Methods Functions

33. Modular Levels Services. Processes. Packages. Objects Subroutines

34. Modular Levels Services. Processes. Packages Objects Subroutines External files Libraries Frameworks

35. Modular Levels Services. Processes Packages Objects Subroutines Unix | tools

36. Modular Levels Services Processes Packages Objects Subroutines

37. Everything is a _______. Everything is not a _______.

38. Everything is a _______. Everything is not a _______.

39. Remote Procedure Call Everything is a subroutine.

40. The messages must flow. Services organized as actors. Services have strong functional cohesion. Services are loosely coupled. Secure message passing with JSON over TCP/IP. Services can include secure service addresses in messages.

41. NATO Software Engineering Conference Be careful that the design team will not have to spend all its time fending off users. [1968]

42. Avoid mid-project design changes. Avoid making unwanted software.

43. Annual Team Sprints With Customers Call center Customer service Sales support Empathy

44. Annual Team Sprints With Customers Make software for real people, not for fictional characters. [2019]

46. Concerning Modules or The Lost Wisdom of the Seventies