ProjectProject DeliverablesDeliverablesThis is an iteration-based project. All artifacts of each Iteration are to be posted in Rational Team Concert (RTC), which is separately documented with accompanying tutorials on my web page. See Course Lecture Notes. (exceptions will be noted ahead)

Each Iteration consists of a number of ‘deliverables’ in the context of RTC are referred to as Work Items

Initially – for Iteration 0, you may include Work Items in the RTC/Change and Configuration Management (CCM) portion of RTC. The deliverables in Iteration 0 are items of work. Work Items are activities that produce ‘artifacts.’

Later, when specific products are developed, they will be entered as ‘artifacts’ in Requirements Management (later, in Quality Management)

Work items are activities usually resulting in producing an artifact constituting part of each deliverable.

Executive Summary Every iteration will include an Executive

Summary.

This is to be a single page document and should summarize the contents of the iteration:

What work items were undertaken (list)

What work items may have been changed Note: revising artifacts is the norm in an

iterative approach to software development. Identify Risks as a Work Item (elaborated upon ahead).

Executive Summary is likely developed by team lead and backup.

Rational Team Concert

Rational Team Concert (RTC) will be the tool of choice for CEN 6016 and CEN 6017.

All work items and artifacts for each iteration will be posted to appropriate places in your team’s project area.

A set of tutorials on RTC is under development for your use and will guide you.

Rational Team Concert Tutorials include basic information on ALM/CLM, creating and

managing a Jazz account, creating a new project, managing requirements with Rational Requirements Composer (RRC), creating iterations, work items, establishing the Eclipse client or Visual Studio for your use, source control (your programming), change sets, and linking work items and change sets, traceability, and much more.

While tutorials currently exist (see Block 2), these are under revision, as most were developed two years ago.

The team is responsible for familiarizing themselves with this very popular development environment.

Work Items Each iteration consists of work items undertaken. Each Artifact will be posted to your project area in RTC,

along with the name(s) of the individual(s) primarily responsible for accommodating each work item.

Some of these items may be Word documents, others graphical models, tables, answers to questions, and assessments. (A few initial work items will be placed in Configuration and Change Management (SSM) part of RTC.)

Some work items will be done by individuals; others by more than one team member.

Work Items will include outputs of your basic work items. Examples include all business modeling, requirements, analysis and design, testing, management, deployment, and implementation modeling artifacts and much more.

Grammar, Wording, and Professionalism

Under NO circumstances will poor grammar or ill-conceived sentences be considered acceptable work. Remember: you only get one chance to make a first impression. Poorly done work will really hurt your grade and perception of what otherwise might be high-quality work. This is a graduate level course and mature, professionalism is expected.

EACH work item of EACH iteration must be reviewed

While the Quality Assurance Manager (ahead) may be the one primarily responsible for grammar and wording, please recognize that this is a TEAM responsibility!!

I cannot stress too strongly emphasis placed on professionalism in organization, content, presenting and reporting.

Iteration #0Iteration #0due Wednesday, 10 Sep 2014 – Midnightdue Wednesday, 10 Sep 2014 – Midnight

Team Formation, Project Identification, Roles,

Methodology, Special TopicsInitial Risk Assessment

Important Be certain you add me as a project participant along with

other team members. Give me all permissions, please. (I may set this up myself)

Iteration 0 will be graded.

As I enter comments on the artifacts in RTC, please share with all team members. Even if the ‘comments’ I offer only go to the work item owner.

I will be putting all your grades in Blackboard at this time.

Work Item: Produce Executive Summary

Artifact: Executive Summary Project Title Standard contents (see previous generic description) Project Lead (interim or permanent) will develop the

Executive Summary Describe in summary form the work items undertaken

for this iteration. This is only an overview Include a list of team members and assigned roles an

backups Include any issues encountered. Include the Iteration assessment text (see ahead) Word Document, unless otherwise directed.

Work Item: Team FormationArtifact: Include in Exec

Summary List the team members by name and the role(s) each

will undertake.

Use the descriptors on the next slide. These are to be included in the Executive Summary, a Word Document.

