Project Deliverables

1
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. (exceptions
  will be noted ahead)
• 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.
  Work Items are activities that produce
  artifacts.
• Later, when specific products are developed,
  they will be entered as artifacts in
  Requirements Management (later, in Quality
  Management)
• Work items are activities usually resulting in
  producing an artifact constituting part of each
  deliverable.

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

3
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
  teams project area.
• A set of tutorials on RTC is under development
  for your use and will guide you.

4
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 or
  Visual Studio for your use, source control (your
  programming), change sets, and linking work items
  and change sets, traceability, and much more.
• While tutorials currently exist (see Block 2),
  these are under revision, as most were developed
  two years ago.
• The team is responsible for familiarizing
  themselves with this very popular development
  environment.

5
Work Items

• Each iteration consists of work items undertaken.
  
• Each Artifact 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 outputs of your basic
  work items. Examples include all business
  modeling, requirements, analysis and design,
  testing, management, deployment, and
  implementation modeling artifacts and much more.
  

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

7
Iteration 0due Wednesday, 10 Sep 2014 Midnight

• Team Formation, Project Identification, Roles,
  Methodology, Special Topics
• Initial Risk Assessment

8
Important

• Be certain you add me as a project participant
  along with other team members.
• Give me all permissions, please.
• (I may set this up myself)
• Iteration 0 will be graded.
• As I enter comments on the artifacts in RTC,
  please share with all team members. Even if the
  comments I offer only go to the work item
  owner.
• I will be putting all your grades in Blackboard
  at this time.

9
Work Item Produce Executive SummaryArtifact
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. This is only an
  overview
• Include a list of team members and assigned roles
  an backups
• Include any issues encountered.
• Include the Iteration assessment text (see ahead)
• Word Document, unless otherwise directed.

10
Work Item Team FormationArtifact Include in
Exec Summary

• List the team members by name and the role(s)
  each will undertake.
• Use the descriptors on the next slide. These are
  to be included in the Executive Summary, a Word
  Document.
• 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.
• Include in Executive Summary

11
Work Item Create Team Roles and Responsibilities
Artifact Role and Backup Identification

• 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)
• Include in Executive Summary

12
Work Item Develop Iteration AssessmentArtifact
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.
• Brief Presentation accomplished by Team Leader
• Include in Executive Summary

13
Work Item Develop Risk ListArtifact Risk
Management Plan

• Risks will be identified, quantifed, and
  prioritized.
• A Risk Management Template is provided on my web
  page. At this point, however, we are only
  after an appreciation of risk. There is no
  need to fully document a project that is not yet
  defined. But Risk is a Living Document, so give
  it a shot as best you can. It will be revised in
  each iteration and made more complete.
• Try to understand risk identification, risk
  mitigation, risk computation, etc. This is a
  separate Artifact.

14
Work Item Develop Approved Project
DescriptionArtifact Project Proposal Plan

• 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
• It is conceivable that you may not have this item
  thought out yet. But give it a shot. Will
  change later.
• This is to be a Word Document. Template
  provided. See web page This is a separate
  artifact.

15
Rational Team Concert

• The following artifacts are to be inserted into
  RTC
• Executive Summary
• Risk Document
• Approved Project Description Proposal

16
Iteration 1to be refined

• Business Modeling
• (Domain Analysis)

17
Iteration 1 Business ModelingBusiness 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

18
Iteration 1 Business Modeling and Domain
Analysis Work Items

• Team Members 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!!

19
Work Item Executive Summary

• See slide 2.
• Overview of the iteration from top to bottom.
• No more than one page.

20
Work Item Statement of Work

• You are to include each individual team members
  statement of work (SOW)
• Develop a document of sequential SOWs and include
  as a work item.

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

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

23
Work Item Business Use Case Model

• Use the Business Use-Case template.
• Simple in structure . See pp 151-152 in the RUP
  textbook.
• You only need show the Model (with actor and
  business use case icon) (top part of figure 8.5)
  (Single page)
• You do NOT have to display the Business Use Case
  spec.
• 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.
• All major use cases and actors should be captured
  in this business model.
• See link to sample on my web page.
• Note Develop this artifact in the Use Case
  View, Business Use Case Model using a
  pre-approved tool set.

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

25
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
• (Whats 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.)

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

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

28
Iteration 2due Wednesday, Oct 17th

• Executive Summary
• Iterate Previous Work
• Team Statement of Work
• Domain Model
• The Product Vision Document (Problem Statement)
• Features List
• Quality Manager Assessment

29
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 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 (responsibilities) only attributes and
  connections (associations/ dependencies)
• There is a decent link to a student example on my
  web page.

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

31
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 (section 5) is
  essential and is to include identification of
  stakeholder needs and their mapping to features
  via the traceability matrix shown in referenced
  articles.
• The QA individual must develop a Traceability
  Matrix that maps Features back to Needs (here).
  So the SQA will have two matrices prepared. (See
  sample article for guidance)

32
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. 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.
• The Features drive the development of the use
  cases our functional requirements, and the
  development of our supplementary specifications
  our non-functional requirements.

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

34
Iteration 3due Wednesday, Oct 31st

