This assignment is a task leading to additional useful data that can be applied to the final report and presentation, AND is a useful contribution to the expansion of CSE's MBASE knowledge base. It is to look back to CS577a and CS577b and do the identification based data gathering based on the course, your project and all guidelines and presentations. In addition, it is to apply the data gathering to what is going on at your summer employer. Please note that there may be various sets of responses based on the project you are working on, what the company "normally" does, and what may be going on in other projects that you hear about.

Below are detailed instructions on what is desired and how to present the results.

1.    What to Gather

        For every software development or software engineering artifact or artifact type (for those that you see multiples of), please
        identify

    1.1    The name of the Artifact or sub-part of an Artifact (where multiple models may be combined in a document).

            1.1.1    For those that are explicitly and exactly defined in the MBASE guidelines, you should include a note under the table
                        identifying the document or section of the document (or documents?). (Where that model is defined, and which named
                        variant, organizational or project variant it represents.)

            1.1.2    For those that are NOT explicitly and exactly defined in the MBASE guidelines (such as those used in other courses,
                        company projects, etc., please provide the following via an end-note reference:

• The name of the document (and section(s)) where the model is defined
• Which variant (named, organizational or project) it represents.
• "What" the model is (usually a sentence or two to a paragraph from the document that describes the model)
• Where and how the model is described
• The "origins" and evolution of the model (you may have to ask about this). For example, the CS577 Variant of MBASE's Testing Documents (Test Plan, Test Description, and Test Results Report) were [organizational] variants of IEEE-J-STD-016-1995.

    1.3    Whether it is an Invariant, a recognized Variant, an Organizational Variant, or Project Variant, with I, V, O, P, respectively.

    1.4     Where in the life MBASE life-cycle is each "Artifact Name or Type"

            1.4.1    Created (C): generated for the first time. If this is a significant change to another Artifact Type, please indicate which one. For example, a data flow     diagram might be the basis for an entity relationship model.

            1.4.2    Expanded (E): an expansion implies more detail (NOT a transformation or change in representation, viewpoint, etc.). For example, a High-level Design might be expanded to a Detailed Design.

            1.4.3    Updated (U): changes are made to details, but not to structure or level of details (e.g. a draft might be updated to final document)

            1.4.4    Referred to (R): a team member other than the creator uses it for information

• For your project and the other for the company (or organization) you work for
• Additional responses for other projects that you become familiar with (these might be done as exceptions to the company/organization response).

    Additional definitions:

• Invariant models (I) comply with the definition of "MBASE Invariance", and would not be recognized as a variant.
• Recognized or named Variants (V) have MBASE-related tailoring instructions or guidelines (documents)
• Organizational Variants (O) are those Variants for which every project in the organization does it the same way.
• Project Variants (P) are those where the project "does it's own thing", perhaps with tailoring of an Organizational Variant, but just as likely with no basis in any organizational documentation.

        2.1    Tabular listing by Artifact: (OK, but not as useful)
 

 

 2.2    Multiple Tables by MBASE model (Preferred)

If you have any questions about the assignment, then send e-mail to csci590@scf.usc.edu