Home

  About Us

  Products

  Process Models

  SE Resources

  Commentary

  Contact us

Breaking News!

A new blog ...

visit OnCenter, Roger Pressman's running commentary on the world at large

A new edition ... the 7th edition of Software Engineering is available now

A new book ... Roger Pressman and David Lowe on Web Engineering

A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge

A new curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.

A redesigned site! ... we've done a major redesign and added many new features for 2009 - 2010

 
Adaptable Process Model
Task V.33 Forward Engineer the Application



IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc. for complete licensing information.

Task V.33 Forward engineer the application

 

V.33.1 Refine analysis model to reflect enhancement to be implemented as part of forward engineering.

Intent: The intent of these tasks is to review and refine the existing analysis model and/or requirements specification to reflect changes to be accomplished as part of reengineering. The goal is to establish a basis from which a prototype can be developed or a revised analysis model can be derived.

Mechanics: The developer reviews the changes proposed for 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 Analysis Model

 

V.33.2 Build prototypes, if required.

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.

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.

Deliverables: Prototype reflected the application enhancement

 

V.33.3 Reengineer an analysis model with enhancements.

Intent: The intent of this task is to create a revised analysis model for the software to be reengineered. 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. If an analysis model is available for the existing application, determine to what extent it can be adapted for the reengineered application.

Application of Formal Methods: structured analysis, object-oriented analysis or another formal method

Application of CASE Tools: t.b.d.

SQA Checklist:

    1. Has the original requirements model been reviewed to ensure that it conforms to requirements established for the reengineered application?

    2. Have all changes associated with reengineering corrections, enhancements or adaptations been integrated into the model?

    3. Has each model been reviewed for completeness, consistency and correctness?

    4. Have errors been found and corrected in each model?

    5. Have models/classes that have undergone significant change been given additional attention during review?

    6. Have the analysts been trained in the analysis method that has been applied?

    7. Has change control been applied as parts of the model have been baselined (large projects only)?

Do's & Don'ts

    Do: Modify the 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: Enhance an analysis model that doesn't conform to the current operational application. The model must be brought into compliance before enhancement activities can begin.

    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 this task Task. 

Deliverables:

1. Reengineered Analysis model

2. Modified Software Requirements Specification (if required)

 

V.33.4 Design reengineered system

Intent: The intent of this task is to create a new design model for the software to accommodate the reengineered analysis model. The design model represents data, function and behavior in the context of data, architectural, procedural and interface designs.

Mechanics: Use a 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 the original design model been reviewed to ensure that it conforms to reengineered requirements?

    2. Have all changes associated with any enhancements been integrated into the model?

    3. Has each model been reviewed for completeness, consistency and correctness?

    4. Have errors been found and corrected in each model?

    5. Have models/classes that have undergone significant change been given additional attention during review?

    6. Have the designers been trained in the analysis method that has been applied?

    7. 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 V.33.4.

Deliverables:

1. Design model

2. Software Architecture Specification

3. Software Detailed Design Specification


Use Browser "back" arrow or return to APM Process Design Language Description


Site search! We've added links to a search engine that will enable you to search our entire site for information you need. Enter the appropriate word or phrase below.

PicoSearch




Home About us Products Product Models SE Resources Commentary Contact us

Web site and all contents © R.S. Pressman & Associates, Inc. 2001 - 2010, All rights reserved.
Free website templates