Please realize this may change and be modified as individuals take on new roles as the project evolves, but you should make every effort to nail down roles.

Include in Executive Summary

Work Item: Create Team Roles and Responsibilities

Artifact: Role and Backup Identification Team lead and backup: Team Quality Assurance Manager : (responsible for ensuring

all work items are properly reported, formatted, included on time and more; responsible for work item reports to RTC)

Business Analysts (Requirement Specifications) Application Designers (Modelers; architects) Application Programmers (API / IDE specialists) Database specialists (database designers; interfacing…) Testing and Reporting (business analysts; others) Include in Executive Summary

Work Item: Develop Iteration Assessment

Artifact: Iteration Assessment Frank assessment of iteration 0. (5-10 minutes) One or more team members will report on Iteration 0

in classroom setting. (good, bad, and ugly) What can be done to improve this process?

Iteration 0 will be graded. Grades: not team grades. Individual Peer Reviews must be submitted no later

than class time on the date on which the Iteration Reports are due/presented.

Brief Presentation: accomplished by Team Leader Include in Executive Summary

Work Item: Develop Risk ListArtifact: Risk Management

Plan Risks will be identified, quantifed, and prioritized.

A Risk Management Template is provided on my web page. At this point, however, we are only after ‘an appreciation’ of risk. There is no need to fully document a project that is not yet defined. But Risk is a Living Document, so give it a shot as best you can. It will be revised in each iteration and made more complete.

Try to understand risk identification, risk mitigation, risk computation, etc. This is a separate Artifact.

Work Item: Develop Approved Project Description

Artifact: Project Proposal Plan Topic must be pre-approved well before it becomes a part of this

iteration. Include full write up.

Title Description – several paragraphs Need – Significance? Usefulness? Clients? Availability of Resources to Specify

Sources of knowledge Overall Software Development Plan

It is conceivable that you may not have this item thought out yet. But give it a shot. Will change later.

This is to be a Word Document. Template provided. See web page This is a separate artifact.

Rational Team ConcertRational Team Concert

The following artifacts are to be The following artifacts are to be inserted into RTC:inserted into RTC: Executive SummaryExecutive Summary Risk DocumentRisk Document Approved Project Description ProposalApproved Project Description Proposal

Iteration #1Iteration #1to be refined…to be refined…

Business Modeling(Domain Analysis)

Iteration #1 Business ModelingBusiness Domain Analysis

Due: Wednesday, October 3rd 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;

Iteration 1 – Business Modeling and Domain Analysis Work Items

Team Member’s Statement of Work (See link on web page)

Business Vision Document – See templates. Business Use Case Model – See templates

Use an approved graphical tool. (Tentatively assigned.) Business Glossary – See templates Business Rules – See templates Business Risk List – See templates; Revise Iteration 0 This is a hefty assignment. Start early!!

Work Item: Executive Summary

See slide 2. Overview of the iteration from top to

bottom. No more than one page.

Work Item: Statement of Work

You are to include each individual team member’s statement of work (SOW)

Develop a document of sequential SOWs and include as a work item.

Work Item: Business Vision Document (1 of 2)

Use the appropriate forms on my web page: Link to Useful Templates You Will Need. This is a Word document.

This captures the purpose of the application domain. What services are they providing? What are they all about? Who are the customers? What are the goals of this business? Primary stakeholders?? Points of contact: emails and telephone and any notes

such as availability / non-availability; where they work, office symbols, tech support, BAs, etc.

This is NOT a product vision document (the product you will develop). This is about the business, enterprise, environment.)

Business Vision Document (2 of 2)

Use the Business 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. Normally, in “Stakeholders,” we address those interests

NOT from a project perspective but from an organization’s perspective: customers, users, etc. In our case, address the interests of the stakeholders for the projects you are undertaking.

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.

Work Item: The Business Glossary (1 of 2)

Use the Business Glossary template. 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. Nouns.

A Student Registration system might have key words like Course, Schedule, Payment, Registration, Student, Professor, ….

What is needed here are acronyms, important definitions, basically the jargon of the organization. These will be heavily referred to when we do use cases!

Business Glossary (2 of 2)

