ProjectProject DeliverablesDeliverables

Version 3: 10/25/2005

Note: This document contains the deliverables for a two semester course.

This document includes Deliverables 1 to 3 but will be extended as the courses progress. Stay tuned

Overview of GuidanceOverview of Guidance I shall try to upgrade / refine

guidance for each deliverable as we progress.

Please view this file often as it will change.

Suggestions for clarity and/or consistency are always welcome.

Format of DeliverablesFormat of Deliverables All Deliverables will be via CD. Outside: Surface of CD is to clearly indicate

your course number and the team number, as CEN 6016 - Team 1. Also include the project title.

Inside: Each deliverable will be in a separate folder on the same CD, so when I access the CD, all I should see are individual folders with labels such as Deliverable n, as in Deliverable 4.

Contents of Folder Contents of Folder Each Folder (i.e., Deliverable) is to contain Management Folder:

a number of Word files discussed aheadArtifacts Folder

Contents discussed ahead.

Management FolderDocuments

Team Num file, with file name as follows (for example): Team1.Deliverablen.Date.mm.dd.yy

In this file, you are to simply (may be a single Word file): List the names of the team members Indicate who is team leader with phone number. Indicate who is the software quality analyst and phone List individual email accounts.

Iteration Plan (Include for second semester deliverables) Note that the Iteration Plan will change for each

deliverable, that is, it will be refined and ‘extended.’ Each successive deliverable will contain a ‘revised’ Iteration Plan.

Management FolderDocuments

Executive Summary Single page document; Summarizes the contents

of this folder. What ‘activities’ were undertaken What ‘artifacts’ were changed and rationale Note: revising artifacts is the norm in an

iterative approach to software development. What new ‘artifacts’ were produced Must include signatures of EACH team member

that he/she has reviewed and has ‘bought off’ on the contents of this deliverable.

If you have not read and personally reviewed the contents of the deliverable, do not sign this form!

Management FolderDocuments

Team Activities: Team Software Process (TSP), and Personal Software Process (PSP) Forms

Software Quality Analyst Report This will address in narrative or graphic form (your

choice) the status of the project with respect to identifying and tracing requirements to date as well as efforts undertaken by you regarding testing.

Artifacts Folder All developed artifacts will be found here.

Sometimes the artifacts will be models; other times, they will be documents. Artifacts are items produced by team members as a result of undertaking specific activities. Sample artifacts – likely Word documents: A

project Vision Document; the Risks List; the Business Rules document, etc.

Sample artifact likely developed in Rose: Your Use Case Folders within your Rose Model.

Artifacts Folder (continued) Sample artifacts developed in Rose

(continued): In general, specific components of deliverables

should be found here, and a number of these should be in their own subfolders, such as the user interface prototype (linked to via Rose / Requisite Pro), Use Case diagrams, Use Case Narratives, Analysis Model, Sequence Diagrams, architectural models, etc.

We will discuss in class for each deliverable.

Guidance on the Rose Browser

Use Case Diagrams in Use Case Folder within Use Case Model in Rose Capture Use Cases in separate

subfolders in the Use Case folder within Use Case Model in Rose (see the Rose Browser).

But Use Case Narratives are in Requisite Pro Capture all Actors in folder within Use

Case Model in Rose

Grammar and Wording Under NO circumstances will poor grammar or ill-

conceived sentences be considered acceptable work. EACH portion of EACH deliverable should be reviewed

and ‘signed off’ by EACH team member. (as stated) Poor adherence to this ‘standard’ will impact EACH

team member. So, check out your text BEFORE you submit it to me.

This is a TEAM responsibility!! On the provided templates, there is room for signoff by

the team / team members. Use this for verification…

Deliverable #1Deliverable #1

Business Modeling(Domain Analysis)

Deliverable #1 Business ModelingBusiness Domain Analysis

Due: Monday 10/3 Purpose:

To understand the structure and dynamics of the organization within which the application will operate;

To ensure customers, end-users, and developers understand the organization;

To derive requirements on systems to support the organization;

Deliverable 1 – Business ModelDomain Analysis

Deliverable Artifacts Business Vision Document - a text document. Business Use Case Model – captured in a

Rational Rose model Business Glossary - text Business Rules – text Business Risk List - text Domain Model - model in Rational Rose – will

accommodate in Deliverable #2.

