Download CEN6016ProjectDeliverables

Project Deliverables
This is an iteration-based project. All artifacts of each Iteration
are to be posted in Rational Team Concert (RTC), which is
separately documented with accompanying tutorials on my web
page. See Course Lecture Notes.
Each Iteration consists of a number of ‘deliverables’ in the
context of RTC are referred to as Work Items
Initially – for Iteration 0, you may include Work
Items in the RTC/Change and Configuration
Management (CCM) portion of RTC. The deliverables in
Iteration 0 are items of work.
Later, when specific products are developed, they will
be entered as ‘artifacts’ in Requirements Management.
Work items are activities usually resulting in producing
an artifact constituting part of each deliverable.
Executive Summary

Every iteration will include an Executive Summary.

This is to be a single page document and should
summarize the contents of the iteration:
 What
work items were undertaken (list)
 What
work items may have been changed



Note: revising artifacts is the norm in an iterative
approach to software development.
Identify Risks as a Work Item (elaborated upon ahead).
Executive Summary is likely developed by team lead and
backup.
Rational Team Concert



Rational Team Concert (RTC) will be the
tool of choice for CEN 6016 and CEN 6017.
All work items and artifacts for each
iteration will be posted to appropriate
places in your team’s project area.
A set of tutorials on RTC has been
developed for your use and will guide you.
Rational Team Concert


Tutorials include basic information on ALM/CLM,
creating and managing a Jazz account, creating a
new project, managing requirements with Rational
Requirements Composer (RRC), creating iterations,
work items, establishing the Eclipse client for your
use, source control (your programming), change
sets, and linking work items and change sets. (More
will be coming later.)
The team is responsible for familiarizing themselves
with this very popular new development
environment.
Work Items





Each iteration consists of work items undertaken.
Each Work Item will be posted to your project area in RTC,
along with the name(s) of the individual(s) primarily
responsible for accommodating each work item.
Some of these items may be Word documents, others
graphical models, tables, answers to questions, and
assessments. (A few initial work items will be placed in
Configuration and Change Management (SSM) part of RTC.)
Some work items will be done by individuals; others by more
than one team member.
Work Items will include all of your basic work item artifacts /
activities including all business modeling, requirements,
analysis and design, testing, management, deployment, and
implementation modeling items.
Grammar, Wording, and
Professionalism




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. This is a graduate level
course and mature, professionalism is expected.
EACH work item of EACH iteration must be reviewed
While the Quality Assurance Manager (ahead) may be the one
primarily responsible for grammar and wording, please
recognize that this is a TEAM responsibility!!
I cannot stress too strongly emphasis placed on professionalism
in organization, content, presenting and reporting.
Iteration #0
due 5 Sep 2012 – Start of Class
Team Formation, Project
Identification, Roles,
Methodology, Special Topics
Important




Be certain you add me as a project participant along
with other team members.
 Give me all permissions, please.
Also, when you load documents to Work Items, please
convert them so I don’t have do and I have easy access
to them.
Lastly, Iteration 0 will be graded.
As grades / comments are entered by me into RTC,
please share with all team members. Even if the
‘comments’ I offer only go to the work item owner.
Work Item: Executive Summary





Project Title
Standard contents (see previous generic
description)
Project lead (interim or permanent) will develop
the Executive Summary
Describe in summary form the work items
undertaken for this iteration. (Details will follow
and should not be included in this summary)
Include any issues encountered.
Work Item: Risk List




Risks will be identified, quantifed, and
prioritized.
See Risk List in the Word Templates links
provided.
Undertake an initial risk assessment as best
you are able at this time. It will change.
In the Iteration Assessment, risk mitigation
must be addressed.
Work Item: Team Formation




List the team members by name and the
role(s) each will undertake.
Use the descriptors on the next slide.
Please realize this may change and be
modified as individuals take on new roles
as the project evolves, but you should
make every effort to nail down roles.
(See Target Organization Assessment
in Templates.)
Team Roles and Responsibilities
(sample roles)


Team lead and backup:
Team Quality Assurance Manager : (responsible for
ensuring all work items are properly reported, formatted,
included on time and more; responsible for work item reports
to RTC)





Business Analysts (Requirement Specifications)
Application Designers (Modelers; architects)
Application Programmers (API / IDE specialists)
Database specialists (database designers; interfacing…)
Testing and Reporting (business analysts; others)
Work Item:
Approved Project Description


