Asian Film Database Life Cycle Plan

1
Asian Film Database Life Cycle Plan
2
Overall Life Cycle Strategy

• Engineering Stage(CS577a)-- formulate
  operational concepts, requirement spec., arch.,
  prototypes, life cycle plans, and integrate
  rationale for the proposed capabilities.
• Production Stage(CS577b)-- develop initial
  operational capability products based on the
  requirement and arch. results from CS577a.--
  training customer to use and maintain the system
• Support Stage(USC ISD responsibility)

3
Phases of the development of AFDB

• Navigation
• Data Input
• Data Management
• Database Administration
• Help and Support

4
Milestones and Schedules
5
Major stakeholders in the development

• Owner USC - ISD
• Developer CS577 students
• User-- general public(web visitor)-- client--
  Data Manager-- System Administrator
• Customer USC - ISD

6
Stakeholders responsibility -- User

• Engineering Stage-- Provide system requirement,
  -- Define the operational concepts -- Prepare
  the operational plan
• Production Stage-- Review and test each
  increment in the development environment
• Support Stage-- Actual usage on the AFDB

7
Stakeholders responsibility -- Developer

• Engineering Stage-- prepare the system
  requirement, operational concept, system
  architecture-- make a plan -- build a prototype
  according to the above
• Production Stage-- implement and integrate the
  product-- perform and support test
• Support Stage-- Provide administrative support
  to the product transition-- adapt the product to
  operate in different environment.

8
Stakeholders responsibility -- Customer

• Engineering stage-- monitor and evaluate the
  project progress-- help to supply test data and
  scenario for system development
• Production stage-- review system performance
• Support stage-- Provide administrative support
  to the product transition -- maintain the system
  usage

9
Risk Management

• Unstable requirement-- currently there has no
  actual system, and a large part of requirements
  are based on customers plan.-- design system
  incrementally and modulely.
• User interface mismatch -- prototype may not
  meet the customers requirements-- frequently
  interact with customer and get their feedback

10
Risk Management (2)

• Schedule constraints-- the whole project should
  be completed by the end of spring semester in
  1999, so it will be too short to design and
  implement all the requirement .
• External components, COTS -- there is no such a
  system now. When customers select database and
  other softwares later, they must think about
  compability with current system design and arch.
• Personal Shortfalls-- the project will be
  continued by the cs577b students. They need time
  to be familiar with cs577a students work.

11
Project Communication
12
Quality Management

• One dedicated team member in project team who is
  in charge of performing the quality control.
• develop documentation and coding standards
• verify the compliance between the products and
  the documentation and coding standards
• prepare test cases and produce test reports
• not involved in the coding and development
  avoiding having any assumption and influence

13
Major Project Reviews

• Architecture Review Board (1)
• overall content of the LCA package
• make sure no other changes have occurred. If new
  elements have come out, they must be integrated
  at this time in the system.
• Architecture Review Board (2)
• The architecture designed, the developers have to
  make sure that they have not forgotten any
  requirements or import features.
• All the risks have resolved.
• Architecture Review Board (3)
• must verity that no interface design errors have
  been made for any module of the system.
• The review also checks that each individual
  module is well architected.

14
Major Project Reviews (2)

• Reviews/Inspections
• The team insures that each sub-module is tested
  and meets all associated requirements.
• Transition Readiness Review
• focuses mainly on the acceptability of the
  system. The customer will meet with the
  development team to discuss whether or not the
  current system is acceptable as it stands.
• Release Readiness Review
• It must verify that all stakholders are satisfied
  with the system acceptance test. Everything that
  is produced by the development team is accepted.
• at the end of the implementation phase.