Deliverable #1: Business Vision Document

This captures (Word document) the purpose of the business enterprise.

What services are they providing? What are they all about? Who are the customers? What are the goals of the business? Primary stakeholders??

Business Vision Document (more)

You may use the Vision Template (see web page) but you must MODIFY it so that it does NOT address a project; rather, it will capture the vision of the enterprise itself. eliminate section 2. Elaborate on section 1. In

Stakeholders, address those interests NOT from a project perspective but from an organization’s perspective: customers, users, etc. There is no Product Overview But your business vision document should address what the business is all about. Add major sections that you deem appropriate.

The Business Use Case Model When logging onto Rose, be sure to select RUP icon

from the initial window.

Be also certain to notice the tool mentors – when you select a folder in the Rose Browser, a description often appears with invaluable information.

The Business Use Case Model must be developed in the Use Case View (see last slide)

This is a single model of the key business processes of the organization.

Deliverable #1: Business Glossary Definitions of important terms used in the

business. (alphabetical) Key words: (sometimes these are called ‘core abstractions.’ ) These are often the

‘things’ the business deals with. Business Entities.

A Student Registration system might have key words like Course, Schedule, Payment, Registration, Student, Professor, ….

Deliverable #1: The Business Rules

Use the appropriate forms available at: RUP document templates are located at the site

http://jdbv.sourceforge.net/RUP.html .  See also my web page. The link for the Business Rules template is incorrect (points to the

Business Modeling Guidelines template), so there is another link to point to the Business Rules format.

There are also two former student examples on my web page to guide you. (Note: I am not disclosing their grades, or how I graded them.) These are merely samples.

Be careful: The samples on my web page are Rules for an application that will be developed. Your Rules are simply for the organization itself - the way it does business; guiding principles. It has no relationship (at this time) to an application to be developed.

Business Rules are policy declarations or conditions or guidelines that must be satisfied in running the business.

Deliverable #1: The Business Risks List

Very general at this stage. What are some of the risks that the organization

must be constantly assessing: e.g. market share, technology awareness, new

statutes from Washington D.C., trends in the industry; demographics; environmental considerations, maintaining top notch software developers, keeping developers current; training; give this some thought….

Again, this is at the organizational level.

Deliverable #2Deliverable #2

Domain ModelThe Product Vision Document

Statement of Work

Deliverable #2 – ArtifactsDue: Monday, Oct 17th

1. Build a Domain Model (precursor activity to Use Case development) Is an essential activity to facilitate good use case development that contains glossary items and

objects from the problem space (domain). 2. Build a Product Vision Document

Will include User Needs and Features 3. Develop a Statement of Work – assigning responsibilities to different roles to be

accommodated on the team. 4. Traceability Matrix Review / upgrade previous artifacts.

Business Use Case Model, Use Cases and Actors - ModeledBusiness Vision document – text, Business Glossary - textBusiness Rules - text

Deliverable #2: Domain Model

1. Domain Model – The Domain Model should be captured as a separate folder under the Logical View in your Rose Browser.

This is a major effort that takes into consideration attributes, multiplicities, associations, etc.

Be careful. the Domain Model may look like a Database Schema. It isn’t. It is similar – to a degree – to a Fully Attributed List in the Logical Model – but there are differences. Notice also – a good domain model does not have methods – only

attributes and connections (associations/ dependencies) There is a decent link to a student example on my web page.

Notice it is found in the Logical View (as it should).

Domain Model - continued A continuation of Domain Analysis… The Domain Model is an extension of

Deliverable 1. It deals with the organization. Domain Model is essential to understanding

the environment within which the application to be developed will function.

It is sometimes the only item from the Business Case. But it is an essential artifact.

See Lecture 8 on the Domain Model.

Deliverable #2: Product Vision Document

This represents the vision for the application you will be developing. This essential artifact is called the Product Vision Document.

Use the template provided. You must take the link to the RUP documents and access the

Project Management Templates : Product Vision Document. You may transfer much of the information from the

Business Vision Document to this Product Vision Document. You are to add the Problem Statements (section 2.2) and all the

other items dealing with the Stakeholder and User Profiles and Stakeholder and User Needs.

You need not include the Product Overview section. Product Features Section (section 5) is essential and is to

include identification of stakeholder needs and their mapping to features via the traceability matrix shown in lecture materials.

