CIS 4327 – Project Phases and Deliverables



CIS 4327 – Project Phases and Deliverables

All software documentation will be accumulated in an evolving software documentation folder, which we will call the repository. This is to be a most-professional appearing document. There is to be a clearly observable tab between each of the major phase deliverables. At your option, you may wish to subdivide parts of each phase deliverables, as appropriate.

As deliverables are turned in, I will look at them carefully and suggest changes that might be necessary. Ultimately, the entire repository (and presentation) will receive a single, final grade. Each major component will be separately graded.

Please note that software documentation is expected to evolve. We do not exist in a perfect world, and as more knowledge is ascertained, and as clarifications arise, you will be expected to spend some time enhancing (updating) your software specification document.

The phase descriptions with attendant required elements delineates the required documentation and their contents. While there may be a clarification or two, the major required components of each phase are listed below.

It is required that each team create a development plan with task assignments and their decompositions in order to track the project progress. A number of project planning tools are discussed in the textbook and are available in our lab…

You may use ERWin for many of your data activities, but ultimately each team is to use System Architect Version – latest as found in our laboratories. This software will serve you well.

Phase I. Requirements Discovery and Modeling. Due: May 28th, 2003

This initial effort is required to get the project into gear. It will include the following items that are to be accomplished:

1. The Initial Project Request/Description (prepared by the client and the teams containing the problem and expected solution). See web page and textbook p. 177 for examples. This is a rather short section which merely outlines the project at a very high level. The Project Scope (ahead) will constrain the project and bound it. This section should contain a Brief Statement of Expected Solution. (Request for Services….) . This is sometimes referred to as the Vision of the project.

2. Requirements Specifications - Start

A. Use Cases. To identify the required functionality of the project, each team will create a series of Use Cases. Such a comprehensive set of use cases will capture the functional requirements of your project. (Be aware that there are other very meaningful requirements that your project must satisfy that are not necessarily ‘functional’ in nature – we will discuss…). The textbook covers the construction of Use Cases on pp. 244-247 and pp. 662-663. Your Use Case submission should include a figure very similar to Fig 6.7 on p. 246 and a number of figures closely resembling Fig 6.9 on p. 247. I have a number of projects in my office that employ use cases to capture functional requirements. You may come and look at them at your leisure. (This activity will take a lot of time!)

Plan your efforts by creating your Use Cases in phases…. (a façade use case, a filled use case, a final use case). See text for examples and/or see me for examples. Don’t jump to the final use case. Go slowly and methodically! Make sure your façade use cases are solid and cover desired functionality FIRST before proceeding.

This activity relates to the Project Scope (below). As you attempt to discover and document your use cases, you will be placing boundaries on the system; the scope will be identified.

Use Case Index and Description. Preceding your Use Cases, you will include a single page containing an Index of Use Cases and an accompanying short use case description– This is meant to tie the use cases to Project Description. Number your use cases starting with 1.

Actor. Each actor is to be accompanied with a ‘brief description’ of the role the actor plays. (one or two sentences) Remember, the actor triggers the application and must receive a value; the application provides the use cases.

B. Supplementary Specifications. Use Cases may capture all of the functional requirements of an application, but there is so much more. Additional supporting artifacts include the domain model / technical dictionary (glossary) (see Project Scope) and are essential for support design and development. The supplementary specifications sections will be included in Deliverable #3 and will include the system requirements that are not readily captured in the use cases or use-case model, such as legal and regulatory requirements, application development standards, quality attributes such as usability, reliability, performance, and supportability requirements, and constraints, such as the operating system environments, programming languages, and other design constraints, and lastly, other requirements that just don’t fit naturally into the use cases. Many of these are ‘declarative’ in nature and may be simple sentences. (Start thinking / keep track of some of these as you evolve your Use Cases). Keep them in your repository.

Technical Dictionary (Glossary) and Domain Model. These are parts of your Supplementary Specifications. Start creating these ‘as you go.’ Define all main terms in the language of the end user. The Domain Model is merely a model of domain entities and their interconnections/dependencies (multiplicity, roles, etc.) It is not the Conceptual Database Model (although there is a similarity…)

In this section, include a draft Technical dictionary and domain model. We will try to lock these in in Deliverable #3.

So, requirement specifications really consist of two components: functional requirements (use cases…) and supplementary (non-functional) requirements – generally declarative in nature. Much more later.

3. Project Scope

This is the section where you will write approximately one-half to a full page describing textually your project. This will scope your project and direct your efforts. This is where the project is bounded!

The Project Scope is constructed to place bounds on the system. However, scope can (and will) change. Do not confuse this requirement with the Brief Statement of Expected Solution in your initial Project Request/Description. That one is quite high level.

