Task I.4 Develop a proof of concept
I.4.1 Build a "concept model."
Intent: The intent of this task is to build a concept model or mock-up of the technology/business application that will enable the developer, the requester, and potential customers to assess the efficacy of a computer-based implementation.
Mechanics: A number of different options, discussed in Tasks I.4.1.1 through I.4.1.4, are available.
Application of Formal Methods: The use of formal methods will be kept to a minimum during this step. The idea is to create a "rapid prototype" that can serve to prove the concept. However, it may be necessary to use elements of formal analysis and/or design methods to establish a basis from which the concept model can be built.
Application of CASE Tools: t.b.d.
Tasks I.4.1.1 through I.4.1.4 that follow represent four options for building the concept model. See Process Design (Appendix I) for additional detail.
I.4.1.1 Create a paper model (e.g., a mathematical model) of the technology or business concept.
Intent: The intent of this task is to create a paper representation of the technology that will demonstrate that it can solve/analyze/ implement the technology. In general, this approach is used when the technology can be expressed mathematically using a notation that is amenable to the problem at hand.
Mechanics: The derivation of a paper model is ad hoc and will be driven by the nature of the technology. For example, if the stability of a control system is under investigation, the mathematics of control theory may be used to demonstrate the stability of system components, assuming that the characteristics of those components are known or can be predicted accurately.
Application of Formal Methods: prototyping
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have the concept models been reviewed internally for conformance to the concept?
2. Has the customer reviewed the concept model? Has feedback been activty solicited?
3. Does the concept model indicate that an actual implementation is feasible?
Do's & Don'ts
Do: Be sure that someone plays the role of the devil's advocate. The concept should be attached to determine whether it can withstand criticism.
Helpful Hints: t.b.d.
Deliverables: Paper model or simulation of the technology or business activity
I.4.1.2 Create a mock-up prototype of the technology or business concept.
Intent: The intent of this task is to create a mock-up prototype of the application. In general, this approach is used when the characteristics of a human-machine interface must be explored. Although the screen images may be dynamic, the mock-up prototype does not implement the algorithms that represent technology computation or control. The focus is on the behavior and "look and feel" of the human-machine interface.
Mechanics: The overall behavior and content of the interface is defined and a prototyping tool is used to create screen images.
Application of Formal Methods: human-computer-interface design techniques may be applied, if necessary.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the mock-up prototype been reviewed internally for conformance to the concept?
2. Has the customer reviewed the mock-up prototype? Has feedback been activty solicited?
3. Does the mock-up prototype indicate that an actual implementation is feasible?
Do's & Don'ts
Do: Consider implementing the prototype on a platform other than the one that will ultimately be used. This will force you to apply software engineering principles to the final implementation of the technology.
Don't: Attempt to implement the entire system. You focus here is on the interface&endash;its look and feel.
Helpful Hints
Be certain that everyone understands that the concept prototype is just that&endash;a mock-up prototype and that it will be 'thrown away' should the concept evolve into a new application or enhancement project.
Deliverables: Mock-up prototype
I.4.1.3 Create a simulation model of the technology.
Intent: The intent of this task is to create a executable simulation model of the technology in which all technology components are represented. In general, this task is applied when the performance and/or behavior of the software must be investigated for a variety of input and event conditions. This subtask is especially useful when real-time software are considered.
Mechanics: All system components are modeled using the notation and heuristics of the simulation tool that is used. In most situations, a behavioral model of the system is created, characteristics of each system component are defined, and interfaces are specified. The simulation model can be used to create a code skeleton from which the actual software can be derived.
Application of Formal Methods: simulation rules
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the simulation model been reviewed internally for conformance to the concept? Has it been reviewed for correctness?
2. Has the customer reviewed the simulation model? Has feedback been activty solicited?
3. Does the simulation model indicate that an actual implementation is feasible?
Do's & Don'ts
Do: Apply this subtask when there are questions about performance, behavior, or throughput that cannot be answered simply using other means.
Do: Recognize that all simulations make simplifying assumptions that may affect the meaning or accuracy of the concept model.
Helpful Hints
The key here is to build a simulation quickly and yet maintain a meaningful level of accuracy in the way it models the actual concept. Modern simulation tools are the proper approach to this problem.
Deliverables: Simulation model or prototype
I.4.1.4 Build an operational prototype.
Intent: The intent of this task is to create a fully or partially operational prototype of the technology. In general, this task is applied when the prototype is planned in a manner that will have it evolve into a production version of the software.
Mechanics: An operational prototype may be built using existing mock-up, interface models or simulation models developed as part of Tasks I.4.1.1 - I.4.1.3 as a starting point. If the application falls into the disciplined or rigorous category, it may be necessary to apply formal methods for analysis and design before the prototype is built.
Application of Formal Methods: Analysis, design and modeling methods, as required.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the operational prototype been reviewed internally for conformance to the concept? Has it been reviewed for correctness?
2. Has the customer reviewed the operational prototype? Has feedback been activty solicited?
3. Does the operational prototype indicate that an actual implementation is feasible?
Deliverables: Operational prototype
I.4.2 Conduct a formal technical review.
See Formal Technical Reviews umbrella activity.
I.4.3 Make revisions based on the formal technical review.
See Formal Technical Reviews umbrella activity.
I.4.4 Re-assess risks based on lessons learned from concept model.
Re-examine and update all deliverables produced as part of Tasks I.3.1 &emdash; I.3.7 using new information learned from the creation of the concept model.
Deliverables: Revised Risk Mitigation, Monitoring & Management Plan
I.4.5 Document the concept model.
Intent: The intent of this task is to document the concept model so that later modifications, extensions or corrections can be made without struggle.
Mechanics: Write an appropriate description of the concept model. In most cases, the model or prototype build during earlier steps will serve as one descriptive element, but restrictions, limitations, operating instructions, workarounds and other characteristics of the concept model must be committed to paper.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have both positive and negative findings based on the concept model and prototype been documented?
2. Does the concept documentation provide a basis for a go, nogo decision on the concept?
3. Has the documentation been reviewed internally and by the customer?
4. Does the concept document define areas where things are unclear?
Do's & Don'ts
Do: Keep a "concept modeling log" throughout Task I.4. When it's time to execute this Task, most of your work will already be done.
Don't: Rely solely on the prototype as a descriptive mechanism. Many characteristics may not be at all obvious by examining the prototype.
Don't: Delay documentation until later. Things will invariably fall into the cracks.
Deliverables: Concept Model Description
Use Browser "back" arrow or return to APM Process Design Language Description
