Project Deliverables

1. ProjectDeliverables Deliverable 5 Posted (revised 11/12/2007) Version Numbers will reflect added Deliverable numbers.

2. Overview of Guidance • I shall try to upgrade / refine guidance for each deliverable as we progress. • Please view this file often as it will change. • Suggestions for clarity and/or consistency are always welcome.

3. Format of Deliverables • All Deliverables will be via CD. • Outside: Surface of CD is to clearly indicate your course number and the team number, as CGS 4308 - Team 1 or CIS 4327 – Team 1. Also include the project title. • Inside: Each deliverable will be in a separate folder on the same CD, so when I access the CD, all I should see are individual folders with labels such as Deliverable n, as in Deliverable 4. • This way, I can also see enhancements to previous deliverables.

4. Contents of Folder • Each Folder (i.e., Deliverable) is to contain • Management Folder: • a number of Word files discussed ahead • Artifacts Folder • Contents discussed ahead.

5. Management Folder Documents (1 of 3) • 1. Team Num file • In this file, you are to simply (may be a single Word file): • List the names of the team members • Indicate who is team leader with phone number. • Indicate who is the software quality analyst and phone • List individual email accounts. • 2. Iteration Plan (Include for CIS second semester deliverables) • Note that the Iteration Plan will change for each deliverable, that is, it will be refined and ‘extended.’ Each successive deliverable will contain a ‘revised’ Iteration Plan.

6. Management Folder Documents (2 of 3) • 3. Executive Summary • Single page document; Summarizes the contents of this folder. • What ‘activities’ were undertaken • What ‘artifacts’ were changed and rationale • Note: revising artifacts is the norm in an iterative approach to software development. • What new ‘artifacts’ were produced •  Must include signatures of EACH team member that he/she has reviewed and has ‘bought off’ on the contents of this deliverable. (signatures may be virtual) • If you have not read and personally reviewed the contents of the deliverable, do not sign this form!

7. Management Folder Documents (3 of 3) • 4. Team Activities: • Team Software Process (TSP), and • Personal Software Process (PSP) Forms • 5. Software Quality Analyst Report • This will address in narrative or graphic form (your choice) the status of the project with respect to identifying and tracing requirements to date as well as efforts undertaken by you regarding testing and verification (we will discuss).

8. Artifacts Folder (1 of 2) • All developed artifacts will be found here. Sometimes the artifacts will be models; other times, they will be documents. Artifacts are sample items produced by team members as a result of undertaking specific activities. • Word documents: A project Vision Document; the Risks List; the Business Rules document, etc. • Artifact likely developed in Rational Rose: Your use-case diagrams, actors, etc.

9. Artifacts Folder (2 of 2) • Sample artifacts developed in Rose (continued): • In general, specific components of deliverables should be found here, and a number of these should be in their own subfolders, such as the user interface prototype (linked to via Rose / Requisite Pro (optional)), Use Case diagrams, Use Case Narrative, Analysis Model, Sequence Diagrams, Communications Diagrams, architectural models, etc. • We will discuss in class for each deliverable.

10. Guidance on the Rose Browser • Use Case Diagrams in Use Case Folder within Use Case Model in Rose • Capture Use Cases in separate subfolders in the Use Case folder within Use Case Model in Rose (see the Rose Browser). • Capture all Actors in folder within Use Case Model in Rose

11. Grammar and Wording • 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. • EACH portion of EACH deliverable should be reviewed and ‘signed off’ by EACH team member. (as stated) • This is a TEAM responsibility!! • On the provided templates, there is room for signoff by the team / team members. Use this for verification…

12. Deliverable #1 Business Modeling (Domain Analysis)

13. Deliverable #1 Business ModelingBusiness Domain Analysis Due: Wednesday, September 19th, 2007start of class. • Purpose: • 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;

