1. Project Deliverables Version 9: 04/03/06 Note: This document contains the deliverables for a two semester course. It is a living document and changes every now and then. Stay tuned! For CEN 6017: Go to Slide 53

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 CEN 6016 - 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.

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 Team Num file, with file name as follows (for example): Team1.Deliverablen.Date.mm.dd.yy 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. Iteration Plan (Include for 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 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. If you have not read and personally reviewed the contents of the deliverable, do not sign this form!

7. Management Folder Documents Team Activities: Team Software Process (TSP), and Personal Software Process (PSP) Forms 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.

8. Artifacts Folder All developed artifacts will be found here. Sometimes the artifacts will be models; other times, they will be documents. Artifacts are items produced by team members as a result of undertaking specific activities. Sample artifacts – likely Word documents: A project Vision Document; the Risks List; the Business Rules document, etc. Sample artifact likely developed in Rose: Your Use Case Folders within your Rose Model.

9. Artifacts Folder (continued) 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), Use Case diagrams, Use Case Narratives, Analysis Model, Sequence 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). But Use Case Narratives are in Requisite Pro 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. EACH portion of EACH deliverable should be reviewed and ‘signed off’ by EACH team member. (as stated) Poor adherence to this ‘standard’ will impact EACH team member. So, check out your text BEFORE you submit it to me. 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 Modeling Business Domain Analysis Due: Monday 10/3 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 Model Domain Analysis Deliverable 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 accommodate in Deliverable #2.

15. Deliverable #1: Business Vision Document 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??

16. Business Vision Document (more) 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.

17. Deliverable #1: Business Use Case Model Simple in structure. See pp 151-152 in the RUP. You only need show the Model (with actor and business use case icon) (top part of figure 8.5) You do NOT have to display the Use Case specification. Each use case is identified and actors who interact with this and each business use case. A Business Use Case Diagram (the top part of figure 8-5) is developed in verb…object format and captured in Rose. All major use cases and actors should be captured in this business model. See link to sample on my web page. Note: It’s location is in the Use Case View, Business Use Case Model (in the Rational Rose Browser)

18. The Business Use Case Model 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.

19. Deliverable #1: Business Glossary 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, ….

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. http://jdbv.sourceforge.net/RUP.html 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. There are also two former student examples on my web page to guide you. (Note: I am not disclosing their grades, or how I graded them.) These are merely samples. Be careful: The samples on my web page are Rules for an application that will be developed. 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.

22. Deliverable #2 Domain Model The Product Vision Document Statement of Work

23. Deliverable #2 – Artifacts Due: Monday, Oct 17th 1. 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). 2. Build a Product Vision Document Will include User Needs and Features 3. Develop a Statement of Work – assigning responsibilities to different roles to be accommodated on the team. 4. Traceability Matrix Review / upgrade previous artifacts. Business Use Case Model, Use Cases and Actors - Modeled Business Vision document – text, Business Glossary - text Business Rules - text

24. Deliverable #2: Domain Model 1. Domain Model – The Domain Model should be captured as a separate folder under 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 – 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).

25. Domain Model - continued A continuation of Domain Analysis… The Domain Model is an extension of Deliverable 1. It deals with the organization. Domain Model is essential to understanding the environment within which the application to be developed will function. It is sometimes the only item from the Business Case. But it is an essential artifact.  See Lecture 8 on the Domain Model.

26. Deliverable #2: Product Vision Document This represents the vision for the application you will be developing. This essential artifact is called the Product Vision Document. 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 much 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. You need not include the Product Overview section. 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 lecture materials. (Software Quality Analyst on your team will learn/use Requisite Pro. Take the Requisite Pro Quick Tour…) One other team members should be conversant.

27. 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. The Features drive the development of the use cases – our functional requirements, and the development of our supplementary specifications – our non-functional requirements. Your deliverable must contain a Traceability Matrix.

28. More on Sample Features Features are not behavioral (like the Use Cases). These are typically text descriptions. 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.

29. Deliverable #2: Statement of Work 3. Statement of Work 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? What is your plan? (See textbook) This short document should appear in the Artifacts Folder

