1 / 51

Project Deliverables

Project Deliverables. Version 5: 04/12/2005 Note: This document contains the deliverables from the first semester. Do review these, as there are changes and some reorganization. Overview of Guidance. I shall try to upgrade / refine guidance for each deliverable as we progress.

demetrius
Download Presentation

Project Deliverables

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Deliverables Version 5: 04/12/2005 Note: This document contains the deliverables from the first semester. Do review these, as there are changes and some reorganization

  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 6017 - Team 2 or CIS 4328 – Team5. 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 • Folder is to contain four Word files plus a Folder. • Team Num file,with file name as follows (for example): Team3.TeamNumFile.Deliverable2.Date.09.27.04 • 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. • List individual email accounts. • Iteration Planwith file name: Team3.IterationPlan.Deliverable2.Date.09.27.04 •  Include for second semester deliverables only. • Note that the Iteration Plan will change for each deliverable, that is, it will be refined and ‘extended.’ The current iteration and a skeletal version of the next iteration constitute the ‘extensions.’ Each successive deliverable will contain a ‘revised’ Iteration Plan. • First semester courses: Executive Summary will suffice.

  5. Continued… • Executive Summary (in Word) with file name:Team3.ExecutiveSummary.Deliverable2.Date.09.27.04 • 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. • Vision Document (in Word) • Artifacts - a Folder • Goal: Contains sub folders and single files as appropriate. • Example: You should have a subfolder entitled Rose Models and perhaps another subfolder entitled Requisite Pro (Grad Students) • E.g. Should have a folder for Rose Models; Folder for Use Cases; Folder entitled Management Documents, which should contain simple Word files for, say, Risks List, Business Rules, etc… You have some flexibility here. Clear organization is a must. • New artifacts or revisited artifacts from previous deliverables, - specific components of the deliverable should be found here, and a number of these should be in their own subfolder, such as the user interface prototype, Use Case diagrams, use case narratives, analysis model, sequence diagrams. We will discuss in class.

  6. Guidance on the Rose Browser • Use Case Diagrams in Use Case Folder within Use Case Model in Rose • Each Use Case is to be a separate subfolder in the Use Case folder within Use Case Model (see the Rose Browser). • But Use Case Narratives are in Requisite Pro for Grad Students. • Actors in folder within Use Case Model in Rose

  7. 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. (See Executive Summary) • 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… • This is also required via the Executive Summary document.

  8. Second Semester StudentsGo to Slide 29 • You may skip over the five deliverables of the first semester. But there are changes within them that would make them better. • There needs to be a deliverable between deliverables 3 and 4 where the Façade-level use case is expanded to include the basic course of events (but not all alternatives and exceptions) and possibly the activity diagrams or at least identification (not expansion) of alternative / exceptional threads. • This will be added next iteration of this course…

  9. Deliverable #1 The Business CaseDue: Wednesday 10/4 • 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; To support these, a number of models and documents are needed. Deliverable Artifacts: • Business use case model Use Cases and Actors - Modeled • Business object model Use Cases realized with actors and entities for the modeling Use Cases realized with actors for the Use Case Descriptions. • Additional Artifacts Business Vision document - text Business Glossary - text Business Rules – text Business Risk List - text Domain Model - model in Rational Rose (in next deliverable)

  10. Guidance on Deliverable #1The Vision Document • Use the templates provided. (You may use Requisite Pro if desired. Take the Requisite Pro Quick Tour…) • This is an essential document and should provide a list of ‘features’ that the application to be developed should possess. • These features are not behavioral (like the Use Cases). These are text descriptions. Example of features: • ClassicsCD.com Web Shop Secure payment method. Easy browsing for available titles. Ability to check the status of an order. Customer shall receive e-mail notification. The catalog shall be highly scaleable to include many titles and effective searching through those titles. Customer shall be able to customize the Web site. Customer shall be able to register as a user for future purchases without needing to re-enter personal information.

  11. Guidance on Deliverable #1The Business Case • Use the appropriate forms available at: • RUP document templates are located at the site 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 of what they submitted.

  12. Guidance on Deliverable #1The Business Case • 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 should be found in the Use Case View; • This is a single model of the key business processes of the organization. •  Business Object Model in the Logical View. • All business object models and the business use case model are to be in a SINGLE copy of Rose. • (See examples on my web page.) • Put your Business Object Models within the Business Object Model folder within Logical View in Rose – see examples on web page. • Business object models are realizations of each of the business use cases and contain business actors. (All domain-oriented)

  13. Deliverable #2Domain Modeland Statement of Work Due: October 13th • Develop the Domain Model • Iterate previous deliverable artifacts • This means address EACH component and fix/repair/enhance/improve, etc. and certify. • Don’t make the same mistakes twice. • Add a Statement of Work (SOW), that is, what is your team plan – who does what, what is your plan, etc. (See textbook)

  14. Guidance on Deliverable #2 - Domain Model In addition to standard items, this deliverable requires a complete Domain Model. The Domain Model is essential to understanding the environment within which the application to be developed will function. Include also a Statement of Work. Turn in CD that contains all models and has links to text descriptions. Purpose: • Construct 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). Deliverable Artifacts for Deliverable #2: • Domain Model – taking into consideration additional attributes, multiplicities, associations, etc. The Domain Model should be captured as a separate folder under the Logical View in your Rose Browser. • Statement of Work - a Word Document. See textbook and/or templates for format Other artifacts from Deliverable #1 to be revisited. (Exec Summary will cite what changes you have done to each artifact…) Business use case model Use Cases and Actors - Modeled Business object model Business Vision document - text Business Glossary - text Business Rules - text

  15. Guidance on Deliverable #2: Domain Model Be certain to see example link on my web page and study carefully the slides in the appropriate two lectures. Be certain to fully consider my grading notes to you for Deliverable #1 prior to submission of Deliverable #2. • For first deliverable or two, the Iteration Plan may be more ‘descriptive;’ that is, may contain textual descriptions. For subsequent iterations, plan will be more cryptic, perhaps bulleted, perhaps tabular. • Not much verbiage. Activities undertaken, schedule, developers, results…

  16. Deliverable #3 - Use Case - Façade Iteration plus Initial User Interface Prototype due: Monday 10/25 • Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, such as the revised Iteration Plan, etc. as required. • Specific Work: • Revisit the Business Case (Deliverables 1 and 2) including artifacts listed below and update them. (Risks Lists; Business Rules; Domain Model; Statement of Work, etc.) • Include an index (numbered) for Use Cases that follow. (discussed in class and via slides) • 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

  17. Guidance on Façade Iteration • Develop an overall Use Case Model (all application Use Cases and Actors). Similar to Business Use Case Model. • Develop Façade Use Case Descriptions and associated Use Case Diagrams for each Use Case. • Use Rose (Use Case View) for your models. Link the Use Case Description text and ensure these descriptions are on the CD you turn in for grading. • CEN 6016 students must use Requisite Pro* • Model your Façade Use Cases using the Kulak and Guiney book. Again, see power point lectures for required attributes. • 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.)

  18. 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 detailed actor-system interactions. • See lecture notes for required attributes. • Must include all Use Cases. • Include your single 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; more, the icons are different for the actors and use cases. Be sure to note the differences.

  19. Guidance on User Interface Prototype • Develop User Interface Prototype…needed for requirements capture!!! Iterate this a 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. • You may use any prototyping tool you wish: VB, Java, etc. Your prototype should include storyboarding. • Most teams use static html; some use Front Page; some contain Javascript, etc. • Recommend testing your interface with someone from a different group. If you link up with me, I will be glad to assist. • To accompany the Façade Use Cases, user interface prototype needs to be total complete. While we are not including actor – application ‘interchanges,’ these are essential for the next deliverable. • See examples of initial user interface prototypes on my web page. • See also (ahead) lecture slides on User Interface Design

  20. Deliverable #4Full Use Cases Model & Activity Diagramsdue: 11/8 • Executive Summary • Develop Focused and Filled Use Case Descriptions and associated Use Case Diagrams for each Use Case. • Use Rose (Use Case View) and Requisite Pro* Kulak and Guiney book (Use Cases); Visual Modeling book and Rose Basics (see power point lecture slides for examples.) • Each Use Case is to be accompanied by an Activity Diagram that should indicate flow for all paths in the Use Case • *CEN 6016 Students only • (Recognize that Use Cases are really never ‘finished.’) • Your Use Case Diagrams will likely be supplemented with Included or Extended Use Cases, as appropriate. Redo your Use Case Model for the Application.

  21. 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 (should include all alternate paths) (Include as package in Rose Model) • Put Use Cases into groups – packages that ‘seem’ to go together functionally, like the GUI or those that address 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

  22. 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. • Requirements with extension points to address alternate and exception flows. – see class notes. • 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. • Ensure everything the customer desires is accounted for!

  23. Keep the alternatives /exceptions WITH the use case. They 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. • 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

  24. Deliverable #5 - Developing the Analysis Model and Non-Functional Requirements - due 12/01 • Analysis Model (Preliminary Design) • Contains communicating boundary, control, entity objects with relationships, etc. •  Will flow from your use case narratives and prototype • Supports Interaction Modeling and much more… • Designed to lead ultimately to the class model (static) • Sources: Use your prototype (boundary) again, domain model (entities), and use case descriptions (control) in earnest. They are not enough, but will help. See also your Vision Document. • See Visual ModelingBook; RUP; Logical View on Rose

  25. 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) This should partition all the classes by type. Include all attributes / methods with each class, but not 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

  26. Guidance on Deliverable #5 Analysis Model • Remember, the validity of the model is simply can I look at any path through a use case and see where/which objects will accommodate all the functionality captured in a scenario? Can it be traced (with your finger...) through the objects as you read through the path description? • This is the check to make! VerifyTraceability!!! • Try to cite as many attributes and methods (responsibilities) as possible in the respective class-names – boundary, control, and entity. • Yes, I am after associations, dependencies, etc. among the classes – as much as practical.

  27. Guidance on Deliverable #5 Analysis Model • For boundary to control classes, the 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.

  28. For next time: • This Analysis Model assignment should include a sequence diagram using the analysis classes for each use case. • Did not require this in the past – should have. • Note: 2/9/05

  29. Guidance Deliverable 5: Non-Functional Requirements • See Use Case Textbook for ‘tables’ • 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. • Thus the Supplementary Specifications Document should be a Word document containing the non-functional ‘tables.’

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

  31. Deliverable #6 - User Interface Designdue: Wednesday, 26 January 2005 • Purpose: To design a user interface that reflects application functionality. • This should be a refinement of your initial user interface prototype based on your further learning about your application. • This user interface should demonstrate all required functionality as found in the use cases. • In your presentation, you are to demonstrate how your UI satisfies all Usability Principles as cited in the lecture slides and your text. • Verify your UI by running it against your use cases to ensure all functionality is captured.

  32. 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. • Recognize that some of the windows / displays will be / may be hard coded and that demonstrated functionality may not be backed up with implemented code or efficient algorithms. But the implied functionality must be evident. • Text caveats in the UI are appropriate.

  33. Deliverable #7 – Layered Architecture due: Wed, February 9, 2005 • 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)

  34. 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. • Deliverable #7 should have the Rose model in a folder with your other Rose models. Of course, this is merely a significant extension of what you already have. So, there should be a Rose folder. • Also, all supporting new documents for Deliverable #7 that are associated with this deliverable need to be in a folder entitled: Architectural Support Documents, and reside in the Deliverable #7 parent folder. • Other documents, such as an executive summary, etc. should be separate as usual.

  35. 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-Name> Layer. • The <Layer-Name> 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:

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

  37. Components and Their Interfaces You will communicate the interface of each component by taking eachcomponent (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. Maintain Database (name interface) <<interface>> Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc……

  38. Design Elements in Each Component 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… Maintain Database Add properties, methods, and anything else that will assist in realizing the interface. (name interface) <<interface>> … 1..2 Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… * … … 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

  39. Deliverable #8: Detailed Design - Overview due: Wednesday, 2 March 2005 • 0. Folder with Deliverable #8 on CD. Executive Summary, as usual. • 1. A carefully constructed Iteration Plan. This now becomes an essential part of your deliverable, as we are about to go into the Construction phase. • 2. A sequence diagram and a communications diagrams for the basic course of events for each of your use cases. • The sequence diagram is to be fully annotated, as shown in lecture slides. • This is a design-level sequence diagram, so it should include subsystems via their interfaces; also the persistency mechanism.

  40. Deliverable #8: Detail Design – Iteration Plan • Iteration Plan • You should 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 out into 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). Use Word or Excel. 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 anything ‘not quite right,’ finalize it before you start this one and map out a ‘pretty good idea’ for the third iteration. Iterate.

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

  42. Deliverable #8: Detail Design – Use Case Realizations • Interaction Diagrams. • For each Use Case, you are to develop a Sequence Diagram 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. • Be certain to look at past examples of sequence diagrams in the lecture slides. • Use the toggle (F5) to generate the Communications Diagram.

  43. Deliverable #8: Detail Design – Use Case Realizations • Class Diagram • For each sequence diagram, you are to produce in Rose the VOPC (View of Participating Classes) for that sequence diagram. • Be certain to include all the associations, multiplicities, etc. in this class diagram. • Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (the attributes and operations of some of the classes) will need to be finalized at this time.

  44. Deliverable #9 – Detail DesignSubsystem Design and Realization – due: 16 March 2005 • For each subsystem, you are to provide an interaction diagram of at least one responsibility accommodated by the subsystem from its interface. (lecture 32) • No more than one interaction diagram should address accommodating persistency. You should, however, include one that does this. • You should also present the corresponding communications (collaboration) diagram. Note the differences. • You are also to provide the internal structure of your subsystems, like slides 4 and 6 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 in this rendering. (see lectures on class design and persistency)

  45. Deliverable #9 – Detail DesignSubsystem 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. 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.

  46. Deliverable #9 - Questions • 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 kind of situation is 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.

  47. Deliverable #10Class Design and Implementation #1 due 30 March • 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. •  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.

  48. Deliverable #10Class Design and Implementation #1 due 30 March • Document how your Use Cases drove your iteration plan and development. • Document how your architecture assisted (was central) in your development. • Demonstrate and Discuss your (first and) second Iteration in class (possibly) • (not formal; 15 minutes per team)

  49. Deliverable #10Class Design and Implementation #1 due 30 March • You are to include your source-level components. These need to be 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.

  50. Deliverable #11 – FinalTesting and 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. • There will NOT be a separate test plan document required, as originally planned.

More Related