Software Engineering II - CEN 6017 Project Deliverables for Spring 2015 1

Software Engineering II - CEN 6017

Project Deliverables for Spring 2015

1

ProjectProject Deliverables for CEN 6017Deliverables 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. More ahead.

4

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 ItemsEach 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 SummaryWork 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.

More later on this topic.

10

Work Item: Sprint Retrospective Frank assessment of an iteration (5-10 minutes. NO

MORE). I will ask for an update each week - MondaysThese 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 due. (Again, only Peer reviews are needed – no Self)

11

Work ItemQuality 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 PlanThe 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 2013All 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 two-three 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 2013Between 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 Map out anticipated Sprints to include allall functionality from functionality from Product Backlog. Ensure all is accommodated.Product Backlog. Ensure all is accommodated. Note that Product Backlog is rather high level, while use case Note that Product Backlog is rather high level, while use case scenarios scenarios (from which the individual Sprints are somewhat (from which the individual Sprints are somewhat refined)refined) are fine are fine grained. If necessary, use the Feature grained. If necessary, use the Feature mappings to use case scenarios to identify the mappings to use case scenarios to identify the activityactivity. You . You will be required to show how each feature you have cited in will be required to show how each feature you have cited in they past they past is planned for in your Product Backlog and Sprint is planned for in your Product Backlog and Sprint Backlogs. Backlogs.

• Equivalently, Equivalently, allall use case scenarios must use case scenarios must tracetrace to the Product to the Product Backlog and to anticipated Sprint BacklogsBacklog and to anticipated Sprint Backlogs• How you plan to clearly provide evidence of this is up to you. How you plan to clearly provide evidence of this is up to you. • EachEach sprint must include a sprint must include a detailed test plandetailed test plan, test data for validation and development of , test data for validation and development of

test suites, retrospective, etc. test suites, retrospective, etc. Note that these will take on increasing level of details as you Note that these will take on increasing level of details as you complete one sprint and approach the next Sprintcomplete one sprint and approach the next Sprint

16

Management PlanningManagement Planning Decide the number and contents of each Sprint needed toDecide the number and contents of each Sprint needed to accommodate the Product Backlog – recognizing it will changeaccommodate the Product Backlog – recognizing it will change .. Decide on development environment for programming suchDecide on development environment for programming such as Eclipse client and Visual Studio client.as Eclipse client and Visual Studio client. Study Team Concert and tutorials on Scrum and Builds, ...Study Team Concert and tutorials on Scrum and Builds, ... Undertake a prototype development build and versioningUndertake a prototype development build and versioning Study Configuration Management and Versioning in RTCStudy Configuration Management and Versioning in RTC

Testing and ValidationTesting and Validation Develop test plan for User Interface from Use CasesDevelop test plan for User Interface from Use Cases Include Validation Criteria for each feature set.Include Validation Criteria for each feature set. Develop Test scenarios and test suites from Use Cases to testDevelop Test scenarios and test suites from Use Cases to test Test Suites must be planned, developed, and archived for allTest Suites must be planned, developed, and archived for all testing including functional and regression testing.testing including functional and regression testing.

The results of this sprint will be presented to the class.The results of this sprint will be presented to the class.

17

Sprint #1 - Thoughts

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

ManagementUse 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

Additional Notes

Clarification on Sprint 1

Product Backlog1. Develop a comprehensive Product Backlog

This can be a simple listAll 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.


Sprint Backlogs2. 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 BacklogNote, 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


Test Plans for Verification4. 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.


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 #2due date: TBD

All that follows will be determined by your Product All that follows will be determined by your Product Backlog and Sprint Backlog.Backlog and Sprint Backlog.

Sprint #2Work Items

Exec Summary, Quality Control statement Statement of Work. Sprint RetrospectiveSelf-Peer Reviews separately submitted via Blackboard

Sprint #2Work 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 #2Work Items

ReleaseNeed 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 #2Work Items

Include any updates on any prototyping or redesign of your database and/or User Interface.

Include any other items you think important.


(more coming)

Exec SummaryStatement of WorkSprint Details (to be determined by team)Quality Control Certification

• 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 #3due 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 #3due date: Tuesday, 5 March


Exec SummaryStatement of WorkSprint Details

to be determined by teamQuality Control Certification







Documents

Software Engineering II - CEN 6017 Project Deliverables for Spring 2015 1