Project Deliverables - PowerPoint PPT Presentation


PPT – Project Deliverables PowerPoint presentation | free to view - id: 71557f-NjhhN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Project Deliverables


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 ... – PowerPoint PPT presentation

Number of Views:38
Avg rating:3.0/5.0
Slides: 49
Provided by: bob1158


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Project Deliverables

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. Your
    activities are referred to as Work Items your
    products are Artifacts (documents, models,
    templates, )
  • Initially for Iteration 0, you may include
    Artifacts in a place with RTC to be determined.
    I will announce the proper application within
    RTC into which the artifacts are to be ported.
  • Remember, Work items are activities usually
    resulting in producing an artifact constituting
    part of each deliverable.

Executive Summary
  • Every iteration will include an Executive
  • This is to be a single page or two 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
  • There are several items to be included in the
    Exec Summary.
  • More 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 are undertaken using RTC 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.

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

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. As the projects develop,
    different artifacts will be ported into different
    applications within RTC. But the entire project
    will be visible to all on your team (and me).
  • Sample artifacts 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.

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
  • 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
  • I cannot stress too strongly emphasis placed on
    professionalism in organization, content,
    presenting and reporting.

Iteration 0 due Saturday, 13 Sep 2014 Midnight
  • Executive Summary (Team Formation, Project
    Identification, Roles, Organization of Team),
    Initial Risk Assessment, Approved Project