A. The Project Scope, as I have it envisioned, will be a single page (approximately) series of statements describing what you plan to analyze, design, and ultimately implement for your project. I will review your Project Scope along with the other materials (once delivered), and we can then discuss (and change the Scope as appropriate). Your Scope deliverable should include data, functions, and system interface, as described on page 179 in your textbook. The Project Scope should be in sentence format. You may title this component simply as Project Scope (center this title on a page and present discussion beneath it). Your use cases, domain model and glossary will guide the creation of the Project Scope.

B. Statement of Work. I would also recommend that you include a Statement of Work (see chapter 4) in with your Scope. Fill in items as appropriate (some you cannot do so at this time and in our environment).

Now go back and review your Use Cases…(Modify as necessary). (They are a living document)

4. Project Plan

At this time, your project plan may be quite high level and be a simple restatement of the deliverables and target dates expanded upon below. However, this Project Plan (please construct a simple Gantt Chart - use Microsoft Project) will be expanded upon in the very near term. You may include (at this juncture) no decomposition of the deliverables cited below. Thus, a single page may well suffice.

Your project notebook should be a large (2”) binder with the name of your project on the outside cover along with the Team Number and the Team Members. Also include Summer 2003 on the cover. Inside there are to be ‘major’ tabs and ‘minor’ tabs. Ensure the tabs cannot ‘fall out’ of the tab holders. This first deliverable will be the first major ‘tab’ and should be entitled Requirements Capture. Ensure this is typed on the tab itself. Inside this tab are four minor (lesser) tabs. Ensure that they are physically ‘smaller’ than the major tab. Each of these tabs is to contain each of the four parts to this deliverable as outlined above. There needs to be a typed title on each of these tabs also.

===============================================================================================

Phase II. Data Modeling and Normalization due: (due: June 4th)

General: Your project will involve creating a database management system to satisfy user requirements. Using the results of your requirements gathering efforts in Phase 1, you are now required to build the logical data model. You may view this deliverable as consisting of five major components: Revisions to Deliverable #1, Creation of the Context Data Model (ER diagram), Creation of a Fully-Attributed Data Model (without normalization), and Creation of the Normalized fully attributed model. Lastly, you are to include an updated Project Plan. Each of these components involves related activities as described below.

Recommendations: 1) Read Chapter 7 very carefully and digest it!

2) Create your context Data Model first and related tasks and updates.

3) Then develop the Full-Attributed Data Model.

3) Complete the data dictionary

4) Normalize the Data Model.

System Architect should be your technology of choice!

Your deliverables (each part, as appropriate) should include the supporting documentation produced for you by System Architect.

Formats: See textbook.

Revisions to Deliverable #1:

For those sections in Deliverable #1 that required revisiting, include them as part of this Deliverable. Be sure to include separate tabs for these, such as Use Cases, but include this tab and its contents within the Deliverable 2 portion of your project folder.

It is quite possible that your project scope with have changed. Update this. Similarly, you may be adding or modifying a number of use cases. Be sure to include a complete new set of these Use Cases. Include a Use Case Index preceding the first use case that references each use case and encapsulates what was done to it (that is, overview). Make this in tabular form.

Do not jump ahead without ensuring the Project Scope and Use Cases (updated) are compatible with your Context Data Model!

Part 1: Context Data Model.

You must include keys in your context data model, as appropriate. No non-specific relationships are to be included in the Context Data Model. These are to be replaced by associative entities, etc. Primary and alternate keys must be included. All cardinalities are to be indicated. Be sure to label your relationships.

(I am including the requirements that are normally found in the key based model in with the Context Data Model. This model should look similar to the one in Figure 7.14, p.283 of your text.)

As you go through the book, you will note (Table 7.5) Fundamental Entities for the Sound Stage Project. This providing of a Business Definition to each Entity is very practical. Include this page as the first page of your Context Data Model tabbed section.

Part 2: Fully-Attributed Data Model

In addition to producing the hard copy fully-attributed data model, all attributes must have their data types, domains, and defaults entered into the data dictionary (encyclopedia in System Architect.) A hard copy of this dictionary must also be included as part of this deliverable. (Figure 7.16, p. 287 is a good reference)

Fully-Attributed Data Model component consists of:

Fully attributed data model

Data Dictionary

Part 3: Normalized Data Models

Include all three models: 1NF, 2NF, and 3NF.

Project Notebook: This second deliverable will be the second major ‘tab’ and should be entitled Data Analysis. Ensure this is typed on the tab itself. Inside this tab are three minor (lesser) tabs. Ensure that they are physically ‘smaller’ than the major tab. Each of these tabs is to contain the deliverables as outlined above. Be certain each component and parts of components are clearly marked.

Be certain to update your Project Plan. Include this as an additional tab of equal size as the other four. Also be certain to have a working degree of granularity for this plan (that is, tasks, assignments, etc.)

Phase III. Requirements Specifications – due June 18th

This deliverable will have five main parts: We will discuss at length in class…

Part 0: Clean up / fix any problems noted in Deliverable #2.

Part 1: Scope

1. Include an Executive Summary of any changes in scope realized by developing the details of this deliverable

described below.

2. Final scope document (single page)

