Software Engineering II CEN 6017 Project Deliverables for

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…) 5 Testing and Assessment (huge job done correctly)

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 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 Time. Lines: 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 Time. Lines • • 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.