Final Status Report

1
Final Status Report
Marvel Electronics Home Entertainment
Team 5

• Sonali Pagade Nibha Dhagat
• David Ziman Reginald Bradshaw II
• Sebastian Schagerer Janet Xu Phan

2
Purpose for Todays Meeting

• Report on progress made since inception
• Review Team Organization, Brain Storming, Vision
  Document
• Show past few weeks progress
• Standish Report
• Use Case, Structural, and Behavioral Diagrams
• Non Functional Requirements, Mockup

3
Project Deliverables

• To Do
• Finish SRS
• Peer ratings
• Project Evaluation
• Completed
• Vision Document
• Project Plan Draft
• Status Report 1 2
• Final Status Report

4
Organizing the Team

• Exchanged contact information
• Setup Yahoo! Group for communication and file
  sharing/storage
• Group Meetings to discuss project plan

5
Brainstorming Session

• Brainstorming for product needs and wants
• Brainstorming session with appropriate
  stakeholders
• Revised Brainstormed Ideas
• Accepted or Rejected wants/needs
• Created a comprehensive Feature list

6
Vision Document Sections 1-7

• 1. Introduction
• 2. Positioning

7
Section 3 - Stakeholders

• Understand who is involved in the current
  business process
• Understand who will be involved in the improved
  process
• Identify features with Stakeholders for
  traceability

8
Vision Document Sections 4-8

• 4. Product Overview
• 5. Product Features
• 6. Constraints
• 7. Quality Ranges
• 8. Precedence and Priority

9
(No Transcript)
10
Vision DocumentSections 9-10

• 9. Other Product Requirements
• 10. Documentation
• User Manual
• Online Help
• Labelling and Packaging
• Appendix A. Feature Attributes
• Status, Benefit, Effort, Risk, Stability, Target
  Release, Assigned To, Reason

11
Standish Report

• Factors Contributing to Project Success
  According to Standish Report
• 1. Executive Management Support
• 2. User involvement
• 3. Experienced Project Manager
• 4. Clear Business Objectives
• 5. Minimized Scope
• 6. Standard software Infrastructure
• 7. Firm Basic Requirements
• 8. Formal Methodology
• 9. Reliable Estimates
• 10. Other
• The cost of incorrect, misunderstood, and not
  agreed upon requirements affects the customers
  and developers in terms of time, money, and lost
  opportunities.

12
Standish Report

• Applying the CHAOS Ten in our project
• User Involvement
• Identified the Users and Customers
• Stakeholder and User description in the Vision
  Document
• Gathered needs from Users and Customers
• Role Playing
• Interviews
• Brainstorming
• Regular Meetings

13
Standish Report

• Clear Business Objectives
• Identified the following in the vision document
• Business Opportunity
• Problem Statement
• Product position Statement
• Product Perspective
• Product Overview
• Also performed
• Market Analysis
• User Background Analysis

14
Standish Report

• Minimized Scope
• Defined Deliverables
• Defined Functionality
• To help you define your scope, answered the
  following questions
• What processes (and what are not) are included in
  the scope of our project?  Where does each
  process begin and where does each process end?
• What systems (and what are not) are used in these
  processes are included in the scope? 
• What organizations (and what are not) involved in
  these processes are included in the scope? 

15
Standish Report

• Firm Basic Requirements
• Elicitation
• Statement of work/task definition.
• Interviews
• Group brainstorming.
• Observation.
• Prototyping
• Approval process for all the requirements for
  both functional and non-functional requirements

16
Standish Report

• For interpreting and agreeing upon requirements,
  in weeding out requirements not considered,
  identifying potential or real bottlenecks, or
  deriving requirements we used
• UML Use Case diagram.
• UML class diagram.
• UML sequence diagram.
• Non-Functional SIGs
• Reliable Estimation
• Based on scope of the project prepared a
  Preliminary master schedule
• For deliverables according to the deadline
• Resources required to complete a deliverable.

17
Standish Report

• Traceability of requirements
• Each Use Case used (in the Functional
  Requirements) can be traced back to the
  respective requirements of the project.
• Each Non functional requirement can be traced
  back to the features represented in the Vision
  Document.
• Requirements can be traced back to the Product
  Features defined in the vision document.
• Each Feature can be traced back to the wants and
  needs of individual customers (which were
  generated in the elicitation processes).

18
Stakeholders wants and needs
Vision Document
Functional Requirements
Non-Functional Requirements
Models
19
User Case Diagram
20
Structural
21
Register Create Profile,Restration
22
Advertising Company logo,links,Specials,
Highlights, Cookies
23

SECURITY



INTEGRITY

AVAILABILITY

CONFIDENTIALITY


ACCURACY
COMPLETENESS

AUTHORIZATION


CONSISTENCY
REGISTRATION
_




PERFORMANCE
PASSWORD
USERNAME

_


INDIVIDUAL PASSWORD
SHARED PASSWORD
24
PERFORMANCE
CAPACITY
SPACE UTILIZATION
THROUGHPUT
RESPONSE TIME

IMPROVES RESPONSE TIME



COMPRESSED FORMAT
INDEXING
SINGLE LEVEL
MULTI LEVEL
CATEGORY BASED
KEYWORD BASED
25
RELIABILITY
INTEGRITY
ACCURACY
AVAILABILITY

!
COMPLETENESS
EFFICIENCY
CONSISTENCY
MINIMUM NUMBER OF HOPS

PERFORMANCE (RESPONSE TIME)
26
MAINTAINABILITY

!
BREAKDOWN TIME
EXTENSIBILITY
_
AVAILABILITY
TESTABILITY
UNDERSTANDABILITY

MODIFIABLE
USABILITY
USER FRIENDLY
27
USABILITY
FLEXIBILITY
USER FRIENDLY

RELIABILITY
ACCESSIBILITY
LANGUAGE
AESTHETICS
CHANGE/CANCEL ORDER
MULTILINGUAL
DEFAULT
28
Mockup - Registration
29
Mockup - Login
30
Mockup - Advertising/Promotions
31
Search MethodsAdvanced Configuration
32
Mockup - Purchase/Shipping
33
Mockup - Customer Service
34
Summary Things Learned

• Standish Report
• Traceability
• Tools
• NFR Modeling

35
The next two weeks

• Finish work on SRS
• Peer Ratings
• Project Evaluations

36
Questions?
???