Topic must be pre-approved well before it becomes a
part of this iteration.
Include full write up.
 Title
 Description – several paragraphs
 Need – Significance? Usefulness? Clients?
 Availability of Resources to Specify
 Sources of knowledge
 Overall Software Development Plan (See Software
Development Plan in Templates)
 It is conceivable that you may not have this item
thought out yet. But give it a shot. Will change
later.
Work Item: Iteration Assessment


Frank assessment of iteration 0. (5-10 minutes)
One or more team members will report on Iteration
0 in classroom setting. (good, bad, and ugly)





What can be done to improve this process?
Iteration 0 will be graded. Grades: not team grades.
Individual Peer Reviews must be submitted no later
than class time on the date on which the Iteration
Reports are due/presented.
Likely accomplished by Team Leader
See Iteration Assessment in Templates
Work Item
Quality Manager’s Certification





I certify that to the best of my ability all
work items have been completed and are
included in the iteration report.
_____ Quality Manager’s (QMgr) Initials
_____ Team Leader’s (TL) Initials
Comments optional.
(completed by QMgr and TL)
Iteration #1
Business Modeling
(Domain Analysis)

Iteration #1 Business Modeling
Business Domain Analysis
Due: Wednesday, October 3rd
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;
Iteration 1 – Business Modeling and
Domain Analysis Work Items







Team Member’s Statement of Work (See link on web page)
Business Vision Document – See templates.
Business Use Case Model – See templates
Use an approved graphical tool. (Tentatively assigned.)
Business Glossary – See templates
Business Rules – See templates
Business Risk List – See templates; Revise Iteration 0
This is a hefty assignment. Start early!!
Work Item: Executive Summary



See slide 2.
Overview of the iteration from top to
bottom.
No more than one page.
Work Item: Statement of Work


You are to include each individual team
member’s statement of work (SOW)
Develop a document of sequential SOWs
and include as a work item.
Work Item: Business Vision Document
(1 of 2)

Use the appropriate forms on my web page: Link to Useful
Templates You Will Need. This is a Word document.
This captures the purpose of the application domain.
 What services are they providing?
 What are they all about?
 Who are the customers?
 What are the goals of this business?
 Primary stakeholders??
 Points of contact: emails and telephone and any notes such
as availability / non-availability; where they work, office
symbols, tech support, BAs, etc.
 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)

Use the Business 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.



Normally, in “Stakeholders,” we address those interests
NOT from a project perspective but from an organization’s
perspective: customers, users, etc. In our case, address
the interests of the stakeholders for the projects you are
undertaking.
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.
Work Item: The Business Glossary



(1 of 2)
Use the Business Glossary template.
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. Nouns.
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!
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 (and do NOT include) methods
 This, however, is for the next deliverable.)
Work Item: The Business Rules

Use the Business Rules template.

See examples on my web page. These are merely samples.




Be careful: The samples on my web page are Rules for an
Application.
In principle, the formal approach is to develop business rules
for the entire organization and not for the specific application
domain.
For our projects this year, you are to develop business rules
for the specific application domain for which we will be
developing the application.
Business Rules are policy declarations or conditions or
guidelines that must be satisfied in running the business.
Work Item: The Business Risks


Use Business Risks template.
What are some of the risks that the
organization and developers must be
constantly assessing:


Clients: market share, technology awareness,
new statutes from Washington D.C., the state of
Florida; trends in the industry; demographics;
Developers: Revisit your Risks from Deliverable
0 to update: include environmental
considerations; personnel risks; technology risks;
economic risks; time constraints; give this some
thought….
Iteration #2
Domain Modeling and Features List
due: Wednesday, Oct 17th
Executive Summary
Iterate Previous Work
Team Statement of Work (SOW)
Domain Model
The Product Vision Document (Problem Statement)
Needs and Features List
Quality Manager Assessment
Iteration #2 will be presented by each team in class
Iteration #2 – Work Items - Overview

1. Executive Summary.


2. Iterate / Review / upgrade previous artifacts


