Software Engineering II - CEN 6017
Project Deliverables for Spring 2015
1
Project Deliverables for CEN 6017
 This is an iteration-based project, based on a hybrid approach of
Unified Process and Scrum using Rational Team Concert as our CLM
too.
 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.
 Each Iteration, which we will call Sprint, will consist of a number
of work items that will result in the production of artifacts that must be
planned, produced, tested, validated, and deployed incrementally to our
clients.
2
Introductory Thoughts and Themes
 Agile Methodology: As we discussed last semester, we will
be continuing with an Agile-hybrid approach integrating
elements of the Unified Process and Agile – Scrum in
particular within the context of Team Concert, RTC.
 Scrum. Since we will be using Scrum as our management
approach, we will talk in terms of Sprints, Product
Backlog, burn-down charts, Sprint-backlogs, along with
Scrum characteristics such as self-organizing, incremental
and iterative development, delivering increments of real,
business value each increment and more.
 Planning: The continuation of our projects will entail levels
of planning starting with a well defined sprint (the one to
be undertaken) following by increasing lesser definition
and coarser granularity for subsequent springs, but all in
concert with an overall “Development Plan.”
Rational Team Concert

Rational Team Concert (RTC) will continue to be the tool of choice for
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.

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.)

Using facilities within RTC for employing Scrum will require a good bit
of work to learn and effectively use the guidance and prescriptive features
within RTC. Project Management of the Sprints and all that are a part of
Scrum are located in Change Management within RTC.
4 More ahead.
Team Roles and Responsibilities
(suggested 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)
 Software
Architect (should be your strongest
designer/programmer)
 Application Designers (Modelers; architects; UI
specialist)
 Application
Programmers (API / IDE / programmers)
 Database Specialists (database designers; interfacing…)
 Testing and Assessment (huge job done correctly)
5
Work Items
 Each
sprint will consist of work items undertaken as part
of the current sprint backlog.
 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. Many will be executable code items, test
suites, assessment results, and more.
 Using
RTC for this semester will be a change of pace, and
the Scrum pages in RTC must be used to the fullest.
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
Work Item: Executive Summary

Each Sprint will include an artifact that is the Executive
Summary. It should include:

Project Title

Standard contents (see previous generic description)
Project lead 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.
8
Work Item: Statement of Work
 Each
Sprint is to contain a work item delineating the
individual team member’s Statement of Work.

This must be posted in with the work items for the
specific sprint.
 Additionally,
individual Peer Reviews must be
submitted no later than class time on the date on which
the Sprints are due/presented.
 For
this semester, you may only complete the second
part (on your peers) if you wish.
9
Work Item: The Sprint

Those items from the sprint backlog (features, scenarios, etc.)
implemented within a specific sprint will be included and fully
discussed here. Include an Activity Diagram to document flow.

There will be likely multiple individual work-item descriptions to be
accommodated.

Burn-down chart, sprint retrospectives, etc. must be included

Assessment to include all details regarding the good, bad, and ugly
must be included.
All testing (various kinds) and validation results must be included.
10
More later on this topic.

Work Item: Sprint Retrospective
 Frank
assessment of an iteration (5-10 minutes. NO
MORE). I will ask for an update each week - Mondays
 These will be presented IN CLASS by one or more
team members.
 The sprint must be assessed as to what was / was not
accomplished, work items produced, work items
unresolved and disposition of these.
 This is the ‘sprint retrospective’ and should be
developed by your scrum master.
 This will be included within RTC.
 Individual
Peer Reviews must be submitted no later
than the night prior to the date on which the Sprint is
11 – no Self)
due. (Again, only Peer reviews are needed
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) Signature
 _____ Team Leader’s (TL) Signature
 Comments optional.

