Team 5 Crystal Stairs Dashboard Application

1
Team 5Crystal Stairs Dashboard Application

• Developers
• Sai Nallapaneni
• Prithvish Tella
• Sirisha Movva
• Manish Khanna
• Jaskiran Sodhi
• Abhijit Mathur
• Martha Saenz

• Clients
• Rick Capella
• HR Manager, Crystal Stairs

1
2
Agenda

• Summary
• Operation Concept Description
• Prototype
• Requirements
• Architecture
• Life Cycle Plan
• Feasibility Rationale
• Acceptance Test plans and cases

2
3
Crystal Stairs Inc. Background

• Largest nonprofit child care and development
  corporation in California
• Through the efforts of the Board, staff and many
  professional and community partners, Crystal
  Stairs programs and services enhance the quality
  of life for thousands of children and families in
  Los Angeles.
• Funds from government contracts and a growing
  number of foundations and donors.

3
4
Introduction to Project

• Goals
• The HR department of Crystal Stairs seeks to
  implement a system of metrics to assist the
  department in measuring its effectiveness.
• The organizations seeks a Dashboard application
  which would be used as a presentation tool to
  display these metrics.

4
5
OPERATIONAL CONCEPT DESCRIPTION

• Prithvish Tella

6
System Purpose

• A dashboard to measure HR alignment with
  organization mission and goals.
• Help in making better presentations to drive the
  data in an animated manner.

7
Changes in current system and Deficiencies

• The current system at Crystal Stairs is a manual
  system.
• The presentations to the management about
  departments performance also contain just
  numeric data.
• The deficiency here is that a lot of time is
  being wasted, and also the presentations are dull
  and not interactive.
• The team has been working on the prototype as
  discussed in the LCO ARBs and has been updating
  the client.

8
Proposed new system

• A dashboard that can get data from Excel files.
• This is how Crystal Stairs is currently
  collecting and storing data.
• Use animated display items like dials and
  bargraphs to make interactive presentations

9
System Boundary
10
Desired Capabilities and Goals

• The dashboard should upload and parse Excel
  files.
• It should have two types of display items.
• The user should be able to select the number of
  display items that he wants to be shown.
• The client should be able to configure each
  display item.
• Animations should be shown on the display items.

11
Top-Level scenarios

• Better analysis and interpretation of the
  collected performance data through visuals.
• Reduce employee time in generation of reports
  from the collected data.
• Improved and more informative presentations to
  keep the management involved and informed with
  the various performance issues.

12
PROTOTYPE
-Sirisha Movva
13
Sample Excel Sheet
14
Main Page
15
Upload Screen
16
Selection Screen
17
Display Screen
18
REQUIREMENTS

• -Jaskiran Sodhi

19
Outline

• Project Requirements
• Capability Requirements
• System Interface Requirements
• Level of Service
• Evolutionary Requirements

20
Key Project Requirements

• Zero monetary Cost
• Delivery in 24 weeks (Architecture
  Implementation)
• Developed as an independent application and
  delivered on a disk.
• Training on the usage of the application
• Should run on the existing systems at Crystal
  Stairs i.e. Windows based systems.

21
Key Capability Requirements

• Uploading and Parsing of the excel files
• Graphical display of the parsed data in two
  modes Bar Graphs and Dials.
• Configuration of the dashboard in terms of
• Selection of the number of the Bar Graphs/Dials.
• Selection of the excel sheet for a particular
  Control.
• Switching between columns by tab selection
• Dials showing the animations.

22
Key System Interface Requirements

• Standard Excel files for display, the excel files
  should be in a standard format as proposed by the
  design team.
• Stand alone application with no web based
  interface.
• Maximum number of Dials/ Bar Graphs on the
  dashboard is limited to 4.
• Error Message Notification for the validation
  errors like an attempt to upload a file with some
  other extension.

23
Key Level of Service Requirements

• The response time for the change in display i.e.
  when the user switches between tabs should be
  within 1 second.
• The user should not take more than 15 minutes
  time for configuration.
• It should be easy to configure and use it should
  not take user more than five hours to get used to
  the system.
• The application shall be available till the
  desktops are up and running.

24
Evolutionary Requirements

• The system detects the wrong format of the excel
  file and displays the error if it is not in the
  standardized format as proposed by the design
  team.
• The user should be able to save the configuration
  of the file and access it later on.

25
SYSTEM AND SOFTWARE ARCHITECUTRE DESCRIPTION
(SSAD)

• 
  
• 
  -Manish Khanna

26
Purpose

• Builds on the Concepts developed in OCD and
  provides an Architecture design that
• 1. Satisfies the System requirements
• 2. Can be implemented in the given time
  frame.
