|
|
|||||||||||||||||||
|
Coutse Outline
Challenger Disaster Disclaimer Natl Sec Space Engineer – Mgr Conflicts Chief Scientist Analytic & Gaming Sims Complex Systems |
Much of Engineering requires software development, so this segment investigates the classic text, The Mythical Man – Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), by Frederick P. Brooks. But much, perhaps most, of Brooks' work pertains to project management as well. And it is apparently not widely recognized, but much of what Brooks described predicted the importance of, and difficulties associated with, Complex Systems. The following is a small sample of Brooks' work, and of what the course covers. |
||||||||||||||||||
|
|
|||||||||||||||||||
|
On page 166, Brooks defines test cases: | |||||||||||||||||||
|
Minimal test cases
— Reassure the user that the program works ok — Are these all that are typically created? Thorough test cases — Test program’s chief functions for common data Barely legitimate cases — Probe the edge of the input domain Barely illegitimate cases — Probe the input domain from the other side — Ensure diagnostic messages are raised by improper input |
|||||||||||||||||||
| TOP | |||||||||||||||||||
|
| |||||||||||||||||||
|
The following is an input screen to a simple program, which calculates an orbit trajectory given some parameters such as semimajor axis, eccentricity, and launch latitude, longitude, and altitude. |
|||||||||||||||||||
| Orbit Semimajor Axis (km) | |
Eccentricity | | |
| |||||||||||||||
| Latitude (deg) | |
Longitude (deg) | |
||||||||||||||||
| Altitude (km) |
|
Azimuth (deg) |
|
||||||||||||||||
| Earth Semimajor Axis (km) | 6378.137 | # significant figures (4-9) |
|
||||||||||||||||
| Earth Eccentricity | .0818191908426 | Output interval (sec) | 10 | ||||||||||||||||
| Trajectory Format |
|
||||||||||||||||||
| |
|||||||||||||||||||
| TOP | |||||||||||||||||||
|
Semimajor axis — Must be > half of Earth Radius Eccentricity — Must be at least zero — Must be less than one Latitude — Must be no greater than 90 degrees — Must be no less than -90 degrees Altitude — Must be at least zero — Actual max depends on project Earth Semimajor Axis — Must be close to 6371 km Number of significant figures — Must be at least four — Must be no more than ten — Must be whole number Output interval — Must be greater than zero — Must be less than flight time — Actual min depends on project — Actual max depends on project |
The Trajectory Format is "L" for latitude/longitude/altitude; is "E" for Earth-Centered Earth-Fixed (ECEF) coordinates. The user enters the desired values in the white areas, then chooses "Spherical Earth" or "WGS-84 Earth"; the former does not use the Earth eccentricity. The latter does, and allows the user to set it. The user then pushes the "CALCULATE" button. The program checks the input for validity, then runs the program. | ||||||||||||||||||
| TOP | |||||||||||||||||||
|
|
|
||||||||||||||||||
|
Semimajor axis — Half of Re — Slightly less than .5Re Eccentricity — Slightly negative — One — Slightly more than one Latitude — Slightly greater than 90 degrees — Slightly less than -90 degrees Altitude — Slightly negative — Slightly > project-specific max Earth Semimajor Axis — Slightly > project-specific max — Slightly < project-specific min Number of significant figures — Three — Eleven — 3.9 — 4.1 — 9.9 — 10.1 Output interval — Zero — Flight time — Slightly > project-specific max — Slightly < project-specific min |
Semimajor axis — Slightly less than .5Re Eccentricity — Slightly positive — Zero — Slightly less than one Latitude — Slightly less than 90 degrees — Slightly greater than -90 degrees Altitude — Slightly positive — Slightly < project-specific max Earth Semimajor Axis — Slightly < project-specific max — Slightly > project-specific min Number of significant figures — Four — Ten Output interval — Slightly < project-specific max — Slightly > project-specific min |
||||||||||||||||||
| TOP | |||||||||||||||||||
|
|
|
||||||||||||||||||
|
Semimajor axis Eccentricity Latitude Longitude Altitude # of signficant figures Output interval |
If there are seven factors, and each factor has N values which are considered to thoroughly cover the test cases, the total number of test cases is N7 There are even more when we add "extreme" test cases, such as barely legitimate and barely illegitimate test cases. We see that the number of test cases can rapidly grow to a number that can't be realistically tested in a reasonable time. For example, for seven factors, if N is five then the number of test cases exceeds 78,000. And this is a very simple program! |
||||||||||||||||||
| TOP | |||||||||||||||||||
|
|
|||||||||||||||||||
|
Conventional wisdom is that the effort (time, budget) required to build a software system is proportional to the number of Lines of Code (LOC). If one does not like using LOC, there are other related measures such as function points. It should be obvious that for extremely large programs, this will not be true, even if only due to the effort required to create, document, and run the required test cases. Since the number of test cases increases geometrically, the effort will also. According to Brooks, the total effort is proportional to the LOC (or function points, or whatever measure one is using) raised to the power of 1.5, rather than one. For very large software systems, this makes a considerable difference, as the following table demonstrates. This is one of the reasons that large, complex software systems cannot be developed using conventional approaches. |
|||||||||||||||||||
| TOP | |||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|
|
|||||||||||||||||
|
|
|
|
|||||||||||||||||
|
|
|
|
|||||||||||||||||
|
|
|
|
|||||||||||||||||
|
|
|
|
|||||||||||||||||
|
|
|
|
|||||||||||||||||
| Table 1. # Employee Years (E.Y.) Required To Develop A Software System. | |||||||||||||||||||
| TOP | |||||||||||||||||||
|
| |||||||||||||||||||
|
Brooks describes a number of rules of thumb relating to software development. Among these are: |
| ||||||||||||||||||
|
The best programmers are at least ten times as productive as the worst (page 30).
The optimum team size is approximately ten people (pages 29-35). Testing takes roughly three times the effort that coding does (page 121). About 50% of programmers' time is programming and debugging. The rest is meetings and paperwork (page 89). |
|||||||||||||||||||
| |
|||||||||||||||||||
|
This last bit of information has considerable significance. If one finds and fixes fifty bugs, there will be about ten (20% of fifty) new bugs introduced. If one then finds and fixes those, there will be about two new bugs introduced. If one finds and fixes those, there is a 40% chance that one more bug will be introduced. As a result, as software is deployed and maintained, and changes are made, eventually more bugs are introduced than can be found and fixed. At that point, the software has to be scrapped and totally rewritten. This is yet another reason to keep the number of bugs in a newly deployed piece of software small – if you have to go in, find, and fix, the bugs, this rule tells you you're well on your way (depending on how many bugs there are) to making that software obsolete. A more realistic example would be 300 bugs in a new installation. Then there will be sixty new bugs introduced once those are found; finding and fixing these will introduce twelve more. These will likely be major efforts, and still leave about a dozen bugs. Most likely these efforts will not occur, or at least the second will not. If the second does, along with a third, that will still leave at least two or three bugs. More than likely, the first effort will the only major bux-fixing effort, leaving sixty bugs. These eventually will likely lead to serious problems with the software. |
|||||||||||||||||||
| TOP | |||||||||||||||||||