12
Sprint #1- Organization and Planning
due: 26 Jan 2013 Software Development Plan
The main purpose of this sprint is to develop your development plan
using Scrum.
1. Clearly develop your Product Backlog (and initial Sprint planning)
2. Using what we have studied about Scrum, you need to tentatively
divide up the client requirements as found and prioritized in the
Product Backlog into a series of Sprints. Recognizing that these
WILL change, you need to be careful what you plan. Your first
Sprint is the most important and must be carefully defined and well
understood before embarking on the work items. These are totally
under your control!
3. Exploiting the features of Team Concert is a major task, and I
recommend two of you undertake all this so that we can take
advantage of traceability, burn-down charts, tracking, etc. – some
of the major advantages of this tool. I will provide more guidance
later on this topic.
13
Sprint #1- Organization and Planning
due: 26 Jan 2013
All this planning will take a major effort and underpin all your activities this
semester. So it is absolutely essential to jump on this.
Because this semester is more about development rather than requirements, much
time will be spent doing analysis, design, programming, and implementation
incrementally. So your planning of your sprints is vital.
For this deliverable (Sprint 1) , I am after a detailed report – it can be totally Word, if
you wish, outlining exactly how you plan to go ahead to accommodate your
development.
Tables, charts, graphs, might help but are not essential.
“Who” will serve in what “role?” Potential Sprints (we should plan on every twothree weeks), specific deliverables, use of Team Concert (I want presentations
using this tool), and more. So this iteration is all about careful and detailed
planning. Again, using Team Concert will be a major effort. Two of the three
teams did not use it much. So you may need to get with team 3 or 4.
14
Sprint #1- Organization and Planning
due: 26 Jan 2013
Between now and the deliverable date, please come to see me or send me
intermediate planning documents for my review and comment.
Drop dead date is 26 Jan, but please do not wait until that date to run your
plans by me, okay? Your plans need to be solid before then.
As it turns out, I will be out of state on 26 Jan for the week (I will be in
Washington DC). But my flight does not leave until the early afternoon.
Thus I would like to meet with each team (or most of the team) Monday
morning, 26 Jan or Thursday / Friday of the preceding week to discuss
your Development Plan.
Please schedule a meeting with me, and I am more than willing to discuss all
these things ahead of time.
I will develop a narrated Power Point presentation for some of the slides on
my web page too, so that you are not disappointed. (LOL)
15
Sprint #1 – Software Development Plans (Sprints)


•
•
•
Map out anticipated Sprints to include all functionality from
Product Backlog. Ensure all is accommodated.
Note that Product Backlog is rather high level, while use case
scenarios (from which the individual Sprints are somewhat
refined) are fine grained. If necessary, use the Feature
mappings to use case scenarios to identify the activity. You
will be required to show how each feature you have cited in
they past is planned for in your Product Backlog and Sprint
Backlogs.
Equivalently, all use case scenarios must trace to the Product
Backlog and to anticipated Sprint Backlogs
How you plan to clearly provide evidence of this is up to you.
Each sprint must include a detailed test plan, test data for validation
and development of test suites, retrospective, etc. Note that these
will take on increasing level of details as you complete one sprint
and approach the next Sprint
16
Sprint #1 - Thoughts
Management Planning

Decide the number and contents of each Sprint needed to
accommodate the Product Backlog – recognizing it will change.

Decide on development environment for programming such
as Eclipse client and Visual Studio client.

Study Team Concert and tutorials on Scrum and Builds, ...

Undertake a prototype development build and versioning

Study Configuration Management and Versioning in RTC

Testing and Validation

Develop test plan for User Interface from Use Cases
Include Validation Criteria for each feature set.

Develop Test scenarios and test suites from Use Cases to test

Test Suites must be planned, developed, and archived for all
testing including functional and regression testing.

