ProjectProject DeliverablesDeliverables

Deliverable 1 PostedVersion Numbers will reflect added Deliverable

numbers.

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 CGS 4308 - Team 1 or CIS 4327 – 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.

This way, I can also see enhancements to previous deliverables.

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 Folder Documents (1 of 3) 1. Team Num file

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.

2. Iteration Plan (Include for CIS 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 (2 of 3)

3. 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. (signatures may be virtual)

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

Management Folder Documents (3 of 3)

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

5. 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 and verification (we will discuss).

Artifacts Folder (1 of 2) All developed artifacts will be found here.

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

the Risks List; the Business Rules document, etc.

Artifact likely developed in Rational Rose: Your use-case diagrams, actors, etc.

Artifacts Folder (2 of 2)

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 Narrative, Analysis Model, Sequence Diagrams, Communications 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. Remember: you only get one chance to make a first impression. Poorly done work will really hurt your grade and perception of what otherwise might be high-quality work.

EACH portion of EACH deliverable should be reviewed and ‘signed off’ by EACH team member. (as stated)

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: Wednesday, September 19th, 2007start of class.

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

accommodated in Deliverable #2.) SQA Report This is a hefty assignment. Start early!!

Deliverable #1: Business Vision Document (1

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

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?? This is NOT a product vision document (the

product you will develop). This is about the business, enterprise, environment.)

Business Vision Document (2 of 2)

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.

This is a template. It offers organization, but it need to be rigidly adhered to.

The Business Use Case Model (2 of 2)

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 (1 of 2)

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

What is needed here are acronyms, important definitions, basically the jargon of the organization. These will be heavily referred to when we do use cases!

Deliverable #1: Business Glossary (2 of 2)

Another key component of domain analysis is the domain model (next deliverable). Here, we supplement the glossary by adding in a graphical mode – business entities, their relationships and associations:

(What’s important in business entities are the ‘attributes.’ So, for example, if you were defining a Student business entity, you might include things like: ssan, classification, gender, major, gpa, projected graduation date, ACT/SAT scores, etc.

We do NOT worry about methods (operations here) This, however, is for the next deliverable.)This, however, is for the next deliverable.)

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.

See examples on my web page. These are merely samples. Be careful: The samples on my web page are Rules for an

application that will be developed (later). 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. That’s it! Have fun!