• Executive Summary
• Iterate Previous Work
• Team Statement of Work
• Use Case Index
• Use Cases including all Façade and Filled (basic
  use cases and those containing happy path
• Traceability Matrices
• Quality Manager Assessment

35
Iteration 3 Work Items - Overview

• 1. Executive Summary.
• Summarize the Iteration.
• 2. Iterate / Review / upgrade previous artifacts
  including the Features List
• Based on evaluation of your iteration, Your
  changes should be annotated in the Executive
  Summary. All previous deliverables should be
  reviewed and potentially updated.
• 3. Team Statement of Work
• 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. Team
  members decide on allocation of Work Items.
• 4. Update Features List to cover but not exceed
  Scope Add comments.
• 5. Provide Use Case Index (see slides for
  examples and description)
• 6. Provide Use Case Diagrams for each use case
  specification (may include with the Use Case
  Specification (Narrative).
• 7. Provide Use Cases one set of filled use
  cases (use case that includes only the happy
  path)
• 8. Provide complete use cases (all alternatives
  / exceptions included) (coming)
• 9. Provide Traceability Matrices for Needs to
  Features to Use Cases and vice versa..
• 10. Quality Managers certification artifacts
  are reviewed.

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

37
Work Items Review Previous Artifacts

• Review primary Needs and Features recognizing
  team members know more about the application
  domain.
• Review and update the domain model to include
  additional / modified business entities.

38
Work Item Statement of Work

• You are to include the Statement of Work from my
  web page updated with this Iterations efforts.
• Include each individual team members 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.

39
Work Item Update Features List

• Update Features list with current knowledge.

40
Work Item Create Use Case Index

• See examples on my web page.
• This is a one-pager listing the use cases to
  come.
• Each entry should have a short user-stories as
  the description of the use case.

41
Work Item Develop Use Case Diagrams

• Develop Use Case Diagrams to include actors and
  use cases.
• You may include individual use-case diagrams with
  their specific use case specification, if you
  wish.
• Not a bad idea, however, to have them all listed
  one after the other here

42
Work Item Develop Use Case Specifications

• The use cases are to be (first) a set of façade
  level use cases.
• Secondly, each use case is to have a second one
  that includes a the basic couse of events.
• Be aware, the next iteration will have all
  alternatives / exceptions developed

43
Work Item Develop Traceability Matrices

• There needs to be a traceability matrix outlining
  needs mapped to features mapped to use cases.
• See examples in my slides and in the article by
  Leffingwell.

44
Work Item Quality Mangers Certification

• Need sign off that the entire team approves of
  the deliverable constituting the third Iteration.

45
Iteration 4due 26 Nov 2012

• Very important deliverable as we approach the end
  of this semester.
• Work items and artifacts follow (you know the
  drill by now)
• 1. Executive Summary
• 2. SOW
• 3. QM certification. Ensure ALL review these
  documents
• 4. Features List (taken from Product Vision will
  likely be okay)
• 5. Traceability Matrices for Needs to Features
  to Use Cases
• 6. Complete Use Cases with all alternatives
  and exceptions. Use Case Diagrams too. Precede
  this with the Use Case Index.
• 7. Initial Data Base Design. (Team 1 will
  present theirs.)
• 8. Upon feedback from me, please down load in
  hard copy the use cases, traceability matrices
  (from product vision and this one), and the data
  base design.
• 9. Team 1 is to present their artifacts.

46
4. Features List

• The Features List will be input to the COJ and to
  UNF (re your team).
• The Clients will prioritize their needs based on
  these features. These constitute the product
  backlog owned by clients.
• Development teams (soon) will develop their own
  Sprint backlogs (we will discuss)

47
5. Traceability Matrices

• Traceability Matrices mapping Needs to Features
  to Use Cases are needed.
• See samples for format.
• Essential for tracking our progress via Sprints
  and ensuring we are working on real requirements.

48
6. Complete Use Cases

• Essential component of the iteration. Preceded
  by the Use Case Index (one page) and accompanied
  by Use Case Diagrams per use case, you are to
  significantly expand your use case specifications
  to include all scenarios worthy of expansion.
• Several samples are available for your study.
• This essentially ends or creates a base line of
  functional specs, so it is essential that you
  attempt to capture all that needs to be
  documented.
• Of course, the use cases are never totally
  complete. ?

49
7. Initial Data Base Design

• Your Work Item here is to develop and document
  your first cut at a viable data base design given
  your many constraints.
• Visual modeling is critical along with text to
  accompany / explain your modeling
• This will be supplied to our clients (COJ and
  UNF) for verification, so we are after your best
  attempt at a good data model.

50
8. Preparation for Incremental Delivery to
Clients

• Be prepared to download, print, and provide a
  professional portfolio of your work to be
  submitted to the client.
• More later on format, etc.

51
Iteration 5due 5 Dec 2012

• In lieu of a final exam, we have a short term
  iteration for these work items..
• 1. Exec Summary, SOW, QM Certification.
• 4. Refinements of iteration 4. These could be
  significant.
• 5. Initial prototype of your Interface.
• 6. Upon feedback from me, please down load in
  hard copy of revised documentation from iteration
  4 plus images of your interface design.
• 7. Team 3 will present theirs for the class
  More later on this deliverable.

52
Thats it for now.

• Starting in January, we will be deeply immersed
  in development starting with the architecture
  followed by the MVC design strategy and
  implementation.
• All teams will, upon prioritization of needs by
  our clients (their product backlog), will decide
  your own sprint backlog. This will take
  participation of all team members in deciding the
  contents of each sprint and commitments thereto.
• We will talk more later, but from here on, the
  development will be directed by the team using a
  Scrum process as nearly as possible.