Work Item Produce Executive Summary Artifact
Executive Summary (Overview)
  • Project Title
  • Standard contents (see previous generic
  • Project Lead (interim or permanent) will develop
    the Executive Summary
  • Describe in summary form the work items
    undertaken for this iteration and cite the
    artifacts produced.
  • Include a list of team members and assigned roles
    an backups
  • Include any issues encountered.
  • Include the Iteration assessment text (see ahead)
  • See additional contents required in the Exec
    Summary ahead.
  • Word Document, unless otherwise directed.

Work Item Team Formation Artifact Include in
Exec Summary
  • 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.
  • Include in Executive Summary

Work Item Create Team Roles and Responsibilities
Artifact Role and Backup Identification Include
in Executive Summary
  • 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
  • Testing and Reporting (business analysts
  • Include in Executive Summary

Work Item Develop Iteration Assessment Artifact
Iteration Assessment Artifact Individual Peer
  • 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 will be placed
    in Blackboard.
  • 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
    or others on Team.
  • Iteration Assessment will be presented in class
  • Peer Reviews are sent individually to me via
  • Neither of these artifacts are to be included in
    RTC, but they are documents produced as part of
    this deliverable.

Work Item Develop Risk List Artifact Risk
Management Plan
  • Risks will be identified, quantifed, and
    prioritized numerically descending.
  • 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 and will be ported into RTC
    along with the Exec Summary and the Approved
    Project Plan (ahead)

Work Item Develop Approved Project
Description Artifact Project Proposal Plan
  • Topic must be pre-approved well before it becomes
    a part of this iteration. The team and I will
    iterate several times prior to approval.
  • 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 and is to be ported into RTC

Summary for Iteration 0 Rational Team Concert
  • The following artifacts are to be inserted into
  • Executive Summary
  • Risk Document
  • Approved Project Description Proposal
  • Other artifacts produced NOT ported into RTC
  • Iteration Assessment (short presentation)
  • Peer Reviews sent to Professor before time/date
    of due iteration.
  • Procedures will be provided.

Iteration 1 due 4 Oct (Saturday)
  • Business Modeling
  • (Domain Analysis)

Iteration 1 Business Modeling Business Domain
Analysis Due Saturday, October 4th
  • Objectives
  • To understand the structure and dynamics of the
    organization within which the application will
  • To ensure customers, end-users, and developers
    understand the organization
  • To derive requirements on systems to support the

Iteration 1 Business Modeling and Domain
Analysis Overview of Work Items and Artifacts
  • Executive Summary
  • Statement of Work
  • Vision Document
  • Glossary Document
  • Business Rules Document
  • Business Risks Document Revise Iteration 0
  • Include Team Members Statement of Work
  • At the time of this writing, templates are
    provided. But it is possible we will use
    templates within RTC.

Work Item Develop Executive Summary Artifact
Executive Summary
  • Refine/expand/update Exec Summary.
  • Overview of the iteration from top to bottom.
  • No more than one page.

Work Item Develop Statement of Work Artifact
  • You are to include each individual team members
    statement of work (SOW)
  • This document is a list of activities and who did
    what and how long it took, if on target, not on
    target, tracking in general.
  • This is an essential document.

Work Item Develop Product Vision Document
Artifact Vision Document (1 of 2)
  • Use appropriate template on my web page or RTC -
    TBD Link to Useful Templates You Will Need.
  • This captures the Vision of the Business
  • Introduction
  • Positioning (Problem Statement Product Position
  • Stakeholder and User Descriptions
  • Stakeholder summary User summary user
  • Summary of key stakeholder or user needs
  • Produce Overview
  • Product Features
  • Other Product Requirements
  • (This is really not a Business Vision document
    but rather a Requirements Vision Document where
    the product is more of a concern rather than the
    business use case.)
  • See Student Example of Business Vision on my web

Work Item Develop Product Vision Document
Artifact Vision Document (2 of 2)
  • Use the Vision Template (see web page). Note
    The Business Vision document addressed the vision
    of the enterprise itself. We are doing the
    Requirements Vision document, where we address
    the project/product vice the business.
  • Stakeholders, are addressed from a project
    perspective rahter than from the organizations
  • Add or omit major sections that you deem
    appropriate. But be careful to not miss the
    intent of this document.

Work Item Develop Glossary (1 of 2) Artifact
Glossary Document
  • Use the Business Glossary template.
  • Definitions of important terms (entities) 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!

Artifact Glossary Document (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
  • (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)
  • This, however, is for the next deliverable.)

Work Item Develop Business Rules Artifact
Business Rules Document
  • Use the Business Rules template.
  • See examples on my web page. These are merely
  • Be careful The samples on my web page are Rules
    for an Application. See Chapter 8 in the RUP
  • 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
  • Business Rules are policy declarations or
    conditions or guidelines that must be satisfied
    in running the business.

Work Item Capture Business Risks Artifact
Risks Document
  • Use Business Risks template from Iteration 0
  • What are some of the risks that the organization
    and developers must be constantly assessing (put
    into categories) Expand your thinking on Risk to
    include company / corporate risk as well as Risk
    associated with development if you can
  • 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.
  • Environmental
  • Social
  • Technical
  • Compute risk values and prioritize.

Iteration 2 due Sunday, Oct 18th
  • Executive Summary
  • Iterate Previous Work
  • Team Statement of Work
  • Domain Model
  • Product Vision to Include Needs and Features
  • Features List
  • Quality Manager Assessment

Work Item Develop Executive Summary and SOW for
  • Same description as previous iterations.
  • SOW (is really an hours accountability system) is
    likely mis-named. But this is your time
    expended on the various work tiems in this
    project per project worker.
  • These are Word documents and a table (Word or
    Excel). Upload these into RTC as has been
    previously done.
  • Exec Summary must include comments on any
    artifacts changed in previus iterations.

Work Item Develop Domain Model Artifact Domain
  • This is a small but major effort that takes into
    consideration attributes, multiplicities,
    associations, etc. Make the model as complete
    as possible.
  • 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.

Domain Model - continued
  • The Domain Model is an extension of Iteration 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

Work Item Develop Product Vision Artifact
Product Vision
  • 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
  • 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)

More on Needs and Features
  • When we are dealing with needs and features
    we are dealing with reasonably high levels of
    abstraction. Needs are very high level.
    Features are the things that the application
    must do.
  • 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.
  • Features drive the development of the use cases
    our functional requirements, and the development
    of our supplementary specifications
    non-functional requirements.

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)
  • 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

Traceability Needs and Features
  • In the modified Product Vision document, include
    a list of Needs and a list of Features.
  • Include a traceability matrix that maps needs to
    features and conversely.
  • See power point lecture notes on Requirements

Iteration 3 due Saturday, 1 Nov, midnight.
  • Executive Summary
  • Iterate Previous Work
  • Team Statement of Work
  • Traceability Matrices
  • Use Case Index
  • Use Cases including all Façade and Filled (basic
    use cases and those containing happy path
  • Quality Manager Certification

Iteration 3 Work Items - Overview
  • 1. Executive Summary. (Summarize the Iteration).
  • 2. Iterate / Review / upgrade previous artifacts
  • 3. Team Statement of Work (Consolidate team work
    efforts into single
  • Team SOW. Be accurate.)
  • 4. Update Features List in Product Vision to
    cover but not exceed Scope Add comments, if
  • 5. Using updated features and developed use
    cases (ahead) provide Traceability Matrices for
    Needs to Features to Use Cases and vice versa.
    (two matrices required)
  • 6. Provide Use Case Index (Single Table of
    Contents for Use Cases)
  • 7. Provide Use Case Diagrams for each use case
    specification (may be included with the Use Case
    Specification (Narrative).
  • 8. Provide Use Case Specifications one set of
    filled use cases (Use case that includes all
    attributes plus the happy path)
  • 9. Quality Managers certification artifacts are
    reviewed, assure similar quality.

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

Artifact Team Statement of Work
  • You are to include the Statement of Work from my
    web page updated with this Iterations efforts.
  • Include / consolidate 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 prior
    to Saturday, midnight.

Artifact Update Features List within Product
Vision document
  • Update Features list with current knowledge.
    Features List is in your Product Vision.
  • (You will need this information for your
    traceability matrices ahead)

Artifact Develop Two 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

Artifact Use Case Index
  • See examples on my web page.
  • This is a one-pager listing the use cases by
    name, title, date, etc.
  • Each entry should have a short user-story as the
    description of the use case as part of the use
    case entry in this Use Case index.

Artifact 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
  • Not a bad idea, however, to have them all listed
    one after the other here

Artifacts Use Case Specifications
  • The use cases are to be both façade and filled
    use cases.
  • Thus, each use case is to include the basic
    course of events (along with all of the other
    attributes included. No alternatives /
    exceptions need to be included on this iteration)
  • Be aware, the next iteration will have all
    alternatives / exceptions developed

Artifact Quality Mangers Certification
  • Need sign off that the entire team approves of
    the deliverable constituting the third Iteration.
  • Make this a simple Word document with a
    signature. But be certain ALL team members
    review all artifacts for consistency in language
    and uniformity in formats, etc. Entire
    deliverable should flow as if it came from a
    single source.

Iteration 4 due Sunday, 16 November, midnight
  • 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 as usual.
  • 3. QM certification. Ensure ALL review these
    documents. Please note that ALL are responsible.
  • 4. Review / update any traceability matrices. I
    expect that there will be some. Mention this in
    the Exec Summary.
  • 5. Complete Use Cases with all alternatives and
    exceptions. Use Case Diagrams too. Precede this
    with the Use Case Index. This is the major
    effort this time.
  • 6. Initial Data Base Design.
  • 7. Need one team to spend 15 minutes to present
    their deliverable
  • 8. If shown in class

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
  • Of course, the use cases are never totally
    complete. ?

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.

Iteration 5 due 6 December (Saturday) midnight
  • 1. Exec Summary, SOW, QM Certification.
  • 2. Upgrade all Use Cases.
  • 3. Select any single Use Case provide the
    Analysis Classes
  • 4. For this set of Analysis Classes for this Use
    Case, construct an Interaction Diagram (sequence
    or collaboration) for the basic course of events.
  • 5. Initial image of your Interface. (optional)
  • 6. Prepare a Supplementary Specifications
  • All these artifacts need to be in Iteration 5 in
    Team Concert.

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
  • All teams will, upon prioritization of needs by
    our clients (product backlog to be developed),
    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.