30. Deliverable #2 – Traceability Matrix A traceability matrix associating needs to features is to be captured in the Product Vision Document. This is essentially a 1:n mapping of Needs (from the Users/ Stakeholders) to Features that the application will accommodate. Needs are very high level and may contain items that will not be (can not be) accommodated by the application. Features are to be accommodated by the application. Additional guidance will be presented to support your traceability efforts.

31. Deliverable #3 Develop Use Case Index Develop Façade Use Case Specification Develop Initial User Interface (UI) Prototype Extend Requirements Traceability (RT) Matrix

32. Deliverable #3 - Use Case - Façade Iteration Initial User Interface Prototype, Traceability due: Wednesday 10/26 Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, such as the revised Iteration Plan, etc. as required. Specific Rework: Revisit the Business Case (Deliverables 1 and 2) including artifacts listed below and update them. (Risks Lists – deliverable 1; Business Rules. Revisit Artifacts from Deliverable 2 especially the Domain Model and the Product Vision Document (deliverable #2) and the Statement of Work, etc.)

33. Deliverable #3: New Artifacts 1. Develop Use Case Index Single page: Essentially this is a table of contents of Use Cases Include an index for Use Cases that follow. Use designators, UC1, UC2, etc. (to facilitate traceability) Use Case Index is to contain an entry to support traceability, Use Case name (verb…object), short description (no more than a single sentence), 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

34. Deliverable #3: New Artifacts 2. Develop Façade Use Case Specification. Develop an overall Use Case Diagram (all application Use Cases and Actors). Similar to Business Use Case Model but icons are a little different. This is sometimes called the system level use case model. This should be a single page of actors and use cases. Examples of all these can be found in Use Case book and Visual Modeling book. Develop Façade Use Case Specifications and associated Use Case Diagrams for each Use Case. (See examples) Use Requisite Pro and Rational Rose (Use Case View) for your models. Link the Use Case Specifications captured in Requisite Pro and onto Rational Rose. Use the Façade Use Cases templates from the Kulak and Guiney book. Again, see power point lectures for required attributes. (See examples of ‘reasonable’ student Use Cases posted on my web page.)

35. Deliverable #3: New Artifacts 3. Develop User Interface Prototype …needed to familiarize the end user with the beginnings of the User Interface. Additional functional requirements will likely be discovered. Iterate this a as needed. (Can 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. You may use any prototyping tool you wish: VB, JavaScript, dynamic HTML, etc. Your prototype should include storyboarding. Most teams use static html; some use Front Page; some contain Javascript, etc. It doesn’t really matter to me. Validate the functionality represented on the user interface with VIM. Alternatively, validate with members of other team.

36. Deliverable #3: New Artifacts To accompany the Façade Use Cases, user interface prototype needs to represent the functionality that will ultimately be implemented and accessible from the UI later. See examples of initial user interface prototypes on my web page. See also (ahead) lecture slides on User Interface Design

37. Deliverable #3: New Artifacts 4. Extend a Traceability Matrix Traceability Matrix is to extend the traceability matrix developed in Deliverable #2. Traceability so far includes tracking indicators (U1, S03, etc.) from previous work that mapped Needs to Features. There were a couple of effective ways we discussed. In this deliverable, you are to extend the traceability from Features (captured in the Product Vision Document and documented in matrices) from Features to specific Use Cases that tell the stories of the Features. Thus your Matrix will have a 1:n mapping of Features to Use Cases.

38. Deliverable #4 Develop Full/Mature Use Case Specifications Develop Activity Diagram for each Use Case Extend Requirements Traceability (RT) Matrix Revisit and Revise: Domain Model, Façade Use Case Specifications and Diagrams User Interface; All Management Docs

39. Deliverable #4 Overview due: Monday, 11/14 Executive Summary; Cite all revisions and overview activities. Develop Mature Use Case Specifications and associated Use Case Diagrams for each Use Case. Each Use Case is to be accompanied by an Activity Diagram that should indicate flow for all paths in the Use Case Extend the Traceability Matrix by tracing all use cases backward to specific features and forward from features to use cases. Revisit the Domain Model for added / altered business entities; revisit your Risks document, Business Rules, and Product Vision statement. Upon ‘completion’ of Use Case specifications, revisit the UI.

