Project Deliverables

1
Project Deliverables

• Version 3 10/04/2006
• Deliverable 3 Added

2
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.

3
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.

4
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.

5
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.

6
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!

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

8
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.

9
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.

10
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

11
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

12
Deliverable 1

• Business Modeling
• (Domain Analysis)

13
Deliverable 1 Business ModelingBusiness 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

14
Deliverable 1 Business ModelDomain
AnalysisDeliverable 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.

15
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??

16
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 organizations
  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.

17
Deliverable 1Business Use Case Model

• Simple in structure . See pp 151-152 in the RUP.
• You only need show the Model (with actor and
  business use case icon) (top part of figure 8.5)
• You do NOT have to display the Use Case
  specification.
• Each use case is identified and actors who
  interact with this and each business use case.
• A Business Use Case Diagram (the top part of
  figure 8-5) is developed in verbobject format
  and captured in Rose.
• All major use cases and actors should be captured
  in this business model.
• See link to sample on my web page.
• Note Its location is in the Use Case View,
  Business Use Case Model (in the Rational Rose
  Browser)

18
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.

19
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, .

20
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.

21
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.

22
Deliverable 2

• Domain Model
• The Product Vision Document Statement of Work

23
Deliverable 2 ArtifactsDue 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

24
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 isnt. 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).

25
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.

26
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.

27
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.

28
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.

29
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

30
Deliverable 3 Use Case - Façade Iteration and
Initial User Interface Prototype

• due Monday 10/25

31
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 important. Construct this in
  tabular form using a table in Word. See power
  point slides for detailed attributes needed. See
  examples on web page too.

32
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.)

33
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. Be
  sure to note the differences.

34
Guidance on User Interface Prototype

• Develop User Interface Prototypeneeded 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 web page.
• See also (ahead) lecture slides on User Interface
  Design