3. Context-level DFD (level-0) – contains application in a box and external agents only.

4. Context level Use Case diagram: Scope overview: Contains use cases and actors only. Single page.

Used to support visual understanding of scope and boundaries. Shows actors and use cases only.

Part 2: Functional Specifications: The conclusion (sic) of our Use Case Modeling to support functional requirements

1. Package Overview: Packages of Use Cases – Single page – overview of Use Cases and single or two

sentence description.

2. Use Cases (or main paths) contained in each package (organized ‘by package’ ‘by use case’)

Needs to contain additional sentence or two describing the thrust of the package.

3. Use Case Index and Descriptions – Single page organized by subsystem / package as best

possible.

4. Use Case descriptions (narratives) Completed.

Per Use Case:

a. Basic course of events

b. Alternative and Exception paths – as appropriate (see lecture slides); add narratives.

c. Add Sub-flows as you consider necessary.

d. Add Traceability Indicators to Use Case description format.

e. Add extension points, separate alternative sections and subflows as you feel your

use cases warrant. I will leave the extent to which you do these up to your team.

Part 3: Supplementary Specifications:

1. Glossary – make this comprehensive! (alphabetical also) (repeated and expanded from Part 1)

2. Domain Model – Connect the business entities together. Include full attributes – but no ‘helping’ entities such as

bridge entities, etc. Use only those that are referenced in Use Cases. Provide ‘domain’ relationships, including all structural relationships such as 1:n, n:m etc.

3. Non-functional Requirements

a. System-wide requirements - characteristics that transcend individual use cases, such as

persistence, security, performance, distribution, etc.

b. Constraints; e.g., regulatory, platform, development methodology, language, application development

standards, etc. risks

c. Business Rules: Rules for the way business is conducted…

e.g. an ABET-accredited school only needs to submit an application form plus their constitution

and bylaws in the initial application.

an institution can submit no more than two students for scholarship: one from an

undergraduate program and, if appropriate, one from the graduate program.

an applicant for a UPE scholarship must be a member of UPE.

Part 4: Revisited Data Models

1. Executive summary of actions taken from deliverable #2 to deliverable #3 to your data model.

2. Conceptual model

3. Fully-attributed model

4. Normalized model

Part 5: Activity Diagram for Use Cases.

For each Use Case, you are to create an Activity diagram. This activity diagram will contain the basic path and all alternative paths associated with the Use Case. Also, you are to annotate the diagram with entity classes, as they are created or as their attributes are modified – thus making this an object-model as well. We will discuss in class and I will provide examples.

But FIRST, I’d recommend that, as a team, you sit down and map out a plan (time table) for accomplishing these tasks below. They are substantial. Don’t apportion one task per individual. Be sure to check each team member’s work to ensure consistency.

Project Notebook: Inside the ‘major tab’ citing Phase III deliverables divided into five major divisions (tabs) easily identified. Major items within each of these major tables are to be also separated if possible. Ensure everything is distinguishable. Label these clearly (use typed indicators on tabs).

There may be changes in Scope needed. Please do so. Update your project plan to reflect these activities PRIOR to starting them. Map out your plan to accomplish this work. There is a lot to do here, and planning is essential.

Phase IV. Application Architecture, Data and Interface Design (Inputs and Outputs) due: June 30th, 2003

This section will include the application architecture (physical data flows), data base design and the input and output prototyping required to satisfy requirements for data input and retrieval output

Recommendations: Read chapters 10 -14 in your textbook.

Deliverables:

Part 0: Clean up any problems from previous deliverables. Finalize the activity diagrams for each use case.

Part 1: Application Architecture

Primary technology to be used is the Physical Data Flow Diagram (PDFD)

Address architectural features. Figures 11-12 and remaining figures are particularly good

within your textbook.

You are to clearly show the distribution of architectures with supporting communication lines. Show all tiers (database server, application server(s), clients. Show database tables associated with the database server. A narrative explaining the PDFD (at all levels) is to accompany each PDFD.

Part 2: Database Design

This is to include your database schema – the physical model for your database.

A general narrative may accompany the schema to explain your model.

Part 3: Prototypes: System Interfaces (inputs and outputs)

All inputs and output screens, forms, reports, inquiry prototypes are to be included in this section.

Be sure to cite the technologies used to realize these items.

Accompanying each of these may be a narrative description and rationale for your interface design.

Part 4: Update the Project Plan

This time, detail is essential. Show the individual tasks, assignments, intermediate deliverables and their due

dates, etc.

Part 5: Signature Sheet for Client.

Project Notebook:

The project notebook is to have a major divider indicating Phase IV. This is to be clear and prominent and should align with previous phase deliverables. Be sure, if these don’t not already do so, that the Phase deliverable dividers line up and that the individual task deliverables therein are ‘inside’ of the larger, more prominent Phase deliverable dividers and tabs. Be sure each component of the Phase IV deliverables is physically separated from each other and easily located. If you have a question, please contact me.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download