Project Deliverables

1. ProjectDeliverables 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 WorkItems; 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.

2. Executive Summary • Every iteration will include an Executive Summary. • 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 ahead). • There are several items to be included in the Exec Summary. • More 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 are undertaken using RTC and artifacts for each iteration will be posted to appropriate places in your team’s 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. 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 includeoutputs 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 Saturday, 13 Sep 2014 – Midnight Executive Summary (Team Formation, Project Identification, Roles, Organization of Team), Initial Risk Assessment, Approved Project Description

8. Work Item: Produce Executive SummaryArtifact: Executive Summary (Overview) • 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 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.

9. 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. • 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

10. Work Item: Create Team Roles and Responsibilities Artifact: Role and Backup IdentificationInclude 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; interfacing…) • Testing and Reporting (business analysts; others) • Include in Executive Summary

11. Work Item: Develop Iteration AssessmentArtifact: Iteration AssessmentArtifact: Individual Peer Reviews • 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 email • Neither of these artifacts are to be included in RTC, but they are documents produced as part of this deliverable.

12. Work Item: Develop Risk ListArtifact: 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)

13. Work Item: Develop Approved Project DescriptionArtifact: 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

14. Summary for Iteration 0Rational Team Concert • The following artifacts are to be inserted into RTC: • 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.

15. Iteration #1due 4 Oct (Saturday) Business Modeling (Domain Analysis)

16. Iteration #1 Business ModelingBusiness Domain Analysis Due: Saturday, October 4th • Objectives: • 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;

17. Iteration 1 – Business Modeling and Domain AnalysisOverview 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 Member’s Statement of Work • At the time of this writing, templates are provided. But it is possible we will use templates within RTC.

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

19. Work Item: Develop Statement of WorkArtifact: SOW • You are to include each individual team member’s 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.

20. 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 Requirements • Introduction • Positioning (Problem Statement; Product Position Statement) • Stakeholder and User Descriptions • Stakeholder summary; User summary; user environment; • 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 page.

21. 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 organization’s perspective: • Add or omit major sections that you deem appropriate. But be careful to not miss the intent of this document.

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

23. 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 associations: (What’s 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.)

24. Work Item: Develop Business RulesArtifact: Business Rules Document • 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. See Chapter 8 in the RUP book. • 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 businessrules 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.

25. Work Item: Capture Business RisksArtifact: 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 separate… • 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.

26. Iteration #2due: 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

27. Work Item: Develop Executive Summary and SOW for Team • 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.

28. Work Item: Develop Domain ModelArtifact: Domain Model 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 isn’t. 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.

29. 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 textbook.

30. Work Item: Develop Product VisionArtifact: 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 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)

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

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

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

34. Iteration #3due: 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

35. 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 needed. • 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 Manager’s certification artifacts are reviewed, assure similar quality.

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

37. Artifact: Team Statement of Work • You are to include the Statement of Work from my web page updated with this Iteration’s efforts. • Include / consolidate each individual team member’s 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.

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

39. 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 Leffingwell.

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

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

42. 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…

43. Artifact: Quality Manger’s 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.’

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

45. “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. 

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

47. Iteration#5due: 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 document • All these artifacts need to be in Iteration 5 in Team Concert.

48. That’s 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 (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.