Another key component of domain analysis is the domain model (next deliverable). Here, we supplement the glossary by adding in a graphical mode – business entities, their relationships and associations:

(What’s important in business entities are the ‘attributes.’ So, for example, if you were defining a Student business entity, you might include things like: ssan, classification, gender, major, gpa, projected graduation date, ACT/SAT scores, etc.

We do NOT worry about (and do NOT include) methods

This, however, is for the next deliverable.)This, however, is for the next deliverable.)

Work Item: The Business Rules Use the Business Rules template.

See examples on my web page. These are merely samples.

Be careful: The samples on my web page are Rules for an Application.

In principle, the formal approach is to develop business rules for the entire organization and not for the specific application domain.

For our projects this year, you are to develop business rules for the specific application domain for which we will be developing the application.

Business Rules are policy declarations or conditions or guidelines that must be satisfied in running the business.

Work Item: The Business Risks Use Business Risks template. What are some of the risks that the organization

and developers must be constantly assessing: Clients: market share, technology awareness, new

statutes from Washington D.C., the state of Florida; trends in the industry; demographics;

Developers: Revisit your Risks from Deliverable 0 to update: include environmental considerations; personnel risks; technology risks; economic risks; time constraints; give this some thought….

Iteration #2due: Wednesday, Oct 17th

Executive SummaryIterate Previous Work

Team Statement of WorkDomain Model

The Product Vision Document (Problem Statement)Features List

Quality Manager Assessment

Work Item: Domain Model

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

(responsibilities) – only attributes and connections (associations/ dependencies)

There is a decent link to a student example on my web page.

Domain Model - continued The Domain Model is an extension of Deliverable 1.

It deals with the enterprise / organization and is essential to understanding the environment (in terms of the business entities) within which the application to be developed will function.

It is an essential artifact.

See Lecture slides on the Domain Model and the textbook.

Work Item: Product Vision Statement See lecture slides and templates provided on my

web page. I am after a short description (paragraph at most)