40. Use Case Specifications Complete Use Case Specification and Use Case Diagrams for each Use Case – This is a major assignment. Complete your model by including alternative, exception flows, and ‘sub-flows’, using extension points or other tags as appropriate. Include all subflows with your use case narratives. Modify any use cases you feel are associated with any ‘included’ or ‘extending’ use cases and change use case diagrams to reflect these use cases. (There definitely should be some.) Develop a single Use Case Diagram for the entire Application too. This will be a single diagram containing all actors and all use cases and connections.

41. Use Case Specifications - More Allocate functional requirements / features to use cases via the stories of interactions. 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. Try to get the proper level of granularity. (Discussed in class). 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 and/or Glossary. Ensure everything the customer desires is accounted for!  Iterate on the Use Case Model. Review, Review, Review!

42. Rational Rose and Requisite Pro In Rose, put Use Cases into packages appropriate to the major feature(s) and groupings of features they address. (These may assist in our software architecture later – as these may become likely subsystems). Use Rose (Use Case View) and Requisite Pro to link all these into a single browser (SQA team members). Kulak and Guiney book (Use Cases); Visual Modeling book and Rose Basics (see power point lecture slides for examples.) Recognize that Use Cases are really never ‘finished.’ They become more ‘mature’ as we learn more.

43. Activity Diagrams Develop one activity diagram per Use Case. Activity Diagram is to should include all alternate paths. You may view an Activity Diagram as a visual model of the Use Case, since it will contain all scenarios. Include Activity Diagrams in a package in Rose Browser in the Use Case View under Use Case Models in a folder entitled Activity Diagrams. See Visual Modeling text for examples and use Rose.

44. Traceability Matrix Extend your traceability by tracing all features forward to individual or groups of Use Cases required to capture these features. Similarly, trace Use Cases back to features that the Use Cases address. You must ensure that every feature is accommodated in the collection of Use Cases and that there are no superfluous paths in use cases that do not trace back to specific features. You will need to address the scenarios in each use case to do an adequate trace. This is a lot of work. If you find a scenario that does not relate back to a feature, check the feature; if necessary check the Need. Something needs to be resolved… Report on this activity.

45. Revisiting / Iterating Previous Deliverables Special emphasis: UI and Domain Model Be absolutely certain to revisit / modify your User Interface Prototype in light of the development of the collection of Use Cases. Recognizing that this collection represents the functionality of the application, does the Use Case support these major functions at a sufficiently high level. The most major options presented on the UI must reflect the most major features to be implemented – up front…

46. This will be a major milestone in our development efforts. Once we can ‘baseline’ these artifacts with user concurrence, we will then embark upon Analysis Modeling

47. Deliverable 5 due: 11/30 1. Analysis Model 2. Non-Functional Requirements: Supplementary Specification Document 3. Traceability Matrix

48. Analysis Model 1. Analysis Model (Preliminary Design) Part 1: Static Model – VOPC Your analysis model must include boundary classes, a control classes, and entity classes required for each Use Case. Model is to be fully connected - show labeled associations, multiplicities (for entity classes – may come from Domain Model)… Should be a one-page drawing per Use Case Class structure may be realized with the standard stereotyped classes or the RUP icons