(Software Quality Analyst on your team will learn/use Requisite Pro. Take the Requisite Pro Quick Tour…) One other team members should be conversant.

More on Needs and Features When we are dealing with ‘needs’ and ‘features’ we

are dealing with reasonably high levels of abstraction. But it is critical to capture the features in the Vision

Document for a new application, because it is these features that must be accommodated in the delivered system.

The Features drive the development of the use cases – our functional requirements, and the development of our supplementary specifications – our non-functional requirements.

Your deliverable must contain a Traceability Matrix.

More on Sample Features Features are not behavioral (like the Use Cases). These are

typically text descriptions. Example of features: (We will discuss) ClassicsCD.com Web Shop

Need a Secure payment method.There must be easy browsing for available titles.Users need the ability to check the status of an order.Application must provide Customer e-mail notification.The catalog shall be highly scaleable to include many titles and effective searching through those titles.The Customer shall be able to customize the Web site.The Customer shall be able to register as a user for

future purchases without needing to re-enter personal information.

Deliverable #2: Statement of Work

3. Statement of Work May take on this is a bit different than the Use Case Book. It should be a

Word document. See textbook and/or templates for format

What is your team plan? Meetings/ (see forms on web page)

Who does what (that is assign roles)? What are the responsibilities that must be

fulfilled by each role? What is your plan? (See textbook) This short document should appear in the

Artifacts Folder

Deliverable #2 – Traceability Matrix

A traceability matrix associating needs to features is to be captured in the Product Vision Document.

This is essentially a 1:n mapping of Needs (from the Users/ Stakeholders) to Features that the application will accommodate. Needs are very high level and may contain items that

will not be (can not be) accommodated by the application.

Features are to be accommodated by the application. Additional guidance will be presented to support

your traceability efforts.

Deliverable #3Deliverable #3

Develop Use Case IndexDevelop Façade Use Case Specification

Develop Initial User Interface (UI) Prototype

Extend Requirements Traceability (RT) Matrix

Deliverable #3 - Use Case - Façade Iteration Initial User Interface Prototype,

Traceability due: Wednesday 10/26

Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, such as the revised Iteration Plan, etc. as required.

Specific Rework: Revisit the Business Case (Deliverables 1 and 2)