for the Product Vision. This results in scoping the project (together with

Needs and Features ahead.

The 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 referenced articles.

The QA individual must develop a Traceability Matrix that maps Features back to Needs (here). So the SQA will have two matrices prepared. (See sample article for guidance)

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. Needs are higher level and often include very high level statements of desired needs not all of which are features which can be implemented in a system.

The Features drive the development of the use cases – our functional requirements, and the development of our supplementary specifications – our non-functional requirements.

More on Sample Features Features are not behavioral (like the Use Cases - coming).

These are typically text descriptions. See text books. 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.

Iteration #3due: ~Wednesday, Oct 31st

Executive SummaryIterate Previous Work

Team Statement of Work Use Case Index

Use Cases including all Façade and Filled (basic use cases and those containing happy path

Traceability MatricesQuality Manager Assessment

Iteration #3 – Work Items - Overview 1. Executive Summary.

Summarize the Iteration. 2. Iterate / Review / upgrade previous artifacts including the Features List

Based on evaluation of your iteration, Your changes should be annotated in the Executive Summary. All previous deliverables should be reviewed and potentially updated.

3. Team Statement of Work Assigning responsibilities to different roles to be accommodated on the team. This text

document should be developed by the team leader in concert with individuals. Team leader must provide direction and guidance. All tasks and sub-task-ids should be clearly delineated. Team members decide on allocation of Work Items.

4. Update Features List to cover but not exceed Scope; Add comments. 5. Provide Use Case Index (see slides for examples and description) 6. Provide Use Case Diagrams for each use case specification (may

include with the Use Case Specification (Narrative). 7. Provide Use Cases: one set of filled use cases (use case that includes

only the happy path) 8. *Provide complete use cases (all alternatives / exceptions included)

(coming) 9. Provide Traceability Matrices for Needs to Features to Use Cases and

vice versa.. 10. Quality Manager’s certification artifacts are reviewed.

Work Item: Executive Summary

As previously done. Summarize the Iteration.

The good, bad, and ugly. Assess how all went and ways to improve

Overview of artifacts developed and your assessment of them.

How did the team do? No more than one page.

Work Items: Review Previous Artifacts

Review primary Needs and Features recognizing team members know more about the application domain.

Review and update the domain model to include additional / modified business entities.

Work Item: Statement of Work

You are to include the Statement of Work from my web page updated with this Iteration’s efforts.

Include each individual team member’s statement of work (SOW). I am after a personal self-assessment as well from

individuals. Remind all team members to email their

personal self-assessments / team assessments to me.

Work Item: Update Features List

Update Features list with current knowledge.

Work Item: Create Use Case Index

See examples on my web page. This is a one-pager listing the use

cases to come. Each entry should have a short user-

stories as the description of the use case.

Work Item: Develop Use Case Diagrams

Develop Use Case Diagrams to include actors and use cases.

You may include individual use-case diagrams with their specific use case specification, if you wish.

Not a bad idea, however, to have them all listed one after the other here…

Work Item: Develop Use Case Specifications

The use cases are to be (first) a set of façade level use cases.

Secondly, each use case is to have a second one that includes a the basic couse of events.

Be aware, the next iteration will have all alternatives / exceptions developed…

Work Item: Develop Traceability Matrices

There needs to be a traceability matrix outlining needs mapped to features mapped to use cases.

See examples in my slides and in the article by Leffingwell.

Work Item: Quality Manger’s Certification

Need sign off that the entire team approves of the deliverable constituting the third Iteration.

Iteration #4due: 26 Nov 2012

Very important deliverable as we approach the end of this semester.

Work items and artifacts follow (you know the drill by now): 1. Executive Summary 2. SOW 3. QM certification. Ensure ALL review these documents 4. Features List (taken from Product Vision will likely be

okay) 5. Traceability Matrices for Needs to Features to Use Cases 6. “Complete” Use Cases with all alternatives and

exceptions. Use Case Diagrams too. Precede this with the Use Case Index.

7. Initial Data Base Design. (Team 1 will present theirs.) 8. Upon feedback from me, please down load in hard copy

the use cases, traceability matrices (from product vision and this one), and the data base design.

9. Team 1 is to present their artifacts.

4. Features List

The Features List will be input to the COJ and to UNF (re your team).

The Clients will prioritize their needs based on these features. These constitute the product backlog owned by clients.

Development teams (soon) will develop their own Sprint backlogs (we will discuss)

5. Traceability Matrices

Traceability Matrices mapping Needs to Features to Use Cases are needed.

See samples for format. Essential for tracking our progress

via Sprints and ensuring we are working on real requirements.

6. “Complete” Use Cases

Essential component of the iteration. Preceded by the Use Case Index (one page) and accompanied by Use Case Diagrams per use case, you are to significantly expand your use case specifications to include all scenarios worthy of expansion.

Several samples are available for your study. This essentially ‘ends’ or creates a base line of

functional specs, so it is essential that you attempt to capture all that needs to be documented.

Of course, the use cases are ‘never’ totally complete.

7. Initial Data Base Design

Your Work Item here is to develop and document your first cut at a viable data base design given your many constraints.

Visual modeling is critical along with text to accompany / explain your modeling

This will be supplied to our clients (COJ and UNF) for verification, so we are after your best attempt at a good data model.

8. Preparation for Incremental Delivery to Clients

Be prepared to download, print, and provide a professional portfolio of your work to be submitted to the client.

More later on format, etc.

Iteration #5due: 5 Dec 2012

In lieu of a final exam, we have a short term iteration for these work items..

1. Exec Summary, SOW, QM Certification. 4. Refinements of iteration 4. These could be

significant. 5. Initial prototype of your Interface. 6. Upon feedback from me, please down load in

hard copy of revised documentation from iteration #4 plus images of your interface design.

7. Team 3 will present theirs for the class More later on this deliverable.

That’s it for now. Starting in January, we will be deeply

immersed in development starting with the architecture followed by the MVC design strategy and implementation.

All teams will, upon prioritization of needs by our clients (their product backlog), will decide your own sprint backlog. This will take participation of all team members in deciding the contents of each sprint and commitments thereto.

We will talk more later, but from here on, the development will be directed by the team using a Scrum process – as nearly as possible.