THSA Website Project

1

• THSA Website Project
• LCO Architecture Review
• Team 12
• 10/26/2007

2

• Agenda
• Introduction
• IIV V
• Operational Concept Description
• System Software Requirements Description
• Prototype
• System Software Architecture Design
• Life Cycle Plan
• Feasibility Rationale Description
• Quality Focal Point

3

• Project Name THSA Website
• Client Poonchana Thitametakul
• (Thai Student Association, USC)
• Team 12

4

• Project Manager and Feasibility Analyst
• - Amrit Pal Singh
• Operational Concept Engineer
• - Ishita Gupta
• Prototype Engineer
• - Dhwanit Purohit
• Requirements Engineer
• - Niket Ashesh
• System Architect
• - Khushboo Bindlish
• Life Cycle Planner and Assistant Shaper
• - Kunal Jain
• IIV V and SRE
• - Yunsheng Lei

5
Integrated Independent Verification Validation
(IIVV)

• Yunsheng Lei

6
Teams strengths and weaknesses

• Teams strong points
• Operational View Good collaboration between
  team members
• Technical View Strong object-oriented
  programming knowledge. Follow LeanMBASE
  guidelines. Incorporate TAs and IIVVs feedback
  into every revision of artifacts.
• Teams weak points
• Operational View First time working with a
  client directly.
• Technical View Not familiar with web
  programming language PHP. First time working with
  COTS Drupal.

7
Project concerns and risks

• Technical concerns Requirements need to be
  clarified, Inconsistent requirements between
  artifacts.
• Solutions Review and refine WikiWinWin
  negotiation.
• Operational risks Transition from old system to
  new system.
• Mitigation Provide detailed administration tool
  manual and possible training.
• Source of observations
• WikiWinWin negotiation, Package evaluation,
  Client meeting notes, Progress reports and Team
  activities.

8
Operational Concept Description(OCD)

• Ishita Gupta

9
Contents

• System Purpose
• Shared Vision
• Benefit Chain Diagram
• System Boundary and Environment
• Proposed New System
• Element Relationship Diagram
• Business workflow Diagrams
• Desired Capability and Goals

10
System Purpose

• Social Networking
• Publicize and promote the ongoing activities of
  the Thai Club at USC

11
Shared Vision

• Common platform for the current students and
  Alumni to
• Communicate
• Share information
• Have fun

12
Benefit Chain Diagram
Members/ visitors
Logging into the system/ Registering/ Visiting
the Site Tour
Teaching Staff (577a Teaching Team)
Authenticating
Guiding and Validating
Various services like pictures uploading, message
exchanging etc.
Better interaction, secured data

Participation growth, Increase in number of
members
Development of THSA website
Better performance and Reliability
User satisfaction
User-friendly and Interactive website
Analyzing the requirements and designing the
system
Securing data
Suggesting new changes
Verifying, managing and maintaining the website
Proposing new features
Developer and IIV V (Team 12)
Administrator/ Maintainer
Client
Contribution Initiative
Outcome
Stakeholder
13
System Boundary Environment
Stakeholders and systems
List of Services
14
Proposed New System

• New interactive website for the Thai Student
  Association
• User is given access through a login
• Provides members with various features
• Uploading pictures
• Sending personal messages
• Writing on wall
• Posting announcements
• Writing testimonials
• Calendar notification
• Email Notification

15
Element Relationship Diagrams
Manages and monitors
System Administrators
16
Business Workflow Diagram for New User creating
an account
17
Business Workflow Diagram for Existing User
accessing the system
18
Business Workflow Diagram for Visitors visiting
the system
19
Desired Capabilities and Goals

• Capability Goals
• OC1 Personalized Account
• OC2 User Profile
• OC3 Interactive Tool
• OC4 Administrator Control
• OC5 Post Announcements
• OC6 Information Sharing
• Organizational Goal
• OG1 Increased number of members
• OG2 Increased participation in events
• OG3 Publicity of the Thai Club

20
Level Of Service
Desired Capabilities and Goals

• LOS1 Availability 24/7
• LOS2 Browser Capability

21
System and Software Requirements Description
Prototype

• Niket Ashesh
• Dhwanit Purohit

22
Contents

• Project Requirements
• Level Of Service Requirements
• Capability Requirements
• Language Requirements
• Evolutionary Requirements

23
Project Requirements
24
Level of Service Requirements
25
Evolutionary Requirements
26
Capability Requirements
27
CR-8
Prototype
CR-11
CR-1
28
CR-8
Prototype
29
Prototype
30
CR-2 CR-9
CR-10
Prototype
CR-6
CR-5
CR-3
CR-10
CR-3
31
CR-7
Prototype
32
Prototyping Tools

• NotePad (Open source text editor)
• HTML
• CSS
• Microsoft Paint
• Mozilla Firefox, Internet Explorer.