49. Analysis Model – Sources; Guidance Use your initial user prototype (boundary), Domain model (entities), and Use Case Specifications (control as well as the others) See also your Features to ensure all features are captured. See Visual Modeling Book; RUP; Logical View on Rose Allocate as many attributes and methods (responsibilities) as possible to each of the analysis classes. Can one inspect any path through a use case and see where/which objects will accommodate the functionality? (Can it be traced (with your finger...) through the objects as you read through the path description?

50. Analysis Model 1. Analysis Model (Preliminary Design) Part 2: Dynamic Model – Interaction Diagram Your analysis model must include an Interaction Diagram (Sequence Diagram and Communications Diagram) for the basic course of events for each Use Case. Use your analysis classes in this modeling. There are a host of examples in my notes and in the books for this course. Object structure may be realized with the standard stereotyped classes or the RUP icons

51. Non-Functional Requirements 2. Supplementary Specifications Document See Use Case Textbook for examples of ‘tables’ System Size: Small systems: functionality; performance Large systems: Portability; Maintainability; Scalability; Reliability; Security How about: Persistence? Will discuss more in class. The Supplementary Specifications for Non-Functional Requirements should be a Word document containing the non- functional ‘tables.’ Link this in to Req Pro.

52. Traceability Matrix and Associated Documentation 1. Map each Use Case (such as UC1, …, UCn) to the analysis classes that will accommodate the Use Case functionality. (Recognize that there may be many scenarios in each use case. But they must be traceable to analysis classes and hence the matrix. You may have to be somewhat creative to show this kind of trace to specific analysis classes. Again, you might include a VERY short description of the Use Case (its name and short description) and then the analysis classes that realize the specification. Link this in to Requisite Pro. Ensure ALL traceability is VERIFIED to date! “Let no function be left behind!” (Ha)

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

54. Deliverable #6 - User Interface Design due: Wednesday, 25 January 2005 Purpose: To design a user interface that reflects application functionality. This should be a significant refinement of your initial user interface prototype based on your increased knowledge and understanding of the requirements. This user interface should demonstrate the vast majority of key items of functionality as found in the use cases. In your classroom and field presentation, you are to demonstrate how your UI satisfies required functionality. Utility and Usability Principles as cited in the lecture slides and your text will be emphasized in evaluation. Verify your UI by running it against your use cases to ensure all functionality is captured.

55. Deliverable #6 - User Interface Design I should be able to access the Deliverable #6 folder on your CD and bring up the UI and execute it successfully. I should be able to navigate from screen to screen to pursue some scenario from a use case. I should NOT have to hunt and peck and wonder… Recognize that some (a few) of the windows / displays will be / may be hard coded and that demonstrated functionality may not be totally backed up with implemented code or efficient algorithms. But the implied functionality must be clear. Text caveats in the UI are appropriate. ALL new team members must be on board and conversant with the project This will be field tested for the Medical Project.

56. Deliverable #6 - User Interface Design Your User Interface will be demonstrated in class and will be openly discussed. This version of your UI should address ALL the anticipated functionality for the VIM project. Ensure the UI incorporates all the myriad changes emailed by the users that you will include in the application. Features to ‘not be included’ will be separated discussed during your presentation. Team 2 will present first. Ensure Self and Peer Evaluations are emailed to me.

57. Deliverable #7 – Layered Architecture due: Wed, February 15, 2006 Layers: You are to design a layered architectural prototype to accommodate your application requirements. The named layers are to consist of major subsystems and packages, their contents (other subsystems, packages, etc.). All component dependencies (coupling) are to be indicated via appropriate UML connectors. The main purpose and suggested contents of each of your layers must be spelled out in a text-accompanying document. (see lecture slides for examples) Your choice (decision) of architectural pattern should be fully discussed using the eleven design principles; that is, how does your choice support the design principles enumerated upon in the lecture slides and your textbook. (Word document, please)

58. Deliverable #7 – Layered Architecture Subsystems / Packages. For each subsystem, you should provide a single sentence citing the purpose of the subsystem (that is, how it ‘coheres’). You should provide a rationale explaining exactly why specific subsystems / packages were placed in their respective layers; that is, a record of your design decisions. (Cohesion) The detailed contents of the subsystems / packages (subsystems, packages, classes and their associations / dependencies) of each design element should be supplied at this time (cohesion). This means that classes, for example, constituting a subsystem or package, must have their properties named and methods (responsibilities) cited – as much as possible. You should NOT INCLUDE the detailed description of properties (that is, float, char, integer, String, etc.) nor the number and types of parameters for the methods nor the algorithms, etc. used by the methods. Only named methods / return items. These models should be realized in Rose. Supplement this layered model separately as needed in Word.

59. Deliverable #7 – Layered Architecture Please note that your architectural modeling (layers and their components, etc.) should be captured in Rose: Logical View, Design Model, Layer. The Layer has subfolders for packages, subsystems, etc., which you will like (I hope). There are mechanisms for, say, a subsystem, to name the subsystem and site the dependencies and interfaces related to this subsystem. Approximately what I’d like your deliverable to look like:

60. … … … Presentation Layer Application Layer Middleware Layer Name each of your layers (probably four…), subsubsystems, packages, classes, etc. etc. See next page. Subsystem name Package name Subsystem name However many Architectural Layers – the basic idea … additional layers as you decide.

61. You will communicate the interface of each component by taking each component (subsystem) and showing the responsibilities of the subsystem by showing the interface class. (Note the stereotype below) You will need to show the arguments that are part of the signature. Please note that a package has no specific interface and thus the classes in a package needs to explicitly show its public interface. (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… Components and Their Interfaces

62. You may combine this drawing with the previous drawing; otherwise, make this separate. For each component, you should also – as much as possible - include the classes and their properties/methods that are needed to ‘realize’ the interface. Recognize those signatures in the interface must be accommodated by the classes or other components (along with other dependencies ‘they’ might have) in the subsystem. You may also show any dependencies these objects will experience with realizing the interface… (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… … …… Design Elements in Each Component 1..2 * Add properties, methods, and anything else that will assist in realizing the interface. Showing a dependency between this object (in sub) and an object in another design element (package, here) We are saying that the interface is realized by this combination of objects and dependencies. XXXX Package

63. Deliverable #8: Detailed Design - Overview due: Monday, 6 March 2006 0. Folder with Deliverable #8 on CD. Executive Summary, as usual. (Also, send Self and Peer Reviews) 1. Iteration Plan. Carefully constructed. This continues to be an essential part of your deliverable, because it really contains your schedule and your development ‘plan.’ Ensure you have time boxes and equally shared responsibilities for contributions. (SQA person primarily with team leader inputs and team buy-in!!) Be CERTAIN to check each other’s work. Do not just parcel tasks out and batch them up for delivery. Verify!!! 2. Sequence diagram and a communications diagram for the basic course of events and at least one alternative or exception scenario for each of your use cases is required. Do yourselves a favor. Don’t select the easiest alternative path. Also for alternative paths for CRUD considerations, these may not need full expansion. Simple notes may be sufficient. Address those issues that require a good number of object collaborations so that you are certain responsibilities will be met.

64. Deliverable #8: Detailed Design - Overview due: Monday, 6 March 2006 3. Traceability Update – Trace your design model entities to layers and subsystems / packages if possible. (accommodated by SQA guru) Because analysis entities do not necessarily morph cleanly to design components, this may be tough. But try to bridge this chasm between the analysis model and the design realization. 4. Prepare to Present – Nothing formal. Perhaps two team members should present. Date: to be decided. Should be able to cover easily within our 75 minutes. 5. Technology assessment. See slide ahead. Should be accommodated by team leader. 5. No need to interface with VIM people for this.

65. More Notes on Interaction Diagrams The sequence diagram is to be fully annotated, as shown in lecture slides. Include the communications diagram too (use the F5 toggle) Clearly use Rose. This is a design-level sequence diagram, so it should include the entire flow. Where there is a reference to a subsystem, that subsystem represented by its interface will suffice. (lectures upcoming) For packages, however, the public interfaces for each of the key classes in the package must be shown. (No implementation, but clear responsibilities via anticipated signatures is needed.) Don’t forget to include any persistency, security, etc. packages in their appropriate layers. Note that the subsystem interfaces do not require showing the ‘insides’ of the subsystem. The detailed responsibilities will be presented in Deliverable #9. But the responsibilities of the classes within packages (via their individual interfaces) must be shown.

66. Deliverable #8: Detail Design – Iteration Plan Sketch out what you feel will be the number of iterations that will be needed and the features (scenarios) that you will implement in each iteration. Remember! Jump on the scenarios / features that you feel present to your team the MOST RISK! Secondly, your most important core functionalities should be second. Map these to a number of iterations with short duration and stick to the plan. Include dates, scenarios, and responsible developers, expected outcomes, and room for your iteration assessment - shortcomings (a post mortem). Include span time dates of iteration! Your first iteration must be totally understood before you start it and you should have a ‘pretty good idea’ of the specifics of your second. As you finish the first, roll into the second one (or subsequent iteration) anything ‘not quite right.’ Finalize the next iteration (or any other one impacted by assessment of the first one) it before you continue. Iterate.

67. Deliverable #8: Detail Design – Iteration Plan Technology Assessment. Your iteration plan should include your preliminary assessment of the technologies that you plan to use, where (for what features) you plan to use them, sources of knowledge of these technologies and overall assessment of your team’s familiarities with these technologies. Tell me who knows what and the extent of that knowledge. See examples on my web page.

68. Deliverable #8: Detail Design – Use Case Realizations Static Component (Structural) Class Diagram For each sequence diagram you develop, you are to produce in Rose the VOPC (View of Participating Classes) for that sequence diagram. Be certain to include all the associations, dependencies, multiplicities, aggregations, etc. Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (Try to include any clear attributes. Identification of methods that realize responsibilities will be very helpful indeed.) (No algorithms, etc.!)

69. Deliverable #8: Detail Design – Use Case Realizations Dynamic Component (Behavioral) Interaction Diagrams (Sequence and Communications). These should be captured in Rose These should be located in the Logical View, Design Package, etc. Check out Use Case Realizations. Sequence diagrams are to be fully annotated and should include subsystem interfaces, persistency references, etc. as appropriate. (See previous slides) Be certain to look at past examples of sequence diagrams in the lecture slides. Use the toggle (F5) to generate the Communications Diagram. Note: Professional Rose users almost all seem to imply that developing the communications diagram first results in a cleaner, less cluttered sequence diagram via the toggle rather than vice versa. What do you think?

70. Deliverable #9 – Detail Design, Traceability, and Iteration Plan Subsystem Design and Realization – due: 20 March 2006 For each subsystem, you are to provide an interaction diagram of at least two responsibilities accommodated by the subsystem from its interface. (lecture 32) and Deliverable #8. No more than one interaction diagram for one subsystem should address accommodating persistency. You should, however, include one that does this. This means that of all your subsystem realizations, you may only show one interaction diagram that addresses persistency. I am thus after you to show a number of realizations that your subsystems must accommodate. You should also present the corresponding communications (collaboration) diagram. Note the differences. For each subsystem, you are also to provide the internal structure of your subsystems, like appropriate slides in lecture 33. This is your VOPC. These are to be fully annotated (dependencies, communications, multiplicities, etc.) You are to annotate via stereotyping which objects are persistent in your modified VOPC as well as any other stereotyping you feel is necessary. (See lectures on class design and persistency)

71. Deliverable #9 – Detail Design Subsystem Design and Realization All messages in your sequence diagrams need to be numbered as shown in lecture 32 (numbers and their sub-parts). ALL of your design class model elements must have the package or subsystem they are associated with in with the class header as shown in lecture 33 (think: University Artifacts). Packages and Subsystems should have a stereotype indicating the layer in which they reside. Sequence Diagrams may require UML Notes to clarify interactions. Use them as necessary. Extra credit and VERY NICE Touch: Try to list the text of the Use Case Specification in the left margin (column?) of each sequence diagram.

72. Deliverable #9 - Traceability The second major part of this deliverable is to realize traceability of each function captured in Use Cases and in the Analysis Model here in the Design Model. Frankly, you are breaking new ground here. It one thing to have traceability from Use Cases to analysis classes. It is quite another thing to trace analysis class traceability into the Design Model, as realized in subsystems, packages, classes, and in layers. Please note that this is a major undertaking for this deliverable and will take time!

73. Deliverable #9 – Iteration Plan This is to be a comprehensive treatment of iterations particularly starting with the Construction Phase. This should be based on scenarios in Use Cases. It should not be supporting activities such as refining the database, developing stored procedures, etc. It is used to track the development of the application and is an essential tool used to determine if we are on schedule. You may use any reasonable format, but remember, each iteration has most of the core disciplines as activities! (requirements, analysis and design, testing, implementation, configuration, environment, program management, etc.) Again, lots of work…

74. Deliverable #9 - Questions These are questions whose answers are to accompany this deliverable. You may answer these in the Management Folder. STUDY these questions and answers. Ensure that they are complete, as you will see them again! What is a proxy class and what is its purpose? What do we mean by a dependency? What are the pros and cons of dependencies? Under what circumstances is the modeling of only a subsystem interface sufficient in a sequence diagram? In behavioral modeling, when must the interface be realized? How is it done? What kind of model(s) is/are used to capture the details of the inner workings of a subsystem? Why should dependencies on a subsystem be on the subsystem interface? Turn these in via a separate Word document.

75. Deliverable #10 Class Design and Implementation #1 due 3 April In addition to Executive Summary,  Update your Iteration Plan for remaining iterations based on your assessment of the previous iterations.  Document that assessment as part of the Iteration Plan (may use Word) This may likely be a few paragraphs. Don’t wimp out on this!  Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.  Extend your Traceability to cover your current detail design  Testing: Document your test suites: catalog these via number, purpose, scope, results, and assessment of each test.  Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all connections are either associations or dependencies. This can be shown by clicking on objects across the top of sequence diagrams and filling in the window specifications.

76. Deliverable #10 Class Design and Implementation #1 Demonstrate and Discuss your (first and) second Iteration in class (possibly) Talk about the ‘good, bad, and ugly’ of your development, tests, etc. (not formal; 15 minutes per team)

77. Deliverable #10 Class Design and Implementation #1 Source Code: Your deliverable is to include your source- level components. organized ‘by design unit’ (that is, package, subsystem), ‘by component’ (within these higher level components). Read documentation section of Component View in Rose.  Please note: Your source code absolutely must be internally documented with meaningful, guiding comments. These will be reviewed very carefully!!! So, your organization should be Component View, Implementation Model, Package or Subsystem, and specific component within the owning package or subsystem.

78. Deliverable #11 Implementation #2 and Demo due 17 April This is a continuation / extension of Deliverable #10: In addition to Executive Summary and the accustomed documents,  Update your Iteration Plan for remaining iterations based on your assessment of the previous iterations.  Document your assessment as part of the Iteration Plan This may likely be a few paragraphs. Don’t wimp out on this!  Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.  Extend your Traceability to cover your current detail design  Testing: Document your test suites: catalog these via number, purpose, scope, results, and assessment of each test.  Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all connections are either associations or dependencies. This can be shown by clicking on objects across the top of sequence diagrams and filling in the window specifications.

79. Deliverable #11 Implementation #2 and Demonstration Source Code: Your deliverable is to include your source-level components. organized ‘by design unit’ (that is, package, subsystem), ‘by component’ (within these higher level components). Read documentation section of Component View in Rose.  Please note: Your source code absolutely must be internally documented with meaningful, guiding comments. These will be reviewed very carefully!!! So, your organization should be Component View, Implementation Model, Package or Subsystem, and specific component within the owning package or subsystem.

80. Deliverable #11 Implementation #2; Demonstration This deliverable is a chance to finalize any shortcomings in your Iteration Plans, Rose Models, or any design models/artifacts you have undertaken. ALL code is to be fully documented and submitted in folders “by type,” that means jsp files together,.java files together, servlets, …etc.

81. Deliverable #11 Implementation #2 and and Demonstration On the day you are demonstrating your projects (April 17 th ), you are to provide to me a hardcopy of your use cases. I will arbitrarily select one or two for you to demonstrate during class. (I would like to meet with the team leader / designee, the SQA individual and, if available, one of your lead programmers in my office earlier on Monday, the 17 th, if that is feasible. Please email and we can discuss the best time for you.) You may also be asked some general questions. Your demonstration, etc. should not last beyond thirty minutes. If you need separate computer support, you should plan to go to class early to set up / connect to whatever you need. Good luck and have fun!