“Managing the Development of Large Software Systems” is a paper written by Dr. W. W. Royce who has deep experience in managing large-scale software development for spacecraft missions. Paper mainly investigates Dr. Royce’s experiences about leashing these critical big projects on time within budget and his ideas condenses to a well structured model which may be summarized below.
Royce has an opinion that, managing a software project mainly depeds on its documentation. He suggests harsh enforcement of documentation and keeping them allways up to date. According to Royce, documentation is the single most important way to make a project personel independent, controllable, observable, testable, sustainable, operatable and later (if desired) improvable, which can all be summarized simply as managable. Royce’s suggestion starts with Requirement Analysis phase. Here, working with customer, a Software Requirement Document should be prepared. Involving customer throughout all the project lifecycle is another suggestion of Royce. With the contunious feedback from customer, we may be sure of usability and accaptability. You may build a perfect mission to Moon but what will it do if the customer had indeed asked for Mars? Then comes Primary Program Design. The puspose of this preliminary design is to produce somewhat a miniature prototype (which will include its own analysis, design coding and testing). With this miniature (which will sure to have errors and imperfections) we will have initial knowledge on some operational constraint such as timing, storage and data flux. Moreover, these a priori estimations (which otherwise will be unknown till integration and testing) may keep our design in a correct path. Besides, this miniature (which is done to find operational constraints) also forces an initial implementation of all critical parts, which will be fully implemented later. In Analysis phase, we will have abstraction of desired software, and following, in Design phase, this abstraction will lead to interfaces and interactions. All these done, Coding becomes only a trivial technical activity, with maybe some optimizations. When we have well documented software, it will be both Testable and Operatable. These stages now can be done by professional testers and operators, since they can get all information that they need from project documentation. Besides, when time comes for future improvements, new team members will easely be at high grounds to start with.
As a result, Royce suggests somewhat control-freak, heavily documented and structured project management which uses prototyping (in order to make critical parts twice), continuous feedback from neighbouring stages and continuous review from customers. This is due to his experience in large scale, complex, critical space missions where a potential failure will be hard to compansate.