Project
Project Deliverables Deliverables
Version 5: 11/15/2006
Deliverable 5 Added
Overview of Guidance Overview 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 Deliverables Format of Deliverables
All Deliverables will be via CD.
Outside: Surface of CD is to clearly indicate
your course number and the team number, as CIS 4251 - 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 ahead
Artifacts Folder
Contents discussed ahead.
Management Folder Documents
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 Folder Documents
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
Management Folder Documents
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
(optional)), 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).
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 #1 Deliverable #1
Business Modeling
(Domain Analysis)
Deliverable #1 Business Modeling Business Domain Analysis
Due: Monday, October 2, 2006
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 Model Domain 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 #2 Deliverable #2
Domain Model
The Product Vision Document
Statement of Work
Deliverable #2 – Artifacts Due: Monday, Oct 16th
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.
Review / upgrade previous artifacts .
Business Use Case Model, Use Cases and Actors - Modeled
Business Vision document – text, Business Glossary - text
Business 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.
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.
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
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 #3
Use Case - Façade Iteration and Initial User Interface Prototype
due: Monday 10/25
Use Case - Façade Iteration plus Initial User Interface Prototype
due: Monday 10/30
Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, such as the revised Iteration Plan, etc. as required.
Specific Work:
Revisit the Business Case (Deliverables 1 and 2) including artifacts listed below and update them. (Risks Lists;
Business Rules; especially the Domain Model; Statement of Work, etc.)
Include an index (numbered) for Use Cases that follow. (discussed in class and via slides)
Use Case Index is to contain a number, Use Case name,
short description, and other high level items you consider
Guidance on Façade Iteration
Develop an overall Use Case Model (all application Use Cases and Actors). Similar to Business Use Case Model.
Develop Façade Use Case Descriptions and associated Use Case Diagrams for each Use Case.
Use Rose (Use Case View) for your models. Link the Use Case Description text and ensure these descriptions are on the CD you turn in for grading.
Model your Façade Use Cases using the Kulak and Guiney book. Again, see power point lectures for required
attributes. See examples of ‘reasonable’ student Use Cases examples posted on my web page.
Additional information: Visual Modeling book and Rose
Basics (see power point lecture slides for examples on
including your Use Cases in your Rose Model in the Use
Case View.)
Guidance on : Facade Iteration
Remember that the Façade iteration names the use case, identifies actors, provides a short
description, frequently includes pre- and post conditions, triggers, etc. But it does NOT
include the detailed actor-system interactions.
See lecture notes for required attributes.
Must include all Use Cases.
Include your single Use Case Model in the Use
Case View (in Rose) in the folder provided by
Rose. Note: this is NOT the Business Use Case
Model, which has been completed; more, the
icons are different for the actors and use cases.
Guidance on User Interface Prototype
Develop User Interface Prototype…needed for
requirements capture!!! Iterate this as needed. (Should 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, etc. Your prototype should include storyboarding.
Most teams use static html; some use Front Page;
some contain Javascript, etc.
To accompany the Façade Use Cases, user interface prototype needs to be total complete. While we are not including actor – application ‘interchanges,’ these are essential for the next deliverable.
See examples of initial user interface prototypes on my
Deliverable #4 Deliverable #4
Develop Full/Mature Use Case Specifications
Develop Activity Diagram for each Use Case
Revisit and Revise:
Domain Model,
Façade Use Case Specifications and Diagrams
User Interface;
All Management Docs
Deliverable #4 Overview due: Monday, 11/13
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
Please ensure (I want you to certify this…) that there are at least two of you undertaking the Rose Modeling.
Revisit the Domain Model for added / altered business
entities; revisit your Risks document, Business Rules, and Product Vision statement.
If you change these documents, please site the changes in your
Executive Summary.
Use Case Specifications
Developing the Complete Use Case Specification and Use Case Diagrams for each Use Case – This is a major assignment.
We will have a major presentation on this deliverable.
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 specifications (narratives).
Now that you are supplying the text of actor – system interchanges, it is
quite likely you will have include and extend use-cases. Be certain to
separately document them in your use-case index and additional use-
cases as needed. (I would be amazed if there aren’t any.)
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 in themselves; 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 Modeling Use-Case View
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)
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 separate 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.
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
Please also note that this deliverable involves considerable work with Rose modeling. Be certain to share this workload equally among the team members and let me know who has
responsibility for what activities in your Executive Summary.
This is not a deliverable that can be easily split across four or
five people. You will need to work together on these.
Deliverable 5 Deliverable 5
Task 1: Analysis Model and
Task 2: Non-Functional Requirements
Due: 12/4/06
Task 1: Analysis Modeling
Analysis Model (Preliminary Design)
Contains communicating boundary, control, entity objects with relationships
Will flow from your use case narratives and prototype
Supports Interaction Modeling and much more…
Designed to lead ultimately to the class model (static)
Sources: Use your prototype (boundary) again,
domain model (entities), and use case descriptions (boundary, control, and entity objects) in earnest.
They may not be enough, but will help. See also your Vision Document.
See Visual Modeling Book; RUP; Logical View on
Guidance on Deliverable #5 Analysis Model - 1
Static Model:
Include boundary classes together, control classes together, and entity classes together all without
associations to other classes. (a one-page drawing) This should partition all the classes by type. Include all
attributes / methods with each class, but not connectivity.
(See textbook for sample rendering)
Follow this with a fully ‘connected’ model – for each use case.
Be sure to study textbook and lectures on boundary,
control, and entity models
Guidance on Deliverable #5 Analysis Model - 2
Dynamic Model – Interaction Diagrams
For each Use Case Do:
One sequence diagram for the happy path.
You may also be able to include alternate paths / exception paths on this single drawing.
You are to include your use-case specification text down the left boundary of the sequence diagram page. This will serve as a check on this realization of the narrative.
Clearly, this must be done in Rose.
Also include collaboration diagrams (now called
communication diagrams). You only need toggle F5.
These models will be in packages in the Logical Model
Additional Guidance on Deliverable #5
Remember, the validity of the analysis modeling is
simply can I look at any path through a use case and see where/which objects will accommodate all the
functionality captured in a scenario? Can it be
traced (with your finger...) through the objects as you read through the path description?
This is the check to make! Verify Traceability!!!
Try to cite as many attributes and methods
(responsibilities) as possible in the respective class-
names – boundary, control, and entity.
Additional Guidance on Deliverable #5
For boundary to control classes, the association line is sufficient, because it cannot be determined what method in control class will be invoked from the boundary class unless we consider a specific scenario. Better, though, is a series of boundary classes constituting the interface.
See lecture slides for example.
Associations among entity classes should have the
multiplicities, aggregations, dependencies, etc. cited, as usual. They are appropriate here and may come from your domain model, which will VERY likely need
upgrading after/during your exercise.
BE CERTAIN to look at the slides on my web site which
‘supplement’ your readings! There are many examples
Task 2: Non-Functional Requirements
See Use Case Textbook for ‘tables’
Small systems:
functionality; performance
Large systems:
Portability; Maintainability; Scalability; Reliability; Security
How about:
Persistence?
Will discuss more in class; Remember the Supplementary Specifications for Non-Functional Requirements.
Thus the Supplementary Specifications Document should be a Word document containing the non-functional ‘tables.’
Do not take this part of the deliverable lightly. It is essential
The End is in Sight!
The End is in Sight!
This is a major deliverable, especially in lieu of the very high granularity of your use-cases. It is VERY likely that your use-cases may need significant revisiting to drill down to lower levels.
This may well be true to support a more comprehensive deliverable #4 but to serve as primary input to deliverable
#5. I’d start with your use-cases…
I strongly urge you to jump on this one. You have three weeks, which is a lot of time. But there is a lot of work to be done.
I strongly suspect that you will need to work physically together to drill down in your use-cases – your primary input to ‘this’
deliverable. There is a ton of work to be done but the opportunities to learn this process is super!
Do NOT hesitate to come and see me along the way!