including artifacts listed below and update them. (Risks Lists – deliverable 1; Business Rules.

Revisit Artifacts from Deliverable 2 especially the Domain Model and the Product Vision Document (deliverable #2) and the Statement of Work, etc.)

Deliverable #3: New Artifacts

1. Develop Use Case Index Single page: Essentially this is a table of

contents of Use Cases Include an index for Use Cases that follow. Use

designators, UC1, UC2, etc. (to facilitate traceability)

Use Case Index is to contain an entry to support traceability, Use Case name (verb…object), short description (no more than a single sentence), and other high level items you consider important.

Construct this in tabular form using a table in Word. See power point slides for detailed attributes needed

Deliverable #3: New Artifacts

2. Develop Façade Use Case Specification. Develop an overall Use Case Diagram (all application

Use Cases and Actors). Similar to Business Use Case Model but icons are a little different.

This is sometimes called the system level use case model. This should be a single page of actors and use cases. Examples of all these can be found in Use Case book and

Visual Modeling book. Develop Façade Use Case Specifications and

associated Use Case Diagrams for each Use Case. (See examples)

Use Requisite Pro and Rational Rose (Use Case View) for your models. Link the Use Case Specifications captured in Requisite Pro and onto Rational Rose.

Use the Façade Use Cases templates from the Kulak and Guiney book. Again, see power point lectures for required attributes. (See examples of ‘reasonable’ student Use Cases posted on my web page.)

Deliverable #3: New Artifacts 3. Develop User Interface Prototype

…needed to familiarize the end user with the beginnings of the User Interface. Additional functional requirements will likely be discovered. Iterate this a as needed. (Can be done in conjunction with the Façade Use Case and will (together with Domain Model) greatly assist you for Deliverable #4, your full-blown Use Case Descriptions with alternate and exception paths.

You may use any prototyping tool you wish: VB, JavaScript, dynamic HTML, etc. Your prototype should include storyboarding.

Most teams use static html; some use Front Page; some contain Javascript, etc. It doesn’t really matter to me.

Validate the functionality represented on the user interface with VIM.

Alternatively, validate with members of other team.

Deliverable #3: New Artifacts To accompany the Façade Use Cases, user

interface prototype needs to represent the functionality that will ultimately be implemented and accessible from the UI later.

See examples of initial user interface prototypes on my web page. See also (ahead) lecture slides on User Interface Design

Deliverable #3: New Artifacts

4. Extend a Traceability Matrix Traceability Matrix is to extend the traceability

matrix developed in Deliverable #2. Traceability so far includes tracking indicators (U1, S03,

etc.) from previous work that mapped Needs to Features. There were a couple of effective ways we discussed.

In this deliverable, you are to extend the traceability from Features (captured in the Product Vision Document and documented in matrices) from Features to specific Use Cases that tell the stories of the Features. Thus your Matrix will have a 1:n mapping of Features to Use Cases.

Deliverable #4Deliverable #4 Develop Full/Mature Use Case Specifications Develop Activity Diagram for each Use Case Extend Requirements Traceability (RT) Matrix Revisit and Revise:

Domain Model, Façade Use Case Specifications and Diagrams User Interface; All Management Docs

Deliverable #4 Overview due: Monday, 11/14

Executive Summary; Cite all revisions and overview activities.

Develop Mature Use Case Specifications and associated Use Case Diagrams for each Use Case.

Each Use Case is to be accompanied by an Activity Diagram that should indicate flow for all paths in the Use Case

Extend the Traceability Matrix by tracing all use cases backward to specific features and forward from features to use cases.

Revisit the Domain Model for added / altered business entities; revisit your Risks document, Business Rules, and Product Vision statement.

Upon ‘completion’ of Use Case specifications, revisit the UI.

Use Case Specifications Complete Use Case Specification and Use Case

Diagrams for each Use Case – This is a major assignment.

Complete your model by including alternative, exception flows, and ‘sub-flows’, using extension points or other tags as appropriate. Include all subflows with your use case narratives. Modify any use cases you feel are associated with

any ‘included’ or ‘extending’ use cases and change use case diagrams to reflect these use cases. (There definitely should be some.)

Develop a single Use Case Diagram for the entire Application too. This will be a single diagram containing all actors and all use cases and connections.

Use Case Specifications - More Allocate functional requirements / features to use cases

via the stories of interactions. This is a painstaking and long task! It will underpin your entire design. Spend time here!!!! Recognize that Use Cases are NOT functional requirements; rather, they are stories of actor-application interactions which contain the required functionality. Try to get the proper level of granularity. (Discussed in class).

All customer functionality should be accounted for here. Be certain to use your Domain Model and italicize or bold all

references to entities in the domain model and/or Glossary.

Ensure everything the customer desires is accounted for! Iterate on the Use Case Model. Review, Review,

Review!

Rational Rose and Requisite Pro

In Rose, put Use Cases into packages appropriate to the major feature(s) and groupings of features they address. (These may assist in our software architecture later – as these may

become likely subsystems). Use Rose (Use Case View) and Requisite Pro to link all these

into a single browser (SQA team members). Kulak and Guiney book (Use Cases); Visual Modeling book

and Rose Basics (see power point lecture slides for examples.)

Recognize that Use Cases are really never ‘finished.’ They become more ‘mature’ as we learn more.

Activity Diagrams Develop one activity diagram per Use Case.

Activity Diagram is to should include all alternate paths. You may view an Activity Diagram as a visual model

of the Use Case, since it will contain all scenarios.

Include Activity Diagrams in a package in Rose Browser in the Use Case View under Use Case Models in a folder entitled Activity Diagrams. See Visual Modeling text for examples and use Rose.

Traceability Matrix Extend your traceability by tracing all features forward to

individual or groups of Use Cases required to capture these features.

Similarly, trace Use Cases back to features that the Use Cases address.

You must ensure that every feature is accommodated in the collection of Use Cases and that there are no superfluous paths in use cases that do not trace back to specific features.

You will need to address the scenarios in each use case to do an adequate trace. This is a lot of work. If you find a scenario that does not relate back to a feature, check the feature; if necessary check the Need. Something needs to be resolved… Report on this activity.

Revisiting / Iterating Previous Deliverables Special emphasis: UI and

Domain Model Be absolutely certain to revisit / modify your

User Interface Prototype in light of the development of the collection of Use Cases. Recognizing that this collection represents the functionality of the application, does the Use Case support these major functions at a sufficiently high level.

The most major options presented on the UI must reflect the most major features to be implemented – up front…

This will be a major milestone in our development efforts.

Once we can ‘baseline’ these artifacts with user concurrence, we will then embark upon Analysis Modeling

Deliverable 5due: 11/30

1. Analysis Model 2. Non-Functional Requirements:

Supplementary Specification Document

3. Traceability Matrix

Analysis Model

1. Analysis Model (Preliminary Design) Part 1: Static Model – VOPC

Your analysis model must include boundary classes, a control classes, and entity classes required for each Use Case.

Model is to be fully connected - show labeled associations, multiplicities (for entity classes – may come from Domain Model)…

Should be a one-page drawing per Use Case Class structure may be realized with the standard

stereotyped classes or the RUP icons

Analysis Model – Sources; Guidance Use your initial user prototype (boundary), Domain model (entities), and Use Case Specifications (control as well as the

others) See also your Features to ensure all features are captured. See Visual Modeling Book; RUP; Logical View on Rose

Allocate as many attributes and methods (responsibilities) as possible to each of the analysis classes.

Can one inspect any path through a use case and see where/which objects will accommodate the functionality? (Can it be traced (with your finger...) through the objects

as you read through the path description?

Analysis Model 1. Analysis Model (Preliminary Design) Part 2: Dynamic Model – Interaction Diagram

Your analysis model must include an Interaction Diagram (Sequence Diagram and Communications Diagram) for the basic course of events for each Use Case.

Use your analysis classes in this modeling. There are a host of examples in my notes and in

the books for this course. Object structure may be realized with the

standard stereotyped classes or the RUP icons

Non-Functional Requirements 2. Supplementary Specifications Document See Use Case Textbook for examples of ‘tables’ System Size:

Small systems: functionality; performance

Large systems: Portability; Maintainability; Scalability; Reliability; Security

How about: Persistence? Will discuss more in class.

The Supplementary Specifications for Non-Functional Requirements should be a Word document containing the non-functional ‘tables.’ Link this in to Req Pro.

Traceability Matrix and Associated Documentation

1. Map each Use Case (such as UC1, …, UCn) to the analysis classes that will accommodate the Use Case functionality. (Recognize that there may be many scenarios in each use case. But they must be traceable to analysis classes and hence the matrix.

You may have to be somewhat creative to show this kind of trace to specific analysis classes.

Again, you might include a VERY short description of the Use Case (its name and short description) and then the analysis classes that realize the specification. Link this in to Requisite Pro.

Ensure ALL traceability is VERIFIED to date! “Let no function be left behind!” (Ha)

Previews of Coming Previews of Coming Distractions!Distractions!

Deliverable 6 (ahead) was from last year. It will be changed, but likely not a great deal.

Second Semester Deliverables(anticipated)

Deliverable #6 – User Interface Design Deliverable #7 – Layered Architectural Design Deliverable #8 – Detailed Design - Iteration Planning

and Use Case Realizations – Context Diagrams only. Deliverable #9 – Subsystem Design – Interaction

Diagrams (both) and VOPC diagrams. Deliverable #10 –Class Design and Implementation #1;

First Functional Demonstration Deliverable #11 – Final Deliverable: Complete

Implementation Model and Demonstration including client testing.

Deliverable #6 - User Interface Designdue: Wednesday, 26 January 2005

Purpose: To design a user interface that reflects application functionality. This should be a significant refinement of your initial

user interface prototype based on your increased knowledge and understanding of the requirements.

This user interface should demonstrate the vast majority of key items of functionality as found in the use cases.

In your classroom and field presentation, you are to demonstrate how your UI satisfies required functionality.

Utility and Usability Principles as cited in the lecture slides and your text will be emphasized in evaluation.

Verify your UI by running it against your use cases to ensure all functionality is captured.

Deliverable #6 - User Interface Design

I should be able to access the Deliverable #6 folder on your CD and bring up the UI and execute it successfully. I should be able to navigate from screen to screen to pursue

some scenario from a use case. I should NOT have to hunt and peck and wonder…

Recognize that some (a few) of the windows / displays will be / may be hard coded and that demonstrated functionality may not be totally backed up with implemented code or efficient algorithms. But the implied functionality must be clearly evident.

Text caveats in the UI are appropriate. This will be field tested for the Medical Project.