LCA ARB - USC CCR Web Application

Document Sample
LCA ARB - USC CCR Web Application Powered By Docstoc
					USC CCR Web Application

  Team 7
Operational Concept
  Carlo Stearns
System Purpose
  Clients: USC External Relations and Civic and
   Community Relations
  Desired Functions:
        Quantify impact of programs
        Reduce schedule and time conflicts between
        Share Resources
    Web Application Components:
        Data Collection & Analysis
        Scheduling Tool
        Shared Repository
Changes in Current System

  UNO Program Managers will submit
   reports exclusively through this system
  UNO Programs will be required to keep
   their online schedules up to date
  UNO Program Staff will need to learn
   how to use the new system (Training
Benefits Chain

                 & ER
System Boundaries

  The system will not keep track of school
   schedules (Future Capability)
  The system will not keep track of facility
   usage (Future Capability)
  The system will not keep track of every
   participant in each program (Future

   Eva Lee
Data Collection & Analysis

    System Administrators
        ER/CCR
    Program Administrators
Reports Page (System Admin)
Statistics Page (System Admin)
Summary Report (System Admin)
Aggregated Summary Report
Reports Page (Program Admin)
Interim Report (Program Admin)
Scheduling Tool

  Public
  System Administrators
        ER/CCR
    Program Administrators
Calendar Page (Public)
Editing Calendar (Admin)
Shared Repository

  Public
  System Administrators
        ER/CCR
    Program Administrators
Get Involved Page (Public)
Application (Public)
Get Involved Page (Program Admin)

           After School Sports Program
Edit Openings (Program Admin)
Prototyping Results

  Iterated multiple times with the client
   regarding interface.
  Critical capability and interface
   requirements have been refined in our

  Karim Vidhani
Project Requirements
   Key Project Requirements:

       24 week time frame (577a and 577b)
       Low cost requirement
          Must use open source or existing software

          Minimize expenditures

       PHP as main development language
       Web Deployment only
       Application backed by Open Source DBMS
          MySQL selected as the DBMS of choice

       System Training provided for users
    Capability Requirements

   Key Capability Requirements:

       Shared repository of data for each CCR program
       Scheduling tool to provide scheduling for programs and schools
       Data Collection & Analysis tool to generate corresponding reports
        for all users
       Different levels of security and operation
       Convenient system and data back up scripts
       Assist users in reducing conflicts between programs and schools
    System Interface Requirements
   Key Interface Requirements:

       General UI of the system should be as simple as possible
       Application will have a public layer followed by a secure access
           Public layer will allow anyone to see upcoming events and
            other static information
           Secure layer will need authentication from one of several
            different types of users
           Calendar modifications, program data upload or any other
            modifications can only take place in secure layer
       Scheduling Tool UI should be similar to USC Arts & Events or
        Viterbi Engineering Calendar
Levels of Service Requirements
   Key L.O.S Requirements:

       Ease of maintenance
       Minimal downtime
       System performance should be as optimized to:
          Handle multiple DBMS requests

          Support heavy traffic

       The system should work well with 3rd party software
          Integration with Microsoft Excel for reports

          Compatibility with IE, Mozilla, & Safari

       The application should be intuitive and easy
       The system should accommodate future growth
    Evolutionary Requirements

   Key Evolutionary Requirements:

       Provide functionality to keep track of each individual student
       Increase the detail of statistics maintained by the application
       Implement the ability to allow users to schedule additional
        resources such as equipment, vehicles, etc …

   Andrew Hart
Physical Architecture

   Client / Server Architecture
   Operating System: SunOS
   Web Server: Apache
   Scripting: PHP, JavaScript
   Hosting / Backup: USC ITS
Status of COTS / Reuse
   COTS Product      Status
   DBMS              SELECTED – MySQL

   Scheduling Tool   SELECTED –
                     ltwCalendar - PHP Event
   (Calendar)        Calendar (v4.2.1)


   PHP Helper Classes SELECTED –
                     PEAR PHP Class Repository

System Actors
System Overview / Deployment
System Information Model
Data Collection & Analysis
Data Collection & Analysis :: Create
Performance Report – Information Model
Data Collection & Analysis :: Create
Performance Report – Sequence Diagram
Scheduling Tool
Shared Repository

  Skanda Ramesh

    Issues –
        Only three members of the team will
         continue to 577b, hence the new members
         would take sometime to get a grip of the

  We would be using ItwCalendar - PHP
   Event Calendar, for the scheduling tool.
  A part time database maintainer working
   for 2hrs/week is sufficient to maintain the
  The new members of the 577b team will
   have good knowledge in PHP and
Skills required for the 577b team

  Good knowledge in web programming
   i.e., good knowledge in PHP and
  Familiarity with Dreamweaver8 and its
   functionalities is good.
  Soft skills such as good communication
   skills are an added advantage.
Stakeholder Responsibilities
                Inception                      Elaboration                  Construction                Transition

 Developers     Prepare the documents          Refine / Elaborate           Implement the system        The software should be
                     which are necessary            documents from               which was being             reviewed and
                     for LCO & LCA                  LCO ARB and                  proposed in the             tested in the real
                     package. This                  evolve them to form          previous 2 phases           world and should
                     includes meeting the           the LCA Package              and also test the           also provide a
                     exit criteria for SSAD,        milestone.                   same.                       user’s manual for
                     SSRD, OCD, LCP,                                                                         new users ( i.e., a
                     FRD and prototype.                                                                      help option in the
 Customers /    The active participation of    Review the documents         Review the prototypes       Check how the
      Clients        clients in Win Win             delivered and                being developed             software has
                     negotiations and thus          monitor the progress         and give feedback           progressed by
                     helping the                    in the project.              to the clients as to        monitoring its
                     developers come up             Provide feedback on          how much they               working
                     with the correct win           the documents.               satisfied your              regularly. Learn
                     conditions which                                            requirements.               how to use the
                     would help                                                                              web based tool
                     developers to                                                                           effectively.
                     document the LCO
                     and LCA package
 IV&V           Review and provide             Review and provide           Review and provide          Review and provide
                     feedback for the               feedback for the             feedback for the            feedback for the
                     different milestones.          different milestones.        different                   different
                                                                                 milestones.                 milestones.
Table of Continuing Students for
                        NAME         CONTINUING / REGISTERED FOR 577B?

 Andrew Hart (SSAD Person)     YES

 Kailash Karol (FRD Person)    YES

 Eva Lee (Prototyper)          NO

 Betty Liu (IV&V)              NO

 Skanda Ramesh (LCP Person)    YES

 Carlo Stearns (OCD Person)    NO

 Karim Vidhani (SSRD Person)   NO
Plan For 577b - RLCA
Plan For 577b – RLCA (cont’d…)
Plan For 577b – Construction
Plan For 577b – Transition

 There are three modules :
  Data Collection & Analysis
  Scheduling Tool
  Shared Repository
Scale Factors
   Scale Driver    Value                       Rationale
      PREC        Nominal   Some of us have past experience in building the
                                              web application

      FLEX         High     Since the need to conform with the requirements
                                                   are high

      RESL         High      We have identified the major risks and we have
                                        taken steps to mitigate them.

     TEAM         Nominal   The team of stakeholders which include the client
                                  are working in a friendly environment and
                                     have a good rapport with each other.

     PMAT         Nominal    Since we are using SEI CMM level-2 i.e., how
                                  should we combine software cost models
                                 such as COCOMO II with other methods of
                                   sizing, estimation, planning and tracking
                                 software projects cost, schedule and effort.
Cost Drivers for Module 1
Cost Drivers for Module 2
Cost Drivers for Module 3
    Min no. of people required to do project in 6 months
    = 9.8/1.67
    = 5.86 persons
    =7.8/1.67
    = 4.67 persons
    Hence with the given resources we have estimated
     our project to be on schedule and on the right track
     even when you consider the pessimistic view.
Conclusion (cont’d…)

    Possible Faults
      The new members of the 577b team and
       their experience in web programming.
      The assumptions made on SLOC is
       approximated to how much we think, we
       would be able to write the code in. It may
       differ from person to person.
Feasibility Rationale
   Kailash Karol

  Business case Analysis
  Process Rationale
  Risk Assessment
Business Case Analysis

  Cost Analysis
  Benefit Analysis
  ROI
Cost Analysis

  Hardware and Software cost
  Personnel cost
Cost Analysis (Cont’d)
              Hardware and Software Cost

         Tool                    Cost
     Dreamweaver             $250(one time)
        MYSQL                      Free
      Web Hosting            $370 (per year)
  Open Source Package              Free
    for Calendar Tool
     PHP Interpreter               Free
Cost Analysis (Cont’d)
                                                                        Time spent
                   Inception & Elaboration Phase

   Time spent by CCR and ER representative (include meeting, Email,      72 hours
     phone and other communication time)- 2x3hrs/week x 12 weeks
  Time spent by program representative (include meeting, Email, phone    3 hours
       and other communication time)- 15 min./week x 12 weeks
                      Architecture Review Board                          6 hours
                        Win-Win negotiations                             6 hours
                  Construction & Transition Phase

  Time spent by CCR and ER representative (include meeting, Email,       48 hours
     phone and other communication time)- 2hrs/week x 12 weeks
  Time spent by program representative (include meeting, Email, phone    2 hours
       and other communication time)- 10 min./week x 12 weeks
                      Architecture Review Board                          6 hours
                        Win-Win negotiations                             6 hours
               Deployment of system in transition phase                  6 hours
                      Training in transition phase                       10 hours
                         Total(Development)                             165 hours
             Maintenance(per year) 2hrs/week x 52 weeks                 104 hours
Cost Analysis (Cont’d)

    Key facts taken into consideration
      Salary of CCR, ER Representative = $35/hr
      Salary of Program Directors = $35/hr
      Salary of person doing maintenance =
      With our system CCR and ER saves time by
       factor of 1/3
      With our system each Program saves time
       by factor of 1/2
Cost Analysis (Cont’d)

    Total Personal Cost includes
      Cost during development (one-time) =
       (165x$35) = $5775
      Cost during maintenance (recurring per
       year) = (104x$20) = $2080/yr
Benefit Analysis

  Monetary Benefit
  Non-Monetary Benefit
Benefit Analysis (Cont’d)

    Monetary Benefit
      Time save by CCR and ER = 150-50 =
       100 hrs/yr
      Time save by Programs = (40x29)/2 =
       580 hrs/yr
      Total saving in money = (100+580) x $35
       =$23800 per year
Benefit Analysis (Cont’d)

    Non-Monetary Benefit
      Avoid overhead of manual records
      Provide efficient way of listing resources
       and thus minimize conflicts
      Will enhance reputation of CCR and ER
ROI Analysis

                          OP- Year 06-07     OP- Year 07-08   OP-Year 08-09   OP-Year 09-10

 Effort Expended                5775                2710          2970            3267

 Effort Saved                     0                 23800        26180           28798

 Net Effort Expended            5775                  0            0                0

 Net Effort Saved                 0                 21100        23210           25531

 Cum. Net Cost C                5775                5775          5775            5775

 Cum. Net Benefit B               0                 21100        44310           69841

 ROI = Cum (B-C)/C               -1                 2.65          6.66            11.08

 (All figures in graph except ROI are money in $)
ROI Analysis (Cont’d)

         Break-event Point summary
Process Rationale

                           Process Model Decision Table

 Objectives, Constraints                     Alternatives                   Model
 Growth         Understanding   Robustness   Available      Architecture
 Envelope       of Requirements              technology     Understanding

 Medium         Low – Medium    Medium       None           Low - Medium    Spiral
Risk Assessment

 RISK-01: Personnel Continuity to 577 B. Nearly half of the team will not
 continue to 577B
 Risk          Artifacts must be consistent with one another and should be able to
 Mitigation:   familiarize the system to new members. Also important to identify the
               specific skills required in development as a criteria for finding new

 RISK-02: The project may be large to be completed in given 577 B schedule.

 Risk          It may be difficult to deliver the system with all required capabilities . We
 Mitigation:   already prioritized all major capabilities and also discussed with client
               that we start with capability that has highest priority and will
               encapsulate them according to their priorities.
Risk Assessment (Cont’d)

 RISK-03: Lack of Domain Experience on behalf of developers

 Risk           Negotiate realistic requirements and study about the framework from
 Mitigation:    the initial phase of the project.

  RISK-04: Open Source Code integration

  Risk          We are continuously prototyping and will do extensive testing and dry
  Mitigation:   run to eliminate any COTS integration problem.
IV & V

   Betty Liu
Highlights From LCA Draft Evaluation:

     Incorporated feedback and suggestions from LCO

     More technical issues decisions resolved

     Updated Prototype provided further screens with

     Made use of SID among documents

     More uniform formatting and information consistency
      among documents
Issues to address:

    LOS requirements measurability
         General concept defined but feasibility of
         potential test cases need more work

    Calendar interface
         Has a reference point for Calendar
         interface but no clear definitions. Need to
         be more specific to avoid scope creep.
Team Highlights:

  “well-oiled” team interactions and
  would be nice if whole team continues
  on to CS 577b
  overall good documentation produced
  for support (especially a visually helpful
  Prototype documented)

       Questions and Feedback

       Your feedback is highly
           valuable to us

            Thank You!

Shared By: