Unformatted text preview: Project Deliverables
Version 8: 11/23/04
Final Final Version for First Semester Overview of Guidance
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. Format of Deliverables
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 2 or CIS 4327 – 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. Contents of Folder Contents of 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 Plan with file name: Team3.IterationPlan.Deliverable2.Date.09.27.04 (Omit for Inception and Elaboration… Deliverables 15 this term…) 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.
For first deliverable or two, may be more descriptive. For subsequent iterations, plan will be more cryptic, perhaps tabular. Not much verbiage. Continued…
Continued… Executive Summary (in Word) with file name: Team3.ExecutiveSummary.Deliverable2.Date.09.27.04 This single page document is to summarize 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 Artifacts a Folder Goal: Contains sub folders and single files as appropriate. E.g. Should have a folder for Rose Models; Folder for Use Cases; perhaps a simple Word files for, say, Risks List, Business Rules, Vision Document, etc… But you may group these Word files into a folder called Management Documents; 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, etc. Guidance on the Rose Browser
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
Look very much at Team2 – Requisite Pro top level folders BEFORE deciding on deliverable contents if you are a grad student!!!!!
Business Vision and Glossary in folders – See Team 2 Grammar and Wording
Grammar and Wording Under NO circumstances will poor grammar or illconceived sentences be considered acceptable work. EACH portion of EACH deliverable should be reviewed and ‘signed off’ by EACH team member.
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… Deliverable #1 The Business Case
Deliverable #1 The Business Case
Due: Wednesday 10/4 Purpose: To understand the structure and dynamics of the organization within which the application will operate;
To ensure customers, endusers, 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) Guidance on Deliverable #1
Guidance on Deliverable #1
The 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 email 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 reenter personal information. Guidance on Deliverable #1
Guidance on Deliverable #1
The 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. Guidance on Deliverable #1
Guidance on Deliverable #1
The 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 domainoriented) Deliverable #2 Domain Model
and 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) Guidance on Deliverable #2 Domain Model
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).
from 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 Guidance on Deliverable #2: Domain Model
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.
Deliverable 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… Deliverable #3 Use Case Façade Iteration Deliverable #3 Use Case Fa
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 Guidance on Façade Iteration
Guidance on Fa 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.) Guidance on: Facade Iteration
Guidance on 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 actorsystem 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. Guidance on User Interface Prototype
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 fullblown Use Case Descriptions with alternate and exception paths.
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 Deliverable #4
Full Use Cases Model & Activity Diagrams
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. Guidance on Deliverable #4: 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 ‘subflows’, 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 Guidance on Deliverable #4: 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 actorapplication 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! 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 UserInterface 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 Deliverable #5 Developing the Analysis Model Deliverable #5 Developing the Analysis Model and NonFunctional 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 Modeling Book; RUP; Logical View on Rose Guidance on Deliverable #5 Analysis Model
Guidance on Deliverable #5 Analysis Model Include boundary classes together, control classes together, and entity classes together all without associations to other classes. (a onepage 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 Guidance on Deliverable #5 Analysis Model
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! Verify Traceability!!!
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. Guidance on Deliverable #5 Analysis Model
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. Guidance Deliverable 5: NonFunctional Guidance Deliverable 5: NonFunctional Requirements See Use Case Textbook for ‘tables’ Small systems: Large systems: Portability; Maintainability; Scalability; Reliability; Security How about: functionality; performance Persistence? Will discuss more in class; Remember the Supplementary Specifications for NonFunctional Requirements.
Thus the Supplementary Specifications Document should be a Word document containing the non
functional ‘tables.’ ...
View Full Document
- Spring '08
- Web page, domain model