II.10.1 Review description of data, function and behavioral information.
This review is intended to familiarize those that did not participate in the creation of the analysis model. In general, it is an informal walkthrough of analysis model content.
II.10.2 Refine data, function and behavioral information, as required.
Intent: The intent of these tasks is to review and refine information gathered during the development of software scope, Tasks II.7.1 - II.7.3. The goal is to establish a basis from which a prototype can be developed or a complete analysis model can be derived.
Mechanics: The developer reviews the description of the software data domain, software functions and behavior. Ambiguity, inconsistency or omissions are investigated and corrected.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Deliverables: Refined Software Scope information, if required.
II.10.3 Create or extend a prototype of the software.
Intent: The intent of this task is to create a prototype for customer and/or developer evaluation. The prototype may be static or executable and is used to assist in further refinement of software requirements as well as a mechanism for proving implementation approach. If a prototype was created as part of Task I.4, it may be extended or modified at this time.
Mechanics: A number of different options, discussed in Tasks II.10.3.1 through II.10.3.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." 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 II.10.3.1 through II.10.3.4 that follow represent four options for building a prototype:
II.10.3.1 Create a paper model (e.g., a mathematical model) of the software.
Intent: The intent of this task is to create a paper representation of the software that will demonstrate that it can solve/analyze/ implement customer requirements. In general, this approach is used when the software internals 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: no software engineering methods
Application of CASE Tools: t.b.d.
Deliverables: Paper model of the software
II.10.3.2 Create a mock-up prototype of the software.
Intent: The intent of this task is to create a mock-up prototype of the software. 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 (I-CASE) 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. Have the limitations of the mock-up been adequately explained to the end user?
2. Does the prototype interface accurately reflect the interface to be developed for the actual application?
3. Has a behavioral model been created for the prototype?
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 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
See interface design references
Deliverables: Mock-up prototype
II.10.3.3 Create a simulation model of the software.
Intent: The intent of this task is to create a executable simulation model of the software 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 is considered.
Mechanics: All system components are modeled using the notation and heuristics of the CASE 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: Formal notation and heuristics are defined as part of the CASE tool is used.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Is the simulation based on known quantitative values that accurately describe the application environment?
2. Has the simulation model been reviewed for correctness?
3. Have known cases been run through the simulation and chacked against simulated results?
Do's & Don'ts
Do: Apply this subtask when there are questions about performance, behavior, or throughout that cannot be answer by simple other means.
Helpful Hints
Deliverables: Simulation model or prototype
II.10.3.4 Build an operational prototype.
Intent: The intent of this task is to create a fully or partially operational prototype of the application. 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 an 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 software falls into the structured or strict 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:
See SQA checklist questions for Tasks II.10.3.1 through II.10.3.3.
Deliverables: Operational prototype
II.10.3.5 Conduct continuing reviews of the prototype with the customer and development staff.
II.10.3.6 Make revisions to prototype based on the reviews.
See guidelines for formal technical reviews.
II.10.4 Engineer an analysis model for the software.
Intent: The intent of this task is to create an analysis model for the software. The analysis model defines all requirements and provides a standardized representation of data, function and behavior.
Mechanics: Use an analysis modeling notation such as structured analysis or object-oriented analysis along with heuristics that guide you in the application of the notation.
Application of Formal Methods: structured analysis, object-oriented analysis or another formal method
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has each model been reviewed for completeness, consistency and correctness?
2. Have errors been found and corrected in each model?
3. Have models that have undergone significant change been re-reviewed?
4. Have the analysts been trained in the analysis method that has been applied?
5. Has change control been applied as parts of the model have been baselined (large projects only)?
Do's & Don'ts
Do: Create a graphical representation of the analysis model. In most cases, it will be easier to present and review.
Do: Use CASE tools to assist you in the subtasks listed above.
Don't: Rush through this task. The work that you do here will serve as an important foundation for design.
Helpful Hints
1. It is usually best to develop the analysis model using a top-down, stepwise approach. That is, the model is derived iteratively, beginning with a top-level representation of data, function and/or behavior and then refining this information as required.
2. Be sure you and your colleagues who are working on the project get some training before embarking on Task II.10.4.
Deliverables:
II.10.5 Engineer a design model for the software.
Intent: The intent of this task is to create a design model for the software. The design model represents data, function and behavior in the context of data, architectural, procedural and interface designs.
Mechanics: Use an design modeling and transformation approach such as structured design or object-oriented design along with heuristics that guide you in the application of the approach.
Application of Formal Methods: structured design, object-oriented design or another formal method
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has each model been reviewed for completeness, consistency and correctness?
2. Have errors been found and corrected in each model?
3. Have models that have undergone significant change been re-reviewed?
4. Have the designers been trained in the analysis method that has been applied?
5. Have design principles been followed throughout the model?
6. Has change control been applied as parts of the model have been baselined (large projects only)?
Do's & Don'ts
Do: Create a graphical representation of the design model. In most cases, it will be easier to present and review.
Do: Use CASE tools to assist you in the subtasks listed above.
Don't: Rush through this task. This is the place where quality is built!
Helpful Hints
1. It is usually best to develop the design model using a top-down, stepwise approach. That is, the model is derived iteratively, beginning with a top-level representation of data, function and/or behavior and then refining this information as required.
2. Be sure you and your colleagues who are working on the project get some training before embarking on Task II.10.5.
Deliverables:
II.10.6 Create preliminary test plan and procedure for the software.
Intent: The intent of this task is to create a preliminary test plan and procedure using information obtained from the data, architectural, procedural and interface design models.
Mechanics: Each of the design models provides information that is useful in deriving a test plan. The data and architectural design will assist in the derivation of black box tests for integration and validation testing. The procedural design and interface design will assist in the derivation of white box and black box tests for unit and integration testing.
Application of Formal Methods: test case design methods, see Testing references
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Treat test case design with as much care as you treat the design of the software itself.
Do: Recognize that most software tests can be developed before any source code exists - as long as the design model is complete.
Helpful Hints: See Testing references
Deliverables:
Use Browser "back" arrow or return to APM Process Design Language Description
