Below I have listed the results submitted for the SE History tutorial by the various groups. Some groups did not contribute. It turns out that most groups were unable to find out what the software engineering method on the project was. Some suggested SE Methods for producing software include (according to the submissions):
· A large central computer or network
· Writing software using drums of paper tape
· Pushing employees hard
· Having a Standard channel interface
Since these are not really methods, but properties, I have added a separate table of my own below that contains some additional examples.
|
Team |
Project |
Type |
Decade |
Hardware |
Language |
SE Process |
|
Operating System |
70s |
FORTRAN-77, COBOL, BLISS-32, Pascal, Lisp, … |
Not found |
|||
|
Operating System |
60s |
GE-635 Mainframe |
||||
|
Operating System |
60s |
MACRO-6 Assembly and BLISS |
Not found |
|||
|
Application |
50s |
IBM 7090 mainframe |
||||
|
Database |
70s |
Assembly |
Not found |
|||
|
Operating System |
60s |
Assembly, Plus, GOM |
Not found |
|||
|
Application |
60s |
Assembly, AGC interpreter |
||||
|
Application |
90s |
|||||
|
3D?? |
Not defined |
Operating System |
60s |
Not found |
||
|
Application |
50s |
AN/FSQ-7 mainframe |
Assembly |
|||
|
Operating System |
70s |
Assembly |
Some additional Recent Projects
|
Project |
Type |
Decade |
Hardware |
Language |
SE Process |
Additional |
|
Lisa OS |
Operating System |
80s |
C++ |
|||
|
Operating System |
80s |
|
Just for fun: User Manual for the IBM 1401. Especially page 15!
1B: (Mini-)VAX
Reason for the Project
The VAX-11 series was the first 32-Bit architecture ever and represents a milestone in computer history. The old PDP-11 system of Digital Equipment Corporation was getting old and cheaper and it was time for something innovative to keep or improve DECs position on the market. It introduced a 32 Bit instruction set (wide word) and virtual memory support (paging), principles also used today.
Objective of the Project
The VAX-11 system was developed from scratch. Concurrently with the hardware (CISC processor, highly orthogonal instruction set) also the operating system, later on called OpenVMS (though it was/is not open source) was developed. This lead to a highly meshed architecture, where hardware and software work together very well. The VAX-11 (miniVax) instruction set was designed to be powerful and orthogonal. When introduced, many programs were written in assembler language, so having a “user-friendly” instruction set was important. In time, as more programs were written in higher-level language, the instruction set became less visible, and the only ones much concerned about it were compiler writers. When it came to market in the late 1977s, VAX machines were the most powerful machines on the market (1 MIPS) and were therefore used as a baseline for CPU Benchmarking. This did not help the architecture to become more popular.
Programming Language Used
FORTRAN-77, COBOL, BLISS-32, Pascal, Lisp, …
Hardware Used
UNIBUS or MASSBUS disks and, tapes typically, l-2tape drives and 2- 6 disks configured RP05, RK07, and TE16 most common
Method Used
· Concurrent building of both software and hardware.
· Provide a set of homogeneous distributed computing system products so a user can interface, store information and compute, without re-programming or extra work in many styles and the following computer system sizes:
· As a single user computer within a terminal
· At a small, local shared computer system
· Via a large central computer or network.
1E: Multics
Reason for the Project
In the beginning Multics is developed as a research project. However Multics become commercial product for General Electric and HoneyWell even though not very successful one. commercial product. Originally it was a cooperative project led by MIT (with Fernando Corbató) along with General Electric and Bell Labs. Bell Labs dropped out in 1969, and in 1970 GE’s computer business including Multics was taken over by Honeywell.
Objective of the Project
Multics (Multiplexed Information and Computing Service) was a mainframe timesharing operating system that began at MIT as a research project in 1965.
One of the overall design goals is to create a computing system which is capable of meeting almost all of the present and near-future requirements of a large computer utility. Such systems must run continuously and reliably 7 days a week, 24 hours a day in a way similar to telephone or power systems, and must be capable of meeting wide service demands: from multiple man-machine interaction to the sequential processing of absentee-user jobs; from the use of the system with dedicated languages and subsystems to the programming of the system itself; and from centralized bulk card, tape, and printer facilities to remotely located terminals. Such information processing and communication systems are believed to be essential for the future growth of computer use in business, in industry, in government and in scientific laboratories as well as stimulating applications which would be otherwise undone.
Multics should provide
· Convenient remote terminal use.
· Continuous operation analogous to power & telephone services.
· A wide range of system configurations, changeable without system or user program reorganization.
· A high reliability internal file system.
· Support for selective information sharing.
· Hierarchical structures of information for system administration and decentralization of user activities.
· Support for a wide range of applications.
· Support for multiple programming environments & human interfaces.
· The ability to evolve the system with changes in technology and in user aspirations.
Programming Language Used
· PL/1
· Assembly language
PL/I (“Programming Language One”, pronounced “pee-el-one”) is a procedural, imperative computer programming language designed for scientific, engineering, business and systems programming applications. It has been used by various academic, commercial and industrial users since it was introduced in the 1960s, and is actively used as of 2010.
Assembly language is a low-level programming language for computers, microprocessors, microcontrollers, and other programmable devices. It implements a symbolic representation of the machine codes and other constants needed to program a given CPU architecture. This representation is usually defined by the hardware manufacturer, and is based on mnemonics that symbolize processing steps (instructions), processor registers, memory locations, and other language features. An assembly language is thus specific to a certain physical (or virtual) computer architecture. This is in contrast to most high-level programming languages, which, ideally, are portable.
Hardware Used
A GE-635 (by General Electric) was delivered to Project MAC in August 1965 for use running the 645 simulator. The 645 was delivered to Project MAC in January 1967, and Multics was self hosting, able to compile itself on, by the end of 1968.
Method Used
Design Process
· Technical memorandum to describe the problem to be solved and seeking consensus at the level of problem definition from other members of the programming staff. After defining satisfactory problem, designer writes technical memorandum describing his proposed solution and again seek for consensus.
· Formal Multics Change Request (MCR) is written to summarize the change to Multics, the reason for that change and its implication. If it affect system documentation, draft of changes is also supplied with MCR. MCR is submitted to MCR board which includes most experienced and knowledgeable people on staff. The decision to approve MCR determined by voting of MCR board.
Implementation
For most projects, the designer is also the programmer, debugger, and documenter. This practice eliminates a troublesome layer of communication and responsibility determination. This approach is feasible due to the ease of the actual programming and debugging task in the Multics environment. High programmer productivity has been established as a Multics tradition; this has come about partly by selecting talented and dedicated people, and partly by providing them with powerful tools, including PL/I.
Program Auditing
When a Multics system programmer has completed a change, he submits his modules to a knowledgeable colleague for review. Thus, not only is the design reviewed by the design discussion process and the MCR Board, but the actual implementation is also subjected to expert scrutiny.
The auditor is responsible for pointing out problems with general structure, documentation, conformance to system standards, and correct operation. The MCR Board sometimes attaches special comments to an MCR to remind the programmer and auditor of important things to check. The auditor can, and often does, suggest changes in the structure of a program, the names of variables, and the comments, as well as in items that actually affect the execution of the program. Several rounds of auditing may be necessary before programmer and auditor agree that the program is ready to install.
2A: Hardware: PDP – 6 / Software: PDP-6 Monitor
http://ed-thelen.org/comp-hist/pdp-6.html
Reason for the Project
The PDP-6 originally was designed to extend the performance of Digital's 18-bit processor series, but several facto influenced the course of the new design. It ended up being the PDP-10 production prototype as its main reason it was started.
Objective of the Project
Designed for timesharing and real-time lab use, with straightforward interfacing capability.
Programming Language Used
An early version of the TOPS-10 OS, Called Monitor was used on the PDP-6. The Monitor OS was written in a combination of MACRO-6 Assembly and BLISS(A systems programming language. Widely used until it was overshadowed by C).
Hardware Used
The OS was primarily written and programmed into the PDP-6 using drums of paper tape. The Monitor OS used on the PDP-6 was further developed on the machine to produce the TOPS-10 OS used in the PDP-10.
Method Used
The OS was primarily written and programmed into the PDP-6 using drums of paper tape.
2D: Sabre
Reason for the Project
Sabre was originally designed for American Airlines to aid in the organisation of seat reservations, and aircraft management.
Objective of the Project
The project was designed to deliver fast, cheap airline reservation with data consistency, information collection and management. It was to allow airlines to grow without the issues arising from an ever-expanding customer base.
Programming Language Used
FORTRAN
Hardware Used
The software was developed on two IBM 7090 mainframes in Briarcliff Manor, NYC. In 1972, the system was migrated to the IBM System/360.
Method Used
Waterfall Method, designed for the SAGE program, which led to the development of SABRE.
2F: Oracle 1 (1977):
Reason for the Project
The founders of Oracle, Lawrence J. Ellison and Robert N. Miner, wanted to start a software firm together. They had worked together before and both had a lot of experience in building custom database systems. Ellison used to read technical documents published by IBM and noticed the interest in relational databases. He suspected that the new technology would soon be incorporated into IBM computers, so they developed the Oracle Relational Database Management System to manage them.
Objective of the Project
There were 3 initial objectives of Oracle’s project.
1. The initial objective of Oracle was to reproduce a commercial version of a relational database system that they had created for the CIA. In fact, they named the company after the codename the CIA gave the project. Oracle wanted this commercial RDBMS to work in an ad hoc network.
2. The second objective was to make a portable software that would work with IBM’s structured query language (SQL).
3. Finally, Oracle wanted to market to minicomputers as opposed to mainframes. This was because they wanted a more youthful following and IBM was focused on mainframes, so Oracle wouldn’t have much competition in the minicomputer field.
Programming Language Used
Assembly
Hardware Used
PDP-11 microcomputer
· 128k memory
· 16 bit operating system
· had the ability to take advantage of C programming language (even though oracle 1 was in assembly)
· closed architecture (cant switch out components) meant it had a limited lifespan even though the firmware was reguarly updated to utilise newer technologies
Method Used
It’s unclear, but in the 70’s and 80’s Ellison had a reputation for pushing his employees hard and the oracle company had a reputation for delivering unreliable software. Ellison was aggressively focused on sales and nothing else, making wild claims about the software and selling it at huge discounts. Thus the focus was definitely not working software nor was it anything to do with customer satisfaction. The culture was probably far from agile.
3A: IBM S/360 -Michigan Terminal System (MTS)
Reason for the Project
MTS was a time-sharing system built to replace the original time-sharing system for the IBM S/360. The original system was overly ambitious and did not work properly which stressed the need for a new and working project. MTS was a solution to overcome the conflicting views of time-sharing while supporting the expanded memory capacity of the IBM S/360.
Objective of the Project
Along with Multics at MIT, MTS were the first operational virtual memory operating systems in the world. MTS was built as a pioneering system that was in several ways a direct ancestor of the Internet, offering early forms of email, file-sharing and conferencing. It consisted of an executive system together with various programming languages and utilities. For many years, it and it’s clones at University of Alberta in Canada and INRIA in Grenoble, France, served the faculties, staff and students of eight universities in US, Canada and UK that comprised the MTS Consortium.
Programming Language Used
Various programming languages were used, but 360/370 Assembler was the main focus. A few job programs and portions including some Command Language Subsystems(CLSs) and Device Support Rountines(DSRs) were written in higher level languages like Plus and GOM. User programs are written in a wide range of languages from assembler to any of the higher level languages that are available.
Hardware Used
· IBM: S/360-67, S/370-148, S/370-168, 3033U, 4341, 4361, 4381, 3081D, 3081GX, 3083B, 3090-200, 3090-400, 3090-600, and ES/9000-720
· Amdahl: 470V/6, 470V/7, 470V/8, 5860, 5870, 5990
· Hitachi: NAS 9060
· Various S/370 emulators
Method Used
· Integrated design of hardware and software
· I/O system offers new degrees of concurrent operation, and the data rates approaches 5,000,000 characters/sec,
· Truly general purpose machine organization which offers supervisory facilities, powerful logical processing operations, and a wide variety of data formats
· Standard channel interface between central processing unit and input/output devices.
· The storage approaches permits and exploits very large capacities, hierarchies of speeds, read only storage for microprogram control, flexible storage protection.
3B: Apollo Mission Computer System
Reason for the Project
The Apollo lunar landing program presented a tremendous managerial and technical challenge to NASA. Navigating from the earth to the moon and the need for a certain amount of spacecraft autonomy dictated the use of a computer to assist in solving the navigation, guidance, and flight control problems inherent in such missions. Before President John F. Kennedy publicly committed the United States to a “national goal” of landing a man on the moon, it was necessary to determine the feasibility of guiding a spacecraft to a landing from a quarter of a million miles away. The availability of a capable computer was a key factor in making that determination.
The presence of a computer in the Apollo spacecraft was justified for several reasons. Three were given early in the program: (a) to avoid hostile jamming, (b) to prepare for later long-duration (planetary) manned missions, and (c) to prevent saturation of ground stations in the event of multiple missions in space simultaneously. Yet none of these became a primary justification. Rather, it was the reality of physics expressed in the 1.5-second time delay in a signal path from the earth to the moon and back that provided the motivation for a computer in the lunar landing vehicle.
Objective of the Project
With the dangerous landing conditions that were expected, which would require quick decision making and feedback, NASA wanted less reliance on ground-based computing. The choice, later in the program, of the lunar orbit rendezvous method over direct flight to the moon, further justified an on-board computer since the lunar orbit insertion would take place on the far side of the moon, out of contact with the earth. These considerations and the consensus among MIT people that autonomy was desirable ensured the place of a computer in the Apollo vehicle.
Programming Language Used
The computer language used was HAL/S (Higher-order assembly Language/Shuttle) which is an improved version of MAC.
Hardware Used
A fairly compact computer for its time, Apollo Guidance Computer(AGC) was written in AGC assembly language and stored on rope memory. It provided onboard control of the Command Module(CM) and the Lunar Module(LM) spacecraft of the Apollo program. There was a simple real time operating system consisting of the Exec; a batch job-scheduling system.
The programs were written in the first higher order computer language called MAC and then compiled by hand, which they typed onto punchcards.The MIT’s instrumentation laboratory(IL) had a number of mainframes, including Honeywell 1800 and the IBM 360 model 175 mainframe computer(used for debugging purposes), which ran simulations of the Apollo computers.
A user interface for AGC, abbreviated DSKY was developed for the Apollo program. Using the Apollo computer system, it took about 10,500 keystrokes to complete a lunar mission. Communication between the crew and the computer was possible via flashing the PROGram, VERB and NOUN displays. The displays included 10 warning lights, a computer activity light, a PROGram display, VERB and NOUN displays, three five-digit numeric displays with signs, 19 keys including VERB, NOUN, CLEAR, KEY RELEASE, PROCEED, RESET, ENTER, PLUS, MINUS and digits 0-9 as shown in figure below.
Apollo’s computer had permanent and erasable memory. It was the first to use ICs. The block I version used 41000 ICs, each containing a single 3-input NOR gate, whereas the later Block II version used 2800 ICs, each containing a two 3-input NOR gates. A 2.048 Mhz crystal clock was used for timing reference. The AGC consisted of four 16-bit registers called central registers, for general computational use. It also consisted of additional registers which were used internally.
Method Used
The Apollo computer used few flip-flop registers due to size and weight considerations.
To further reduce size and weight, the Apollo computer was designed with a single adder circuit, which the computer used to update incremental inputs, advance the next address register, modify specified addresses, and do all the arithmetic.
The memory size was increased with the increase in development of mission requirements. NASA and its computer contractors have been consistently unable to make adequate judgments in this area. Apollo’s computer had both permanent and erasable memory, which grew rapidly over initial projections. Software was not considered a driving factor in the hardware design, and the hardware requirements were insufficient. The use of core rope constrained NASA’s software developers.
Software to be stored on core rope had to be perfect and delivered months before a scheduled mission for the rope to be properly manufactured and tested.
In the Apollo program, as well as other space programs with multiple missions, system software and some subordinate computer programs are only written once, with some modifications to help integrate new software. The cycle of requirements, design, coding, testing and maintenance was followed even during the early 1960s. The important difference from present practice was the report’s recommendation that modules of code be limited to 200 to 300 lines, about five times larger than current suggestions.
For Apollo, MIT developed a higher order language that translated programs into a series of subroutine linkages, which were interpreted at execution time. This task although slower than a comparable assembly language program, the language required less memory for the same task.
The lessons learned include
· Documentation is essential.
· Verification must proceed through several levels.
· Requirements must be correct and defined clearly.
Bibliography
· http://www.netjeff.com/humor/item.cgi?file=ApolloComputer
· http://en.wikipedia.org/wiki/Apollo_Guidance_Computer
· http://en.wikipedia.org/wiki/Apollo_PGNCS
· http://history.nasa.gov/computers/Part1.html
· http://books.google.com.au/books?id=gXYItzQARVoC
3D: HTTP protocol and the first web browser
Reason for the Project
It was a proposal by Tim Berners-Lee to use "HyperText...to link and access information of various kinds as a web of nodes in which the user can browse at will."
Objective of the Project
"The World-Wide Web was developed to be a pool of human knowledge, and human culture, which would allow collaborators in remote sites to share their ideas and all aspects of a common project."
Programming Language Used
The WorldWideWeb browser (later Nexus) was written in Objective C, but later on many componenets were rewritten in C.
Hardware Used
The original web browser, WorldWideWeb (later Nexus) was writtne on a NeXT computer which had a greyscale screen.
Method Used
The first web browser was originally written by Tim Berners-Lee himself while working at CERN. As time went on more people helped with the project. The browser was built iteratively with new versions being made to deal with revisions to the HTTP protocol.
3D: IBM1410
Reason for the Project
IBM1410 needed an operating system
Objective of the Project
To provide a compatible operating system for the new IBM1410
Programming Language Used
COBOL
Hardware Used
IBM1410
Method Used
Waterfall method
3F: SAGE (Semi Automatic Ground Environment)
http://en.wikipedia.org/wiki/Semi_Automatic_Ground_Environment
Reason for the Project
After WWII, with the on-set of jet-powered aircraft, using manual ground-controlled interception methods to counteract fighter and, in particular, bomber planes was too slow. By the time a plane had been spotted on a radar, had its path computed and a fighter plane had been ordered to intercept it, the attacking plane would have already reached its target destination.
Objective of the Project
Dr. George E. Valley decided that, to ensure the U.S.A. had some sort of protection a radar system would have to span the coasts of the USA, as well as Canada. However, if such a system were to be implemented, the sheer number of reports that would flood in the event of a raid would be overwhelming. Valley decided that the entire system could be automated by connecting all of the radar sites to a computer, which would control all of the necessary input and output. This simplified the operator’s job dramatically, as they only had to choose which targets to attack, and what assets to use.
Programming Language Used
· 500,000 lines of assembly language (wiki, does not specify which assembly language)
Hardware Used
· AN/FSQ-7 - possibly the largest computer ever built, and likely to remain so in the future
· CRTs
· Light guns
· Love the complimentary feature: built-in cigarette lighter and ashtray
Method Used
Likely waterfall or V-model (could not find conclusive information), could also be some special methodology used by the military. Different entities participated in the project so it’s almost certain, especially considering the era in which this project was done, that they used a process which clearly distinguished phases and allowed them to pass work from one entity to another.
3G UNIX
Reason for the Project
“Bell Labs, frustrated by the size and complexity of Multics but not the aims, slowly pulled out of the project. Their last researchers to leave Multics, Ken Thompson, Dennis Ritchie, M. D. McIlroy, and J. F. Ossanna,[4] decided to redo the work on a much smaller scale.”
http://en.wikipedia.org/wiki/Unix
“Thompson, once it was obvious that Multics was going away, decided to satisfy two urges: to write an operating system of his own, and to create an environment in which to do future work.”
http://www.bell-labs.com/history/unix/acronyms.html
Objective of the Project
Dennis Ritchie says "What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication." http://en.wikipedia.org/wiki/Unix
Programming Language Used
Initially written in PDP assembly code. But by 1973 most was rewritten in C.
Hardware Used
Minucs was developed on an expensive GE645 series mainframe. (http://en.wikipedia.org/wiki/GE-600_series)
During the same year bell labs pulled out of the multics project, Ken Thompson had developed a game - ‘Space Travel'. This was developed to run on a multics system. As cpu time on the GE mainframe was expensive, a PDP-7 (http://en.wikipedia.org/wiki/PDP-7) was obtained. The porting of Space Travel to the PDP7 provided valuable experience in working with the PDP-7’s instruction set and limitations.
Unix was programmed on a GE600 series mainframe running GECOS, in PDP assembly. This was assembled and written to paper tapes, which ran on a PDP-7, however, as soon as an assembler was completed, the system could support itself.In 1970 a PDP-11 machine was purchased by bell labs, for the development of a text editing system. Development continued on the PDP-11. Unix was later ported to c and was therefore became cross-platform.
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
Method Used
Look at: bell labs' history of unix:
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
Linux timeline: http://www.levenez.com/unix/
The design for unix seemed to be incremental. Individual components were developed, some before the initial planning phase for the operating system, though most after a requirements document was created. As components were added, some components had to be redesigned to fit with the existing system.
"Thompson saw that file arguments weren't going to fit with this scheme of things and he went in and changed all those programs in the same night. I don't know how...and the next morning we had this orgy of one-liners."
http://www.bell-labs.com/history/unix/sohedid.html
“Thompson, R. H. Canaday, and Ritchie developed, on blackboards and scribbled notes, the basic design of a file system that was later to become the heart of Unix. Most of the design was Thompson's, as was the impulse to think about file systems at all, but I believe I contributed the idea of device files. Thompson's itch for creation of an operating system took several forms during this period; he also wrote (on Multics) a fairly detailed simulation of the performance of the proposed file system design and of paging behavior of programs.”
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
“He first worked out the requirements for an operating system, in particular the notion of processes. Then he developed a small set of user-level utilities: the means to copy, print, delete and edit files. And he developed a command interpreter, or shell.”