33
Web Development Checklist

• Navigation and Architecture
• Horizontal navigation is used for Friends
  feature using the
• angular symbols.
• Layout and Design
• The design of the page use same background
  image throughout
• the site
• Color
• The website uses same color combination
  throughout the site.

Note The web development checklist used from
CSCI 588 by Professor Steve Jacobs.
34
System and Software Architecture Design (SSAD)

• Khushboo Bindlish

35
Contents

• System Structure
• Information Model
• Use Case
• Mode of Operation
• Why use Drupal?

36
System Structure
37
Information Model
38
Use Case - User
39
Use Case New User
40
Use Case - Administrator
41
Use Case - Maintainer
42
Modes of Operation

• The system has only on mode of operation i.e.
  Execution Mode

43
Why use Drupal?

• Popular CMS tool
• Properties
• Simplicity
• Flexibility
• Affordability
• Good Documentation
• Freedom

44
Drupal Features

• Content Management Systems
• Peer-to-peer networking
• Picture galleries
• Messaging
• Wall Feature
• Calendar Notification
• Post Announcements

45
Life Cycle Plan (LCP)

• Kunal Jain

46
Contents

• Present Scenario
• Overall Strategy
• Roles Responsibilities
• Gantt Chart
• Monitoring Control Methods
• COCOMO II Cost Estimation

47
Present Scenario of LCP

• Assumptions
• There will not be major requirement changes after
  Win-Win negotiation agreements.
• The developer team is not changeable during the
  semester.
• The total time for system development is 24 weeks
  (12 weeks in 577a and 12 weeks in 577b).
• Team members will stick to the schedule.

48
Overall Strategy

• Model
• Win-Win Spiral Model
• Strategy
• Schedule As Independent Variable (SAIV)
• Risk Management

49
Roles Responsibilities
50
Roles Responsibilities
51
Roles Responsibilities
52
Gantt Chart
53
Monitoring Control Methods

• Weekly Progress Report
• Weekly Effort Report
• USC COCOMO Tool
• Weekly Client Meeting Reports
• Weekly Microsoft Project Schedule
• DART Tool
• Reviews
• IIV V
• Peer Review
• Team Reviews
• Feedback from CS577a staff

54
Cost Estimation

• There are 3 modules
• User Interface
• Database
• COTS Drupal

55
COCOMO II Cost Estimation
56
COCOMO II Cost Estimation
57
COCOMO II Cost Estimation
58
COCOMO II Cost Estimation
59
Feasibility Rationale Description

• Amrit Pal Singh

60
Contents

• Business Case Analysis
• Risk Analysis
• Process Rationale

61
Business case analysis

• Cost Analysis
• Benefit Analysis
• ROI (Return on Investment)

62
Cost Analysis

• Software and Hardware Costs
• Personnel Costs

63
Software and Hardware Cost
64
Personnel Cost
65
Benefit Analysis

• Tangible Benefits
• No financial benefit for this project.
• Intangible Benefits
• Time saved by THSA Community in managing the
  group activities.
• Promotion of Thai Club

66
ROI Analysis
67
ROI Analysis
68
Risk Assessment

• The project technology is new and unfamiliar
• The tools to be used to develop the system are
  new and unfamiliar. Team has no experience
  working with COTS
• Mitigation Plan Provide training on the new
  technology, as early as possible
• Performance Measure
• The client has not specified anything about
  performance measures, so all the testing would be
  done by the developers. If the client is not
  satisfied with these measures later, the product
  will not be delivered on time.
• Mitigation Plan Clarifying the performance
  measures with the client as soon as possible will
  help avoid this risk.

69
Risk Assessment

• User interface mismatch
• The client is not too sure about the kind of GUI
  he needs. A frequent change in his requirements
  could cause changes in the architecture. This is
  an IKIWISI
• Mitigation Plan Designing templates and
  discussing those with the client will help in
  timely requirements gathering. Also, constantly
  updating him with prototypes would help him
  decide better.
• Lack of time
• Since the semester is only 12 weeks long, not
  having a planned work-flow for the project,
  frequent changes and improper gathering of
  requirements may lead to not meeting the hard
  deadlines.
• Mitigation Plan Setting up milestones and making
  sure that the milestones are met per schedule.
• Personnel shortfall
• Team members drop the class may result not
  meeting deadline.
• Mitigation Plan Make complete and sound
  documents. Also add comments in the code so that
  new joining members do not face any problem in
  understanding the project. Also new members will
  be made to put extra hours.

70
Process Rationale

• Incremental Development because of fixed schedule
• Schedule as Independent Variable (SAIV) Strategy

71
Quality Focal Point

• Kunal Jain

72
Traceability Matrix
73
Defect Identification Review
74
Defect Injection Removal Matrix