The results of this sprint will be presented to the class.
17
Additional Notes
Architectural Design
Decide and design User Interface with clients
Design database and refactor database
Product Backlog from clients prioritized Features
Develop anticipated Sprints and next sprint backlog
Develop Test Plan and Test Suites from Use Cases
Activity Diagam
Management
Use Team Concert for managing Scrum (see tutorials)
Configuration management toos and versioning control
Builds and procedures to use RTC
Include product backlog from Features in RTC
Include Sprint Backlogs in RTC
Burn down list included in RTC
How to do Builds etc.
18
Clarification on Sprint 1
Product Backlog
1. Develop a comprehensive Product Backlog
This can be a simple list
All functionality should be derived from the use cases.
Elements within the Backlog should be in relatively prioritized
order.
Elements should be in verb…object format, as in Generate
User List, etc.
Elements are really features / functionality cited in the use
cases.
Use cases drive all of this.
Clarification on Sprint 1
Sprint Backlogs
2. From the Product Backlog develop the activities for your
Sprint Backlogs starting with Sprint 2.
3. You will have a number of Sprints.
The number of sprints is up to you. Front-end the difficult
activities!
Each element in a Sprint should map back to an element in the
Product Backlog
Note, these elements, activities, use case scenarios all come
from the use cases.
The sum of the elements in all Sprints should equal the number
of activities in the Product Backlog
Clarification on Sprint 1
Test Plans for Verification
4. Once each Sprint is planned, there should be a test plan associated with each
activity within each Sprint. This test plan should include a name, number,
objective, anticipated results, and observations. There should be a short
retrospective for each test and disposition, such as part of the test may need to be
redone in a subsequent sprint, etc.
5. All tests come from the use case dialogs (use case narratives). The things that you
cite that are to be done within a use case need to be verified. These are the tests. Thus
tests should map back to specific use cases.
Clarification on Sprint 1
Using Team Concert for Neat Features – Burn-down charts, etc.
To get the real value of Team Concert, its facilities must be used. But Sprint 1 does not
need to use much. The Product Backlog, etc. must ultimately go into Team
Concert. All Use Cases must be ported into Team Concert to reap the benefits from
this tool.
To assist in this effort, Ramsey Crowe will be sending you some directions and screen
shots that his team undertook in getting the Use Cases into Team Concert. Then, on
2 Feb, he will present via demonstration exactly how to do this (in class). For
Sprint 2 and after, your use cases need to be ported into Team Concert.
Sprint #2
due date: TBD
All that follows will be determined by your Product
Backlog and Sprint Backlog.
Sprint #2
Work Items
Exec Summary,
Quality Control statement
Statement of Work. Sprint Retrospective
Self-Peer Reviews separately submitted via Blackboard
Sprint #2
Work Items – Sprint Details
Under Change Management for your Project,
Please include
Product Backlog under Current Plans.
this includes all features, story points, priority…
Sprint Backlog w/story points and their individual
tasks allocated to specific Sprints
Release Backlog - lists each Sprint / and date with
story points and tasks for that specific sprint.
Sprint #2
Work Items
Release
Need data for Release Burndown, Team Velocity and
Story points / iteration
Current Sprint:
try to track progress
Project Details:
Under Plans, include
Exec Summary, SOW, etc.
Under TimeLines: map out the specific sprints
including stories to be accommodated within each
sprint.
Sprint #2
Work Items
Include any updates on any prototyping or redesign of
your database and/or User Interface.
Include any other items you think important.
Sprint #3
due date: TBD
(more coming)
Exec Summary
Statement of Work
Sprint Details (to be determined by team)
Quality Control Certification
Sprint #3
due date: Tuesday, 5 March
• Sprint must include specific user stories / task forecast,
or scenarios from use cases for this sprint.
• Each user story / scenario must include corresponding
acceptance criteria.
•
•
•
•
•
•
For user stories, acceptance criteria must map acceptance
criteria to stores/tasks
For use case scenarios, test plan must map to scenario.
Develop test plan for all stories / scenarios in sprint
Include burn-down chart on RTC
Use Traceability Matrix for mappings above.
Update Release
Sprint #3
due date: Tuesday, 5 March
•
•
•
•
Update Product Backlog
Update Sprint Backlog
Update Release Backlog
Update TimeLines
•
•
•
•
Include Executive Summary
Include Statement of Work
Include Quality Manager’s Statement
Send Individual Peer and Self Reviews
•
Please include any key correspondence from our clients
as to how they are going to access / test your releases.
Sprint #4
due date: TBD
Exec Summary
Statement of Work
Sprint Details
to be determined by team
Quality Control Certification
Sprint #5
due date: TBD
Exec Summary
Statement of Work
Sprint Details
to be determined by team
Quality Control Certification
Sprint #6
due date: TBD
Exec Summary
Statement of Work
Sprint Details
to be determined by team
Quality Control Certification