14. Deliverable 1 – Business ModelDomain AnalysisDeliverable Artifacts • Business Vision Document - a text document. • Business Use Case Model – captured in a Rational Rose model • Business Glossary - text • Business Rules – text • Business Risk List - text • (Domain Model - model in Rational Rose – will accommodated in Deliverable #2.) • This is a hefty assignment. Start early!!

15. Deliverable #1: Business Vision Document (1 of 2) • Use the appropriate forms available at: • RUP document templates are located at the site http://jdbv.sourceforge.net/RUP.html.  See also my web page. • This captures (Word document) the purpose of the business enterprise. • What services are they providing? • What are they all about? • Who are the customers? • What are the goals of the business? • Primary stakeholders?? • This is NOT a product vision document (the product you will develop). This is about the business, enterprise, environment.)

16. Business Vision Document (2 of 2) • You may use the Vision Template (see web page) but you must MODIFY it so that it does NOT address a project; rather, it will capture the vision of the enterprise itself. • Eliminate section 2. Elaborate on section 1. In Stakeholders, address those interests NOT from a project perspective but from an organization’s perspective: customers, users, etc. There is no Product Overview But your business vision document should address what the business is all about. Add major sections that you deem appropriate. • This is a template. It offers organization, but it need to be rigidly adhered to.

17. The Business Use Case Model (2 of 2) • When logging onto Rose, be sure to select RUP icon from the initial window. • Be also certain to notice the tool mentors – when you select a folder in the Rose Browser, a description often appears with invaluable information. • The Business Use Case Model must be developed in the Use Case View (see last slide) • This is a single model of the key business processes of the organization.

18. Deliverable #1: Business Glossary (1 of 2) • Definitions of important terms 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!

19. Deliverable #1: Business Glossary (1 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 methods (operations here) • This, however, is for the next deliverable.)

20. Deliverable #1: The Business Rules • Use the appropriate forms available at: • RUP document templates are located at the site http://jdbv.sourceforge.net/RUP.html.  See also my web page. • The link for the Business Rules template is incorrect (points to the Business Modeling Guidelines template), so there is another link to point to the Business Rules format. • See examples on my web page. These are merely samples. • Be careful: The samples on my web page are Rules for an application that will be developed (later). Your Rules are simply for the organization itself - the way it does business; guiding principles. It has no relationship (at this time) to an application to be developed. • Business Rules are policy declarations or conditions or guidelines that must be satisfied in running the business.

21. Deliverable #1: The Business Risks List • Very general at this stage. • What are some of the risks that the organization must be constantly assessing: • e.g. market share, technology awareness, new statutes from Washington D.C., trends in the industry; demographics; environmental considerations, maintaining top notch software developers, keeping developers current; training; give this some thought…. • Again, this is at the organizational level. • That’s it! Have fun!

22. Deliverable #2due: Wednesday, Oct 3rd – midnight Iterate Previous Work Domain Model The Product Vision Document Statement of Work

23. New Directions • For Deliverable 2 and thereafter, your subfolders to the Deliverable n folder are to include: • 1. Artifacts • 2. Management • 3. Deliverable (n-1) folder (I returned to you) • 4. Revisited Deliverable (n-1) folder • Be certain your Executive Summary addresses all items in these folders • You may send me a zip file (e.g. UgTeam3.Deliverable’n’) via Outlook and also send the same folder to me using Digital Dropbox

24. Deliverable#2 – Artifacts - Overview • 1. Iterate / Review / upgrade previous artifacts • based on evaluation of your deliverable. Your changes should be annotated in the Executive Summary. Business Use Case Model, Business Use Cases and Business Actors – Modeled, Business Vision document – text, Business Glossary – text; Business Risks Lists; Business Rules - text • 2. Build a Domain Model (precursor activity to Use Case development) • Is an essential activity to facilitate good use case development that contains glossary items and objects from the problem space (domain). This is a graphical model of Business Entities (enterprise as a whole). But these entities will become useful for your application. (major artifact this deliverable; Requires Rose) • 3. Build a Product Vision Document • Will include User Needs and Features This Vision document addresses the ‘needs’ of the client for your application. SQA people: brief your team on Needs, Features, etc., referenced in the article you are responsible for. (See ahead)> • 4. Develop a Statement of Work – (Team Leader Log may be substituted) • assigning responsibilities to different roles to be accommodated on the team. This text document should be developed by the team leader in concert with individuals. Team leader must provide direction and guidance. All tasks and sub-taskids should be clearly delineated. Add column to the Team Leader Log reflecting individual assignments to each task – as appropriate. You may include a ‘primary’ and a ‘backup’ if you wish. This artifact is not to be contained in the Management Folder. Rather, include it in the Artifacts Folder as the fourth item.

25. Deliverable #2: Domain Model 2. Domain Model – The Domain Model should be captured as a separate folder within the Logical View in your Rose Browser. • This is a major effort that takes into consideration attributes, multiplicities, associations, etc. • 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. Notice it is found in the Logical View (as it should). • Study the Rose descriptions / options too in the specification windows associated with the business entities (classes)

26. Domain Model - continued • The Domain Model is an extension of Deliverable 1. It deals with the enterprise / organization. • Domain Model 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 8 on the Domain Model and the textbook. See also Tom Morgan’s slides.

27. Deliverable #2: Product Vision Document • 3. This represents the vision for the application you will be developing. • Use the template provided. • You must take the link to the RUP documents and access the Project Management Templates: Product Vision Document. • You may transfer some of the information from the Business Vision Document to this Product Vision Document. • You are to add the Problem Statements (section 2.2) and all the other items dealing with the Stakeholder and User Profiles and Stakeholder and User Needs. These are customers (now) of your application. • 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 SQA function will prepare a second Traceability Matrix that maps Features (identified earlier) back to Needs (here). So the SQA will have two matrices prepared. (See sample article for guidance)

28. More on Needs and Features • When we are dealing with ‘needs’ and ‘features’ we are dealing with reasonably high levels of abstraction. • But 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. • The Features drive the development of the use cases – our functional requirements, and the development of our supplementary specifications – our non-functional requirements.

29. More on Sample Features • Features are not behavioral (like the Use Cases). 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.

30. Deliverable #2: Statement of Work • 4. Statement of Work – developed by Team Leader. Coordinate with team members. • May take on this is a bit different than the Use Case Book. It should be a Word document. See textbook and/or templates for format • What is your team plan? • Meetings/ (see forms on web page) • Who does what (that is assign roles)? • What are the responsibilities that must be fulfilled by each role? (use ‘tasks.’) • What is your plan? (See textbook) • This short document should appear in the Artifacts Folder and should include assignments by task by team member and the particulars.

31. Deliverable #2: Statement of Work • Lastly, • Only turn in (hard copy) your Peer Review. (For deliverable 2) please save these for me until I return to class on Oct 15th. Turn them in to me then. Please do NOT email them to me. • Team leaders should meet with me starting the day after the deliverable is due (see office hours) (For Deliverable 2, please start to see me on Oct 16th). You may simply drop by.

32. Deliverable #3Revisiting (Iterating) Previous Deliverables Use Case - Façade Iteration and Initial User Interface Prototype due: Monday 10/22 Start of Class

33. Use Case - Façade Iteration Initial User Interface Prototype due: Monday 10/22 • 1. Management Folder: Executive Summary (overviews new artifacts with brief discussion on ALL changes/revisions to existing artifacts, such as the revised Product Vision, Domain Model, etc. as required. Include other items in this folder as customary. Revisit the Business Case (Deliverables 1 and 2) including artifacts listed below and update them. (Risks Lists; Business Rules; especially the Domain Model; Statement of Work, etc.) • 2. Iterate Previous Deliverables Folders. In addition to the Management and Artifacts folders in Deliverable 3, include (as done in deliverable 2) a folder for Deliverable2 plus a folder of Deliverable2 Revisited. Cite changes undertaken in Deliverable 2 within the ExecutiveSummary for Deliverable 3. Include revised artifacts in revisited folder. • 3. Artifacts Folder (main deliverables: façade use-cases and initial interface prototype) • Façade Use-Cases. Include a use-case index (numbered) for Use Cases included in this folder. (Discussed in class and via slides. See student example link) • Use Case Index is to contain a number, Use Case name, short description, and other high level items you consider important. Construct this in tabular form using a table in Word. See power point slides for detailed attributes needed. (Artifacts Folder) See sample Use Case Index on my web page. • Façade Use-Cases should subscribe to the template found in lecture slides and student examples. Essential undertaking. • Initial Interface Prototype. (discussed ahead).

34. Guidance on Façade Iteration • 1. Develop an Overall Use Case Model (all application Use Cases and Actors). (System Level Graphical Use-Case Model) • 2. Develop Façade Use Case Descriptions and associated Use Case Diagrams for each Use Case cited in the System Level Use-Case Model. Use template in notes. Develop Façade Use Cases using the Kulak and Guiney book. Again, see power point lectures for required attributes. See examples of ‘reasonable’ student Use Cases examples posted. • Use Rose (Use Case View) for your System Level use-case model and all of your individual use-case diagrams (one per use-case). Link the Use Case Specification text (that is, the use-cases) into Rose and ensure these descriptions are on the CD you turn in for grading. (More to be discussed: You may need to use Requisite Pro. • Additional information: Visual Modeling book and Rose Basics (see power point lecture slides for examples on including your Use Cases in your Rose Model in the Use Case View.)

35. More Guidance on: Facade Iteration • Remember that the Façade iteration names the use case, identifies actors, provides a short description, frequently includes pre- and post conditions, triggers, etc. But it does NOT include the anydetailed actor-system interactions. • See lecture notes for required attributes. • Include your single System-level Use Case Model in the Use Case View (in Rose) in the folder provided by Rose. Note: this is NOT the Business Use Case Model, which has been completed; moreso, the icons are different for the actors and use cases. Be sure to note these differences.

36. Guidance on User Interface Prototype • Develop User Interface Prototype needed for showing potential application interface and verification of requirements capture!!! • Iterate this as needed. (Should be done in conjunction with the Façade Use Case and will (together with Domain Model) greatly assist you for Deliverable #4, your full-blown Use Case Descriptions with alternate and exception paths. • Prototyping Tools. You may use any prototyping tool you wish: VB, Javascript, HTML, etc. Your prototype may include storyboarding and other links you might feel appropriate. • Most teams use static html; some use Front Page; some use Javascript, etc. • To accompany the Façade Use Cases, user interface prototype needs to be complete. Remember (more lectures ahead) the interface represents the application! • Examples of initial user interface prototypes - my web page. • See also (ahead) lecture slides on User Interface Design • Read the textbook chapters as well – very carefully.

37. Deliverable #4Full Use Cases Model & Activity Diagramsdue: 11/14 (Wednesday) – Start of Class • ManagementFolder: Executive Summary, Team and Individual Logs, Team Num File, SQA Report as usual, and the Statement of Work (SOW) • ArtifactsFolder: • 1. Focused Use Case Descriptions and associated Use Case Diagrams for each Use Case. • Use Rose (Use Case View) and Requisite Pro* Use Kulak and Guiney book (Use Cases); Visual Modeling book and Rose Basics (power point slides for examples.) *CEN 6016 Students only • 2. Activity Diagrams: • Each Use Case is to be accompanied by an Activity Diagram that indicates flow for all paths in the Use Case • 3. TraceabilityMatrices (forward and backward) features  Use Cases • Revisit Deliverable 3Folder. Document artifacts changed. Include (name) any changes to Deliverable 3 artifacts in Deliverable 4 Executive Summary. Then, of course, include these changes in Deliverable3Revisited folder. • Your Use Case Diagrams for individual use-cases) will likely be supplemented with Included or Extended Use Cases, as appropriate. Redo your Use Case Model (Overall) for the Application. This is the System Use Case Model. • Be certain also to view the new sample SOW link on my web page. This is a good template and contains guidance on the individuallogs as well. (Individual logs may be included in a single folder in the Management Folder, if desired).

38. Guidance on Deliverable #4: ‘Complete’ Use Case Model Executive Summary – as usual; All on CD. • Complete Use Case Model and Use Case Diagrams for each Use Case – This is a major assignment. Consider alternative, exception flows, and ‘sub-flows’, using extension points as appropriate. • Reflect any use cases you feel are ‘included’ or ‘extending.’ • Activity Diagrams – one per Use Case (must include all alternate paths) (Include as package in Rose Model) • Put Use Cases into groups – packages should include use cases that ‘seem’ to go together functionally, like the GUI or those that address specific business activities. • (These will help in our architecture – as these will become likely subsystems). •  Iterate on the Use Case Model and/or your User Interface Prototype (and any other documents) from Deliverable #3 as appropriate Document that you have changed this and other artifacts in your Deliverable4 Executive Summary.

39. Guidance on Deliverable #4: ‘Complete’ Use Case Model • Allocate functional requirements to use cases via the stories of interchange. (and domain objects) This is a painstaking and long task! It will underpin your entire design. Spend time here!!!! Recognize that Use Cases are NOT functional requirements; rather, they are stories of actor-application interactions which contain the required functionality. • All customer functionality should be accounted for here. Be certain to use your Domain Model and italicize or bold all references to entities in the domain model or glossary found in your use-case specification. • Ensure everything the customer desires is accounted for!

40. Keep the alternatives /exceptions WITH the use case. Subflows, if used, should be included with the use case and not made separate. See examples on web page. • Use the User-Interface to ensure all functionality is captured. One should be able to read a use-case and see how to test the use-case flow of events via the interface prototype. • Develop Activity Diagrams – one per Use Case – that captures all paths (scenarios) in a Use Case. See Visual Modeling text for examples and use Rose. • Activity Diagrams should be placed in the Use Case View under Use Case Models in a Folder entitled Activity Diagrams • Traceability Matrices – add to Needs to Features and Features to Needs. This deliverable includes Features to Use Cases and Use Cases back to Features. • You have plenty of time. But don’t wait until next week to start. • When I ‘open’ your CD, I should see four folders; Deliverable 1, Deliverable 2, …, Deliverable 4. Please use these names. Thnx.

41. Deliverable 5due: 12/05/2007 start of class • Key Components • 1. Traditional Management documents (SOW, SQA report, Exec Summary, etc.) • 2. Revisit previous deliverables • 3. The Analysis Model • 4. Interaction Diagrams (actually part of the Analysis Model) • 5. Non-functional considerations

42. Overall Guidance on Deliverable 5 • Management documents: the usual. Don’t forget hard copies of peer reviews to be brought to class. This is important. • When I bring up your CD, I should see five folders named Deliverable 1 … Deliverable 5. Within deliverable 5, I should see a Revisit Deliverable 4 folder, a Management Folder, and an Artifacts Folder that contains the up to date Rose Model (containing the analysis model artifacts including the interaction diagrams), and a Word document capturing the non-functional requirements. • Please ensure that your Rose Model distributes these analysis components to appropriate folders in the browser.

43. Deliverable #5 – Analysis Model • Contains communicating boundary, control, entity objects with named associations etc. •  Will flow from your use case specifications and your initial user interface prototype • Supports Interaction Modeling and and your class models • Sources: Use your prototype (boundary) again, domain model (entities), and use case specifications (control) in earnest. These are not enough, but will help. See also your Vision Document. • See Visual ModelingBook; RUP; Logical View on Rose

44. Guidance on Deliverable #5 Analysis Model • Include boundary classes together, control classes together, and entity classes together all without associations to other classes. (a one-page drawing) Merely separate the classes from each other. This should partition all the classes by type. Include all attributes / methods with each class, but no connectivity. • Follow this with a fully ‘connected’ model – for each use case. Use those analysis classes appropriate to the use case and associate the classes. • Be sure to study textbook and lectures on boundary, control, and entity models • Class structure may be realized with the standard stereotyped classes or the RUP icons • These are to be included in your Rose browser. Create folders in the browser as you need them.

45. Guidance on Deliverable #5 Analysis Model • Remember, the validity of the model is simply determined: can one look at any path through a use case (scenario) and see where/which objects will accommodate all the functionality captured in this scenario? Can the functionality be traced (with your finger...) through the objects as you read through the path description? • Each developer should be responsible for his/her own traceability; The SQA person should inspect overall traceability, but individual traceability is the author’s. • This is the check to make! VerifyTraceability!!! • Cite as many attributes and methods (responsibilities) as possible in the respective class-names – boundary, control, and entity. • Include associations, dependencies, etc. among the classes – as much as practical in the fully-connected model.

46. Guidance on Deliverable #5 Analysis Model • For boundary to control classes, a simple association line is sufficient, because it cannot be determined what method in control class will be invoked from the boundary class unless we consider a specific scenario. Better, though, is a series of boundary classes constituting the interface. See lecture slides for example. • Associations among entity classes should have the multiplicities, aggregations, dependencies, etc. cited, as usual. They are appropriate here and may come from your domain model, which will VERY likely need upgrading after/during your exercise. • BE CERTAIN to look at the slides on my web site which ‘supplement’ your readings! There are many examples of the format you will need for the classes.

47. Guidance on Interaction Diagrams • For each use case, you are to develop a sequence diagram for the basic course of events only. (You need NOT develop sequence diagrams for the other scenarios (alternative and exception scenarios). Only one interaction diagram per use-case (at this point). • These will show boundary, control, and entity classes along with appropriate actors. • Toggle using the F5 key and include these in your Rose model. • Recommend that the static classes (boundary, control, and entity classes) be devleoped first so that the methods these classes include are available to the dynamic model (sequence diagram), which sequences the issuing of method calls. • Ensure that these are developed within your Rose browser in the appropriate folder.

48. Guidance on Non-Functional Requirements • See Use Case Textbook for ‘tables’ • Thoughts: • Small systems: • functionality; performance • Large systems: • Portability; Maintainability; Scalability; Reliability; Security • How about: Persistence? • Will discuss more in class; Remember the Supplementary Specifications for Non-Functional Requirements. • The Supplementary Specifications Document should be a Word document containing the non-functional ‘tables.’ These, as stated, are to be included in the Artifacts folder via a single icon.

49. Supplemental • Please ensure that all italicized or bolded items in your use-case specifications are hot (link to the domain model or glossary) Ensure all hot links are relative so that they are accessible on my machine. • This ‘assumes’ key abstractions are, in fact, bolded or italicized • See slide 30-32 in lecture 22 – Non-functional Requirements • The team should do the tracing – as a unit, please. • Evidence of this tracing activity is to be included in the SQA report, which should assert that all team members participated in this tracing exercise (It is essential for follow- on activities). . • It would be nice (but not required) to develop your own checklist to verify that your team has indeed gone through these checklist items. • Ensure your sequence diagrams include the use-case flow of events as a left column (we will discuss in class).

50. Second Semester Deliverables(anticipated) • Deliverable #6 – User Interface Design • Deliverable #7 – Layered Architectural Design • Deliverable #8 – Detailed Design - Iteration Planning and Use Case Realizations – Context Diagrams only. • Deliverable #9 – Subsystem Design – Interaction Diagrams (both) and VOPC diagrams. • Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration • Deliverable #11 – Final Deliverable: Complete Implementation Model and Demonstration including client testing. Clients will be simulated – other teams.