Is an essential activity to facilitate good use case development that contains
glossary items and objects from the problem space (domain). This is a graphical
model of Business Entities (enterprise as a whole). But these entities will
become useful for your application. (major artifact this deliverable; You may use
Visio or Smart Draw and import this model.
5. Product Vision and Features List


Assigning responsibilities to different roles to be accommodated on the team.
This text document should be developed by the team leader in concert with
individuals. Team leader must provide direction and guidance. All tasks and
sub-task-ids should be clearly delineated. Add column to the Team Leader Log
4. Domain Model (precursor activity to Use Case development)


Based on evaluation of your deliverable. Your changes should be annotated in
the Executive Summary.
All previous deliverables should be reviewed and
potentially updated.
3. Team Statement of Work


Summarize the Iteration.
A few sentences or paragraph; Reveals scope of project. Follow with
catagorized list of features (User Needs and Features) See lecture notes..
6. Quality Manager’s certification

that all artifacts have been reviewed and meet these sepecifications.
Work Item: Executive Summary


As previously done.
Summarize the Iteration.





The good, bad, and ugly.
Assess how all went and ways to improve
Overview of artifacts developed and your
assessment of them.
How did the team do?
No more than one page.
Work Item: Statement of Work


You are to include the Statement of Work
from my web page updated with this
Iteration’s efforts.
Include each individual team member’s
statement of work (SOW).


I am after a personal self-assessment as well
from individuals.
Remind all team members to email their
personal self-assessments / team
assessments to me.
Work Item: Domain Model
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
(responsibilities) – only attributes and connections (associations/
dependencies)
There is a decent link to a student example on my web page.
Domain Model - continued



The Domain Model is an extension of
Deliverable 1. It deals with the enterprise /
organization and is essential to
understanding the environment (in terms of
the business entities) within which the
application to be developed will function.
It is an essential artifact.
 See Lecture slides on the Domain Model
and the textbook.
Work Item: Product Vision Statement





See lecture slides and templates provided on my web page.
I am after a short description (paragraph at most) for the
Product Vision.
This results in scoping the project (together with Needs and
Features ahead).
The Product Features Section in the template is essential
and is to include identification of stakeholder needs and
their mapping to features via the traceability matrix shown
in referenced articles. (See lectures coming and slides
ahead)
The QA individual must develop a Traceability Matrix that
maps Needs to Features and vice versa. So the SQA will
have two matrices prepared. (See sample article for
guidance)
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 Product
Vision Document for a new application, because it is
these features that must be accommodated in the
delivered system. Needs are higher level and often
include very high level statements of desired needs not
all of which are features which can be implemented in a
system. (These may not be explicit, and you may have
to wing it, if these are not directly provided.)
The Features drive the development of the use cases –
our functional requirements, and the development of our
supplementary specifications – our non-functional
requirements.
Traceability Matrix – Leffingwell article
Feature #1
Need #1
Need #2
…
…
Feature #2
x
Feature #m
x
x
x
x
x
Need #n
The Stakeholder needs are in the first column and the application features that we
have defined to meet those needs constitute the columns.
Features are normally found in the Product Vision document for the Application.
36/37
Traceability Matrix






We put Xs in the cells under the features that we
have defined to satisfy the stakeholder needs.
 Please note that this is a 1:n mapping, as there
are far more features than explicitly stated Needs.
Further, the Needs are at high levels of abstraction.
Study the matrix carefully.
No X under a feature? Perhaps Need is not
mapped into feature(s)! Flag!!
Features not traced back to a Need? Perhaps we
have Features that are not traceable back to
Needs!
37/37
Needs to Feature Mapping




Maybe the Needs or Features are not clear!
Too, we are not dealing with a lot of information
here, so this traceability should be undertaken.
Leffingwell: “Once you've mapped the needfeature relationships and have determined that
the needs and features are correctly accounted
for and understood, it's time to consider the next
level of the hierarchy: relationships between
the features and the use cases.”
Coming…
38/37
More on Sample Features



Features are not behavioral (like the Use Cases - coming). These are
typically text descriptions. See text books.
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 scalable 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.
Reference

See the link on my web page under
Helpful Links: Selected Sample Student
Work:
http://www.unf.edu/~broggio/cen6016/SamplesLinksAn
dExercises/Product_Vision_10_03_07.doc


You should include much of this: the
product vision statements, stakeholder
needs, features, etc. as you deem
appropriate.
This Work Item represents a lot of work
and should be completed as a team.
Future Iterations


Will be inserted as developed.
Iteration 3 will be Use Cases