• Explanation of the features, behaviors and
  capabilities of different components of the
  Dashboard System

27
Changes from LCO

• New Artifact added (Dropdown)
• Selection of Excel sheet
• One mode of Operation
• Display also used in Configuration
• Configuration at the time of Display
• Technology independent Model (Why?)
• Most members of Current team not
  continuing in CS 577b
• Flexibility of choosing own technology,
  platform etc

28
Outline

• System Architecture
• Actors and artifacts
• System Model
• Technology Independent Model
• Deployment diagram
• Information Class Model
• Use Cases
• Sequence diagrams

29
System Architecture (Actors and Artifacts)

• System Actors
• Actor 1 HR Personnel
• Actor 2 HR Management
• Actor 3 Top Level Management
• System Artifacts
• Dashboard Interface
• Standard Format Excel File
• Display Sections
• Dials
• Bar Graphs
• Tabs
• Dropdown

30
System Architecture (System Model)
31
Technology Independent Model (Deployment)

• Hardware component
• Client Machine (PC)
• Software Components
• Parsing
• Dashboard Interface
• Animation

32
Technology Independent Model (Information Class
Model)
33
Use Cases

• Use Case 1 Excel File Generation
• Use Case 2 System Configuration
• Use Case 3 Data Visualization
• Use Case 2 Excel File Maintenance

34
Use Case 2 System Configuration
35
Use Case 3 Data visualization
36
Life Cycle Plan
Sai Nallapaneni
36
37
Issues/Concerns

• Personnel Continuity
• Most of the members not continuing in CSCI577B
• Target development team size is 5 (optimistic)
• Recruit people from CSCI577b students or DR
  students
• Widely available skill set Java/C and Flash,
  Perl or other scripting languages
• Risk
• Project has elements of risk due to Animation
  involved and a completely new team taking over

37
38
Plan for next phase
39
Jan. 18 - Re-form teams Feb. 5 - Draft
LCA-Rebase line on Web Feb. 12-15 - LCA-Rebase
line ARB reviews Feb18 Apr 3 - Core Capability
Development Apr. 10 - Transition readiness
review draft Apr. 15-16 - Transition Readiness
Reviews May 8 - Product Delivery
40
Project Manager
COCOMO says that I need 4 programmers
Software Developers
41
Core development cycle (approx 45 days)
Training ( 5 days)
Iteration 2 (10 days) Add-ons and other feature
Iteration 1( 30 days) Core capabilities
42
Production Phase
42
43
Iterations
44
Transition Phase
44
45
Team MembersRoles Responsibilities
45
46
Cost estimation

• There are three modules-
• - Processing Module (Parsing)
• - Display Module (Dashboard Interface)
• - Animation Module (Animation)

46
47
COCOMO II Cost Estimation
47
48
COCOMO Analysis Updates

• Initial analysis had to be changed to
  post-architectural model
• Bought information through research
• New factors fed into COCOMO according to the
  module
• Project now within feasible range
• Construction phase planning based on COCOMO
  Estimation

48
49
FEASIBILITY RATIONALE DESCRIPTION
-Abhijit Mathur
49
50
Outline

• Business Case Analysis
• Cost Analysis
• Benefits Analysis
• Return on Investment (ROI)
• Risk Assessment

50
51
Business Case Analysis- Cost Analysis

• Hardware Costs Software Costs

51
52
Business Case Analysis- Cost Analysis

• Personnel Costs

52
53
Business Case Analysis- Benefits Analysis

• Intangible Benefits
• Escalate HR Departments credibility
• Acquiring support for HR Departments initiatives
• Tangible Benefits
• Time Saved

53
54
Business Case Analysis - ROI
54
55
Business Case Analysis - ROI
55
56
Business Case Analysis- Break Even Analysis
56
57
Risk Assessment

• Personnel Shortfall
• Most of the team members are not continuing in
  CSCI 577b.
• The team will document each and every detail of
  the project so that the 577B team is able to
  follow the system requirements and the system
  design.
• Animation
• The 577b team should have a member with some
  experience in animation.

57
58
ACCEPTANCE TEST PLANAND CASES

• Martha Saenz

59
Acceptance Testing

• Functional Testing
• Provide coverage to requirements
• Test Cases
• Single Metric Dial/Bar Graph
• Single Column, Single Worksheet
• Multiple Column, Single Worksheet
• Two Metrics Dial/Bar Graph
• Incorrect File
• Incorrect Format

60
IIVV Observation

• Integrated Feedback
• Important evolutionary requirement was captured
  (saving configuration)
• Documents did not capture a lot of the behind the
  scenes ground work that happened in evaluating
  different tools and reduction of risks

61
THANK YOU

• Questions?