Overview
The software developer often is called upon to perform software prototyping to support systems engineering (or later software engineering efforts). Software prototyping reduces risk through exploring ill-defined or unknown requirements and determining the feasibility of proposed requirements or design considerations. Prototyping can help determine which one of multiple subsystems is better equipped to handle a task, given imposed design constraints. Consequently, this reduces the risk of overloading one of the subsystems. The scope and nature of the prototype(s) to be produced vary widely, as does the formality of the development process. This activity describes the factors prompting questions and issues to be resolved about the nature of prototyping, and guidance for its use. It also establishes guidelines for prototyping versus formal product development.
Roles and Responsibilities
The software developer develops the software prototypes and records the results.
The systems engineering group defines the need for prototyping and evaluating the results.
Controls
The Prototype Proposal Form (see Appendix C).
Inputs
Subsystem definitions and allocated system requirements developed (see activity 3.1.2.1 Identify Subsystems) and documented in the System Components section of the MIL-STD-498 System/Subsystem Design Description (SSDD) (see Appendix E) or other equivalent system documentation.
Any subsystem interface descriptions (see activity 3.1.2.2 Define Interfaces Among Subsystems) developed and documented in the Internal Interfaces section of the SSDD.
Any subsystem operational scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios) developed and documented in the System/Segment Behavioral Design section of the SSDD that may be implemented or simulated in the prototype.
Procedures
1) Before prototyping commences, the systems engineering group (or individual members) establishes and clearly states the prototyping goals. The broad goal is to reduce cost, schedule, or technical risk. More specifically, prototyping often meets one or more of the following goals:
Obtain information on the "look and feel" of user interfaces, including what information needs to be displayed and how. This may be iteratively done by providing potential users with a prototype, receiving their feedback, and updating the prototype until the users indicate they are satisfied with the proposed interfaces.
Example:
Define Graphical User Interface (GUI): Produce a preliminary GUI for evaluation by potential users to further define user interface requirements.
Determine the users’ preferred colors and required level of precision for the contour maps.
Test or demonstrate control of a hardware component, and define its interface requirements.
Example:
Verify the documented interface requirements for an Interactive Stepper Motor Controller.
Determine the impact of using a faster clock and/or inserting a wait state on the timing design.
Test or demonstrate interaction with an external software package(s) or component(s), and define its interface requirements.
Example:
Verify the documented interfaces and capabilities of the Intel 8250 Universal Asynchronous Receiver/Transmitter (UART) reusable software component.
Determine the data formatting required to import the signal data into the proposed commercial pattern matching software package.
Establish algorithm, system (or software) design, or throughput viability.
Example:
Data compression: Determine if an interface can transfer the required amount of data given the candidate data compression scheme.
Timing Issues: How much data can be sent during X amount of time before the receiving system is going to read the data?
2) Establish constraints and plan the prototyping. After the goals are established, the major prototyping constraints are determined. The constraints include the language, hardware and software environment to be used, and the products to be developed. Normally, the functions implemented will be only a small subset of the total required system functions. Special tools, such as code generators, may be used to speed up the prototyping. Coding and documentation standards may be relaxed during this effort if it is clear that the prototype products will not be used in the final product. End products of prototyping may be algorithmic analyses, feasibility studies of alternative system designs, interface requirements definition, and concepts of user operation. The software can be a product itself, and reused in the final software product.
Example:
Software interface drivers developed during prototyping to better understand how to control a hardware interface may be reused in the final software. However, the primary reason for producing software during prototyping is to obtain additional information about the end products.
If a prototype is expected to result in software that will be in the final product, it should be developed with all usual requirements analysis, design, coding, test documentation, standards, management planning, and configuration and quality control measures enforced. The need for these measures must be communicated to all group members because the lack of this documentation and control may result in higher costs during system integration and maintenance, and an increased number of defects in the product.
Prototyping should be a limited effort, usually no longer than one staff-month. It should be incorporated and tracked as any other element in the schedule as defined in the MIL-STD-498 Software Development Plan (SDP) (see Appendix E) (see activity 1.1.1 Plan Software Development).
Once the prototype goal, development environment, products to be produced, labor estimate, and expected completion date are documented on a Prototype Proposal Form, the form is submitted to the project software manager (if the prototyping is for software development) or the project manager (if the prototyping is for an overall system effort) for approval.
3) Based upon the defined prototyping goals and constraints, the software developer performs the actual prototyping. During this effort, the software developer may reference any system or subsystem definitions and interface descriptions, operational scenarios, code or documentation from past projects, or technical documentation on system products (e.g., MIL-STD-1553B , Intel processor documentation).
4) The software developer documents the results on the Prototype Proposal Form and reports to the systems engineering group. The systems engineering group decides if the prototyping results met the goals, or if further iterations or a different approach is needed. The prototyping is often accomplished in increments. This is especially true for efforts whose goal is to eliminate usage requirements by obtaining periodic user feedback on prototyping results. The content of successive increments may be determined from the previous feedback. If the goals are met, the results (e.g., a successful interface with a new hardware component) can be used in developing and refining system products (e.g., interface requirements definition for the new hardware component).
Outputs
Prototyping results ("result" may indicate a usable software system, numerical quantity, interface definition, algorithm, or what is desired based upon the goals) documented on the Prototyping Proposal Form and placed in the systems engineering notebook.