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 6th edition of Software Engineering is available now

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

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

A redesigned Web site ... we've done a major redesign and added many new features

 
Adaptable Process Model
Checklists:
Reviewing the Analysis Model



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.

Reviewing the Analysis Model

    The analysis model serves as the foundation for all subsequent software engineering activities. For this checklist, the more questions that elicit a negative response, the higher the risk that the analysis model will not adequately serve its purpose.

    • Have requirements elicitation activities been performed? Are the results written down?
    • Have all output/input objects defined as part of requirements elicitation been refined (decomposed)?
    • Have attributes of output/input objects been identified?
    • Have data objects and their relationships (a data model) been described?

    For conventional software engineering:

    • Have all functions been decomposed?
    • Has a grammatical parse been used to begin the modeling process?
    • Has an entity relationship diagram been developed for all data objects?
    • Has a data flow model been developed?
    • Is each level of the DFD represented at a consistent level of abstraction?
    • Is information flow continuity maintained through various levels of the DFD?
    • Are all data flow items (objects) and transforms labeled and understood?
    • Have extensions for real-time systems been applied, when required?
    • Is the lowest level of the DFD represented in sufficient detail?
    • Has a control flow diagram (or its equivalent) been developed?
    • Have process specifications been developed for each low level transform?
    • Has a list of "events" that affect software behavior been developed?
    • Has a state transition diagram been developed?
    • Does the STD accurately represent system behavior?
    • Is there a way to exit every state?
    • Have usage scenarios (use cases) been applied to the STDs?
    • Have the models been represented in a way that avoids implementation details?
    • Has a CASE tool been used to support the analysis models?
    • Is a data dictionary available?

    For object-oriented software engineering:

    • Has domain analysis been conducted as a precursor or in parallel with to OOA?
    • Is the domain to be analyzed clearly identified?
    • Have domain objects been identified and defined in detail?
    • Are use cases available for OOA work?
    • Have potential classes been identified for the problem to be solved?
    • Have potential classes been evaluated using selection characteristics?
    • Have chosen classes been categorized by type?
    • Have "responsibilities" (operations, attributes) for each class been identified?
    • Is each responsibility stated as generally as possible?
    • Is system intelligence evenly distributed across classes?
    • Have collaborations (relationships) between/among classes been defined?
    • Has a CRC model (SEPA, 5/e, p. 582) been created?
    • Are CRC index cards (or their equivalent) available for review?
    • Have appropriate class hierarchies been identified?
    • Have appropriate subjects and subsystems been defined?
    • Has an object-relationship model been defined?
    • Has an object-behavior model been defined?
    • Have all elements of the OOA model been reviewed?
    • Have use cases been applied to validate the CRC model and other object models?
    • Has a prototype been developed for any function that is ambiguous or unclear?
    • Has a written Software Requirements Specification been developed?
    • Has the specification undergone formal technical review(s)?


      Return to Checklist Table of Contents


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 - 2006, All rights reserved.
Free website templates