Iterative Software Development Course Deliverables

1. ProjectDeliverables Version 1: 08/30/2005 Note: This document contains the deliverables for a two semester course. These items WILL change as the courses progress.

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 FolderDocuments • 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 FolderDocuments • 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 FolderDocuments • 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 ModelingBusiness 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 ModelDomain AnalysisDeliverable Artifacts • Business Vision Document - a text document. • Business Use Case Model – captured in a Rational Rose model • Business Glossary - text • Business Rules – text • Business Risk List - text • Domain Model - model in Rational Rose – will accommodate in Deliverable #2.

15. Business Vision DocumentGuidance • 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 Guidance • 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. The Business Case ModelGuidance with Rose • When logging onto Rose, be sure to select RUP icon from the initial window. • Be also certain to notice the tool mentors – when you select a folder in the Rose Browser, a description often appears with invaluable information. • The Business Use Case Model must be developed in the Use Case View (see last slide) • This is a single model of the key business processes of the organization.

18. 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, ….

19. The Business Rules • Use the appropriate forms available at: • RUP document templates are located at the site http://jdbv.sourceforge.net/RUP.html.  See also my web page. • The link for the Business Rules template is incorrect (points to the Business Modeling Guidelines template), so there is another link to point to the Business Rules format. • 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.

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

21. Deliverable #2 Domain Model The Vision Document - Application Statement of Work

22. Deliverable#2 – ArtifactsDue: Wednesday, Oct 12th • Purpose: Develop Key Artifacts. (Inception Phase) • Address all items in Management Folder. • 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). • Build a Vision Document for the Application to be developed. Will include User Needs and Features • Develop a Statement of Work – assigning responsibilities to different roles to be accommodated on the team. • Review / upgrade previous artifacts. Business Use Case Model Use Cases and Actors - Modeled Business Vision document - text Business Glossary - text Business Rules - text

23. Domain Model - Guidance 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).

24. Domain Model • 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.

25. The Vision Document • This represents the vision for the application you will be developing. An essential artifact. • Use the template provided. • Modify items as need. • (Software Quality Analyst on your team will learn/use Requisite Pro. Take the Requisite Pro Quick Tour…) One other team members should be conversant. Needs and Features: • This essential document and should provide a capturing of ‘user needs.’ • These “needs” will be mapped into “features” which will be later traced into use cases in the form of functional requirements. •  Be sure to review the link on my web page to ‘Great Article…..’ Gives very valuable information (not found in your books) on needs, features, use cases.

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

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

28. Statement of Work • My 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)