Life Cycle Plan

Asian Film Database System - LCP

of 37

Life Cycle Plan

Date: 12/14/1998

Version: LCA V2.0

Team: Team #3

Team Members and Roles:

Jingtao Sun OCD

Hui Wang SSRD

Guang Yang SSAD

Xinhua Wei LCP/FRD

Tao Feng Prototype


of 37

TABLE OF CONTENTS:

1. INTRODUCTION......................................................................................................................................................... 3

1.1 PURPOSE OF THE LIFE CYCLE PLAN DOCUMENT......................................................................................................... 31.2 REFERENCES ............................................................................................................................... ................................ 3

2. MILESTONES AND PRODUCTS...................................................................................................... ........................ 3

2.1 OVERALL LIFE CYCLE STRATEGY............................................................................................................................... 42.2 SCHEDULES AND PHASE MILESTONES, DELIVERABLES, AND COMPLETION CRITERIA .............................................. 8

2.2.1 Engineering Stage............................................................................................................................................. 82.2.2 Production Stage ............................................................................................................................................ 102.2.3 Support Stage.................................................................................................................................................. 11

3. RESPONSIBILITIES ................................................................................................................................................. 11

3.1 ORGANIZATIONAL RESPONSIBILITIES........................................................................................................................ 123.1.1 Global Organization Charts ........................................................................................................................... 133.1.2 Organization commitment responsibilities ..................................................................................................... 13

3.2 STAKEHOLDER RESPONSIBILITIES............................................................................................................................. 143.2.1 Engineering Stage........................................................................................................................................... 143.2.2 Production Stage ............................................................................................................................................ 183.2.3 Support Stage.................................................................................................................................................. 20

3.3 ORGANIZATIONAL IMPACTS...................................................................................................................................... 213.3.1 Engineering Stage........................................................................................................................................... 213.3.2 Production Stage ............................................................................................................................................ 213.3.3 Support Stage.................................................................................................................................................. 22

4. APPROACH................................................................................................................................................................ 22

4.1 RISK MANAGEMENT ................................................................................................................................................. 224.2 SUPPORT ENVIRONMENT, METHODS, AND TOOLS .................................................................................................... 254.3 REVIEWS ................................................................................................................................................................... 25

4.3.1 Architecture Review Board I........................................................................................................................... 254.3.2 Architecture Review Board II ......................................................................................................................... 264.3.3 Architecture Review Board III ........................................................................................................................ 264.3.4 Reviews/Inspections ........................................................................................................................................ 274.3.5 Transition Readiness Review .......................................................................................................................... 274.3.6 Release Readiness Review .............................................................................................................................. 27

4.4 PROJECT COMMUNICATIONS ..................................................................................................................................... 284.5 CONFIGURATION MANAGEMENT............................................................................................................................... 294.6 QUALITY MANAGEMENT........................................................................................................................................... 324.7 FACILITIES AND RELATED CONCERNS....................................................................................................................... 324.8 STATUS MONITORING AND CONTROL ....................................................................................................................... 33

5. RESOURCES .............................................................................................................................................................. 33

5.1 WORK BREAKDOWN STRUCTURE ............................................................................................................................. 345.2 BUDGETS .................................................................................................................................................................. 36

6. ASSUMPTIONS.......................................................................................................................................................... 36

7. APPENDIX.................................................................................................................................................................. 37


of 37

1. Introduction

This document is to identify the life-cycle stakeholders and life-cycle process model in top-level stageand increments. It mainly demonstrates top-level evidence to achieve objective to answer the commonquestions about the AFDB project, to plan the development schedule, to tell who will be responsiblefor performing the various software development functions, to tell where they will be performed, to tellhow the project will implemented the software development strategy, to tell how much resources theproject will require to perform the functions.

1.1 Purpose of the Life Cycle Plan Document

To achieve the objectives of the AFDB system, The following Life Cycle Plan document will:

• Serve as the basis for monitoring and controlling the project’s progress in achieving the softwareproduct objectives.

• Help make the best use of people and resources throughout the development cycle.• Provide evidence that the developers have thought through the major development issues in

advance.• Guide the cs577b construction effort.

The intended audience of this document is primarily the performer teams in each stage, but it is alsoimportant for customer, and useful for other stakeholders.

1.2 ReferencesOperational Concept DescriptionSystem and Software Requirements DefinitionSystem and Software Architecture DescriptionFeasibility Rationale

2. Milestones and Products

This section tells what project functions will be performed during development, and what products willbe developed. It contains schedules and milestones which indicate when each function and product willbe completed.


of 37

2.1 Overall Life Cycle Strategy

In the process of AFDB development, there are three stages of life cycle plan, which are EngineeringStage (consists of Inception and Elaboration Phases), Construction Stage (consists of Construction andTransition Phases) and Support Stage. The primary development process model to use in developingthe AFDB is the spiral model. Each phase involves a spiral cycle in the developmental process, andeach phase’s lessons learned are carried through to the next. In each phase of the model are severalsequential activities, such as determining objectives, alternatives, and constraints for this phase;evaluating alternatives, identifying risks, and selecting an alternative; developing and verifying theproduct; and planning for the next phase.

While the spiral model will be the primary overarching methodology used, a risk-driven waterfallmodel will be used to allow users to test the system as it is incrementally released, and provide timelyfeedback for inclusion in future incremental releases. Using this internal model is most effective whenthe core functionality is released to the customer in early increments, particularly when that corefunctionality covers the major risks identified from the initial spiral model iterations. This is becausethe primary benefit of the spiral model lies in its identification and resolution of critical risksassociated with complex systems early in the development process. The risk-driven waterfall modelreduces the possible disturbances arising from the inevitable requirement changes, and its explicit risk-management process assists resolution of risks associated with complex systems and scheduleconstraints.

The major schedule constraint is that the system should have its hand-off to the USC library and themaintenance stakeholders completed on May 4, 1999. The risk-driven waterfall model strategy willimplement the highest-risk system capabilities in the early incremental release, the final incrementalrelease is scheduled to be completed by April 24, 1999. The core system capabilities will beguaranteed in this release. Features which are designated as non-essential may be included in thisrelease if time and system reliability permit. Otherwise, continuation of further incremental releases toadd additional non-essential features may be negotiated. The inclusion of such features will be made inthe order of priority as specified by the customer, subject to developer concurrence.

Since the project is going to be developed by the CS577 students during the two semesters, the majorlife-cycle stages with their organizations, phases, and milestones are as follows:

• Engineering Stage (CS 577a)

• Inception Phase (one Win-Win Spiral cycle, completed by an LCO ARB review)• Elaboration Phase (one Win-Win Spiral cycle, completed by an LCA ARB review)

• Production Stage (CS 577b)

• Construction Phase (a short Win-Win Spiral cycle, completed by an ArchitectureRebaseline Review; followed by a risk-driven waterfall cycle, completed by a TransitionReadiness Review)


of 37

• Transition Phase, completed by a Release Readiness Review

• Support Stage (USC Library responsibility)

• A series of releases, each with its appropriate choice of the stages and phases above,completed by a Release Readiness Review

The phase Overviews are as follows:

Inception Phase

The Inception Phase of the software development process is to achieve concurrence amongstakeholders on the life-cycle objectives for the project. The primary objectives and activities of theInception Phase includes:

• Establish the project’s software scope and boundary conditions including an operational concept,requirements, acceptance criteria, potential risks and what is intended to be in the product and whatis not

• Defines the cost and schedule for the entire project• Complete the Win-Win negotiations between the customer, user, and developer stakeholders which

marks the first milestone.• Build an initial prototype depending on the scope, size, risk and novelty of the project.

The system requirements and capabilities are determined by use of these results. The next milestone isthe completion of the system's Life Cycle Objectives (LCO) document to demonstrate the concurrenceof each stakeholder with the system. The project's scope is established by the LCO, defining thesystem's top-level objectives, requirements, architecture, core capabilities, and software developmentplan. The completion of the LCO ARB Review is the final milestone for this phase.

Elaboration Phase

The Elaboration Phase of the software development process makes the decision on whether or not tocommit to the Construction Phases. The primary objectives and activities of the Elaboration Phaseincludes:

• Baseline the architecture and select components as rapidly as practical.• Baseline the vision.• Build an executable prototype to satisfy the system requirements.• Baseline a high-fidelity development plan for the construction phase.• Demonstrate that the baseline architecture will support the vision for reasonable cost in a

reasonable time.

The whole activities in this phase must ensure that the architecture, requirements and plans are stableenough, and risks sufficiently mitigated.


of 37

The system’s core capabilities are divided into the main components as developed during the LCOprocess. The capabilities are categorized based on standard object oriented analysis, that thecapabilities within a module are both data and functionally cohesive.

In this phase, the milestone is determination of the Life Cycle Architecture (LCA), which is primarilyconcerned with elaborating the elements specified in the LCO. The definition of the systemarchitecture is key to the LCA. As with the LCO, the LCA milestone is the concurrence of eachstakeholder with the system described in the LCA documents. A series of basic prototypes of thesystem, largely "snapshot prototypes" which give an indication of the types of GUIs which could beproduced and their relative benefits, were developed during the Inception Phase, and have beendemonstrated to team members and the customer. The completion of the LCA ARB Review is thefinal milestone for this phase.

Construction Phase

The Construction Phase of the software development process implements the all system essentialfunctions decided by the Elaboration Phase. Incremental development strategy is used in this phase.The four development increments and primary objectives and activities of the Construction Phaseincludes:

Increment I: Database design and construction

• Design and construct the film database• Create the unified film data format• Generate HTML film catalogs which contain the film title, director, actor, country, etc.• Test database

Increment II: Data operation, user’s navigation, database administration

In this increment, we just want to mention the parallel development strategy for implementing thecore capabilities of user, data manager, and system administration; and do the unit test for eachfunction.

• HTML generator to create HTML pages with each query functions for the user, data manager, andsystem administration.

• Implement query functions for the core capabilities of user and interfaces for user• Implement query functions for the core capabilities of data manager and interfaces for data

manager• Implement query functions for the core capabilities of system administration and interfaces for

system administration.• Test functions created in this increment using test data provided by USC library

Increment III: System integration test and installation


of 37

• Perform all essential applications including user’s navigation, manager’s update, client’s dataentry, system administrator’s maintenance based on the test data provided by USC library.

• Install the AFDB system on the USC Web server.

The Architecture Rebaseline review is time at the front end of the Construction Phase to allow themembers of the 577b team and the USC library to clarify any outstanding design issues. During thistime, new issues may be raised which need to be examined before commencement of the ConstructionPhase. Old issues which could not be fully addressed in the LCA package may also need to be revised.This phase has a hard stop of Feb. 2, 1999 for handoff to the Construction Phase. Further issueclarification and addressing may continue, but from a schedule and architecture standpoint the fewerdrastic changes made past this point the better.

The Construction Phase specifies how the LCA is to be implemented. The creation of a ConstructionSpecification, which specifies the detailed design for the system's architecture and software modules, isto be completed in this phase. Also commencing in this phase is the development of an Integration andTest Plan, as well as a System Acceptance Test Plan. The risks identified by the Construction Reviewwill be included in the scope of the system prototype to aid in their assessment. The completion of theConstruction Review is the milestone signifying the end of the Elaboration Phase.

The Construction phase of each software development release requires the detailed design of themodules in the Construction Specification. The modules and their core system capabilities are listedbelow. The end of the Construction Phase is marked by satisfaction of the listed core capabilities (Seethe system priority outlined in section 3.1 of FR), confirmed during an Inspection Review for thatincremental release.

The Integration and Test plan of each incremental release involves testing and integration of the newmodules contained within that release, as well as regression testing of modules contained in priorreleases. Upon completion of the integration and testing for this increment, the development team willhold a Unit Test Completion Review for each incremental development release. The milestone for eachincremental release is the completion of this review.

The Construction Phase of each incremental release involves the addition of the new increment into theexisting system. Following the System Acceptance Test Plan, system level tests are run to verify thecorrect functioning of the system. The Construction Phase milestone is the completion of a SystemAcceptance Review for each incremental software release.

Transition phase

The Transition Phase focus on the activities required to place the software into the hands of the users.The primary objectives and activities of the Transition Phase includes:

• Achieve user self-supportability by developing user-oriented manuals and reacting to userfeedback.


of 37

• Achieve stakeholders concurrence that deployment baselines are complete and consistent with theevaluation criteria of the vision.

• Achieve final product baseline as rapidly and cost effectively as practical.• Train the system administrators and data managers with the developing maintain-specific

documents.

2.2 Schedules and Phase Milestones, Deliverables, and Completion Criteria

The total time for development is almost 24 weeks which are in accordance with the requirement of theCS577 a/b course spanning over two semesters. Based on the different phases shown in Life CyclePlan section 2.1, we indicate milestones showing the overall order in which components are integrated,and the intermediate stages of increment and acceptance testing, show how these are synchronizedwith milestones for preparation of test drivers, facilities, equipment, data, post- processors, etc. for thevarious increment.

2.2.1 Engineering Stage

The CS577a team members will gather the requirements through Win-Win negotiation used within theall stakeholders from the AFDB system, then formulate operational concepts, requirementspecifications, architectures, prototypes, life cycle plans, and integrating rationale for the proposedcapabilities.

During this stage, the customers from USC library will have to participate in the validation of theAFDB prototype is exactly meet what they need. They have to make a clear schedule time tocommunicate with development team and give them a feedback on the project implementation. If theyhave to change some functions that may influence the prototype, they have to make sure that thisimprovement is provided in this phase.

The detailed milestones and schedule of deliverables and completion criteria in this stage will:

Item Name Date Item Format Completion CriteriaWin-WinNegotiation

Oct. 19, 1998 Document Most win conditions for all thestakeholder properly identified,and some of the conflicting winconditions properly resolved.

InitialPrototype

Oct. 19, 1998 Web-basedApplication

Availability of the basicprototype to customer for initialfeedback.

LCO Drafts Oct. 28, 1998 Web-basedDocument

See a draft for every artifact withTBD’s.


of 37

Give your team members theopportunity to review your work,and to ensure consistencybetween the various artifacts.

LCO Package Nov. 4, 1998 Web-basedDocument

Establish the system boundaryand specify the scope of projectby defining the top-levelobjectives of the system.

IntermediatePrototype

Nov. 4, 1998 Wed-basedDocument

TBD’s in initial prototype shouldhave been cleared by now.Functionality added, or refinedaccording to refinement inrequirements, and results of win-win negotiation.

LCO PackageArchitectureReviewBoards

Nov. 9, 1998 -Nov. 13, 1998

Wed-basedDocumentand Application

Demo the every artifact in LCOpackage with customers and getfeedback on it and give aninitially solution for TBD’s

LCA Drafts Dec. 2, 1998 Web-basedDocument

See a draft for every artifactwithout TBD’s.Give your team members theopportunity to review your work,and to ensure consistencybetween the various artifacts.

LCA PackageArchitectureReviewBoards

Dec. 7, 1998 -Dec. 11,1998

Web-basedDocument andApplication

Demo the every artifact in LCApackage with customers and getfeedback on it

LCA Package Dec. 14, 1998 Web-basedDocument

The critical element is thedefinition of the system andsoftware architecture. It includesthe definitions of the system andsoftware components,connectors, and constraints. Thespecifications of COTs andarchitectural evolution are alsothe key features of the LCA

FinalPrototype

Dec 14, 1998 Web-basedApplication

The critical element is thedefinition of the system andsoftware architecture. It includesthe definitions of the system andsoftware components,connectors, and constraints. Thespecifications of COTs andarchitectural evolution are alsothe key features of the LCA


of 37

2.2.2 Production Stage

In CS577b team members will plan to have student teams develop initial operational capabilityproducts based on the best results from CS577a.

For the development team, they should have to be familiar with the operation of DBMS and completethe database design and construction before Mar. 2, 1999.

The detailed produce phase milestones and schedule of deliverables in production stage will:

Item Name Date Item Format Completion Criteria

Development teamformation

Jan. 26, 1999 Five students selected to be thedevelopment team and one was electedto be development manager

ARB RebaselineReview

Feb. 2, 1999 Web-baseddocument

• Discuss the individual critiquesfrom CS577a team members

• Revise LCASoftwareDevelopment Plan

Feb. 9, 1999 document • Project plan• Software requirements specification• Initial software development files• Metrics report

Increment IDevelopment andUnit Test

Feb.23, 1999 Web-basedapplication anddocument

• Incremental software release I• Test review for this release• Metrics report

Increment IIDevelopment andUnit Test

Apr. 6, 1999 Web-basedapplication anddocument

• Incremental software release II• Test review for this release• Metrics report

Increment IIIDevelopment andTransition Plan


• Incremental software release III• Test review for this release• Metrics report• System acceptance review report• Transition plan and preparation

Transition ReadinessReview


• Software Acceptance Review

Software transition May 4, 1999 Web-basedapplication anddocument

• Transition activities• Software user manual• Software version description

documentRelease ReadinessReview

May 4, 1999 Web-basedapplication and

• System Acceptance Review• Review system preparation,


of 37

document training, usage, and evolutionsupport with customers

System operationand maintenance

May 14, 1999 Web-basedapplication

• System operation and maintenanceon the USC Web server

2.2.3 Support Stage

This stage is supported by ISD in USC. The ISD must provide a commercial DBMS to thedevelopment team at the beginning of the Construction Phase. They also are responsible for theproduct release version when the product is operated on the USC Web server. In the future, thedifferent version of the product can be released along the evolution of the product.

The clients will continuously provide the film data to the AFDB system, which is used to develop thenew version product gradually.

3. Responsibilities

This Section tells who will be responsible for performing the various software development functions,and where organizationally they will be performed. It identifies the major development- related agents- developers, customers, administrators, users - and establishes their roles and responsibilities. Itdefines the major organizational components of the development project, and indicates theirresponsibilities across the phases of the development cycle. It presents organization charts showingindividual and organizational responsibilities, and includes plans for project staffing and training.

The major development related agents consist of:• Owner: USC library• Developer: team members of graduate students enrolled in CS577b• User: Web visitor• System Administrator: employee of ISD at USC• Data Manager: employee of USC library• Client: film data provider from different Asia countries• Customer: USC library


of 37

3.1 Organizational Responsibilities

The development related agents will assume responsibility for carrying out the functions as follows:

Owner • Monitor closely the progress of the development team• Make sure that the development team is provided with the

computing facilities such as equipment, or software• Ensure the development team is granted to use some privileged

services (e.g., increased quotas).Developer • Plan, design, develop and verify selected changes

• Provide installation and configuration• Provide training

Customer • Evaluate all the project deliverable• Supply data for the testing of the system under development and

for testing of the database releaseSystem Administrator • Maintain high level system performance

• Provide system usage statistics• Ensure data consistence• Protect the security of system• Collect system period update data

Data Manager • Check the data sent by clients.• Communicate with clients regarding the correctness and

translations of film data• Update the database

Client • Create new film data and transmit to AFDB• Check the status of the film data

User • Browse the AFDB.• Download the pictures and videoclips• Know the unfamiliar contextual information related to the cinema

culture in a film• Search the film information


of 37

3.1.1 Global Organization Charts

Users

Other Countries

Administrator

UCS

Manager

Asian Film Database

USC Library

Team 3

CSCI577a

USC Students

USC Users

USA

Clients Users

China India

Taiwan Japan Korea

CSCI577b

Team

Global Organization Chart

3.1.2 Organization commitment responsibilities

Any and all changes that are made to the schedule, scope, and budget of this project will need to beratified by all organizational stakeholders directly involved with the development, operation, andmaintenance of the AFDB system. Those organizations include the Library Department at USC, andthe development team from the Fall 1998 CS577a class to the development team from Spring 1999CS577b class.


of 37

The Development Team Manager from each team is responsible for committing the development teamto any changes in the project schedule, scope, or budget. Prior to committing the development team toany project changes, The Development Team Manager will gather input from development teammembers and other stakeholders as appropriate.

Should a new stakeholder be identified from an organization directly associated with the development,operation, and maintenance of the system, that organization’s manager will be responsible forcommitting their organization to any changes in the project schedule, scope, or budget.

3.2 Stakeholder Responsibilities

This section will show the responsibilities of all stakeholders in the different stages.


The stakeholders’ responsibilities in the engineering stage are listed as follows:

Inception Elaboration User • Specify the definition of

requirements• Define the operational concepts• Prepare the operational plan• Negotiate the win-win conditions

with other stakeholders

• Review project developmentarchitecture, designs andprototypes during ARB

Customer • Support the definition from thecustomer’s concern

• Review the definition ofrequirements, operationalconcepts and plan from user

• Accept or reject options duringnegotiation with the win-winconditions with otherstakeholders

• Identify, negotiate transitionrequirements, strategies, anddeliverables

• Monitor and evaluate theproject progress at themilestones and schedule ofdeliverable

• Supply data for the testing ofthe system underdevelopment and for testingof the database

• Review project developmentarchitecture, designs andprototypes during ARB

Developer • Prepare the documents of OCD,SSRD, LCP, FR, sketch SSAD

• Modify and refinearchitecture and design based


of 37

and prototype• Support the interface

specification• Present the LCO package during

the ARB

on the good feedback forLCO from ARB

• Present the LCA packageduring the ARB

• Modify and refinearchitecture and design basedon the good feedback forLCA from ARB

Development Responsibilities

A team of five students from CS577a (Fall 1998 semester) will be responsible for the systemengineering of the AFDB system. In the roughly 12-week period between September 23, 1998 andDecember 14, 1998, Team members will be responsible for formulating the LCO and LCA versions ofthe six project artifacts (OCD, SSRD, SSAD, LCP, FR and Prototype) for the proposed capabilities.Project development team manager elected by the team will perform the following primaryresponsibilities related to the project management:

• Customer contact: Confirm that customer needs are being identified and addressed.• Ensuring consistency among the team members’ artifacts (and documenting this in the

Rationale).• Leading the team’s development of plans for achieving the project results, and ensuring that

project performance tracks the plans.• Schedule monitoring.

Development Organization Charts

Project DevelopmentTeam Manager(CS577a student)

Project DevelopmentTeam Member(CS577a student)

Project DevelopmentTeam Member #(CS577a student)

Project DevelopmentTeam Member #3(CS577a student)

Project DevelopmentTeam Member #4(CS577a student)


of 37

Detailed roles and responsibilities for each development team member in this stage are as follows:

TeamMembers

Responsibilities Life Cycle Objectives(LCO)

Life Cycle Architecture(LCA)

TeamMember #1

OperationalConceptDefinition(OCD)

• Top-level systemobjectives and scopesuch as systemboundary, environmentparameters andassumptions, evolutionparameters

• Operational conceptsuch as operations andmaintenancescenarios andparameters,organizational life-cycle responsibilities(stakeholders)

• Elaboration of systemobjectives and scope byincrement

• Elaboration ofoperational concept byincrement

TeamMember #2

SystemPrototype(s)

• Exercise key usagescenarios

• Resolve critical risks

• Exercise range of usagescenarios

• Resolve majoroutstanding risks

TeamMember #3

Definition ofSystem andSoftwareRequirements(SSRD)

• Top-level functions,interfaces, qualityattribute levels,including growthvectors, priorities

• Stakeholders’concurrence onessentials

• Elaboration of functions,interfaces, qualityattributes by increment

• Identification of TBDs(to-be-determined items)

• Stakeholders’concurrence on theirpriority concerns

ProjectDevelopmentTeamManager

System andSoftwareArchitectureDefinition(SSAD)

• Top-level definition ofat least one feasiblearchitecture includingphysical and logicalelements andrelationships andchoices of COTS andreusable softwareelements

• Identification ofunfeasible architectureoptions

• Choice of architectureand elaboration byincrement

• Physical and logicalcomponents,connectors,configurations,constraints

• COTS, reuse choices• Domain-architecture and

architectural style choices• Architecture evolution


of 37

parametersTeamMember #4

Life-Cycle Plan (LCP)

• Identification of life-cycle stakeholders

• Users, customers,developers,maintainers, generalpublic, others

• Identification of life-cycle process model

• Top-level stages,increments

• Top-levelWWWWWHH* bystage

• Elaboration ofWWWWWHH* forInitialOperational Capability(IOC)

• Partial elaboration,identification of keyTBDs for laterincrements

TeamMember #1and #3 and#4 and TeamManager

FeasibilityRationale (FR)

• Assurance ofconsistence amongelements above

• Via analysis,measurement,prototyping,simulation, etc.

• Business case analysisfor requirements,feasible architectures

• Assurance of consistencyamong elements above

• All major risks resolvedor covered by riskmanagement plan

* WWWWWHH: Why, What, When, Who, Where, How, How Much

Training

The development team members will learn all the tools in the CS577a class in Fall 1998, such as Win-Win tool for negotiation, COCOMO II 98.0 for the cost estimation, the ROSE 98’ tool to supportObject-oriented Language UML 4.0 for Object-oriented software architecture designing.


of 37


The stakeholders’ responsibilities in the production stage are listed as follows:

Construction TransitionUser • Short win-win spiral cycle between

the stakeholders• Review and test each increment in

the development environment.• Provide test support.

• Evaluate the product and give usagefeedback to the systemadministrator

• Review and test each increment inthe development environment.

Customer • ARB rebaseline Review• Facility preparation (computer,

scanner,• Short win-win spiral cycle between

the stakeholders• Monitor the product progress at the

development milestones andschedule of deliverable

• Perform data manager and systemadministrator’s responsibilities

• Review system performance

• Monitor the product progress• Provide administrative support to

the product transition• Refine transition strategy; Prepare

for transition• Review system performance• Operate and maintain system

Developer • Short win-win spiral cycle betweenthe stakeholders

• Implement and integrate product• Perform and support test

• Validate interface in operationalenvironment

• Adapt the product to operate indifferent environment.

• Provide administrative support tothe product transition

Clients • Short win-win spiral cycle betweenthe stakeholders

• Perform and support test withproviding film data

• Evaluate the product and give usagefeedback to the systemadministrator

Development Responsibilities

A team of five students from CS577b (Spring 1999 semester) will be responsible for the developmentof the AFDB system. In the roughly 12-week period between Jan. 26, 1999 and Apr. 20, 1999, thisteam will be responsible for the product design and four incremental development phases associatedwith the development process.


of 37

Development Organization Chart

Detailed roles and responsibilities for each development team member are described in the followingsections.

Project Development Team Manager

The role of the Project development team manager will be assumed by one of the CS577b teammembers, who will be responsible for all project-level management functions. The mainresponsibilities include:

• Customer contact: Confirm that customer needs are being identified and addressed.• Project-level planning and control.• Providing team leadership and direction.• Overseeing the software development process.• Risk monitoring.• Schedule monitoring.• Assisting as necessary with programming.

The other four members of the development team will be responsible for the completion of thesystem’s software modules and other associated project activities. These activities include the productdesign, programming, module and system level testing, quality assurance, and the production ofmanuals. Each of the four members reports directly to the Project Development Team Manager. Theresponsibilities assigned to each of the members are detailed in the following paragraphs.

System Architect: (one student)

Project Development Team Manager (CS577b student)

System Architect(CS577b student)

Programmer1 (CS577b student)

Programmer 2(CS577b student)

Tester(CS577b student)


of 37

• System architecture design• System requirement definition• Software requirement specification• Software development files• Project plan

Programmers: (two students)

• Database design and construction• Data operation• HTML formatting• Data edition and management• HTML generation.• User’s navigation, and administration

Tester: (one student)

• System test plans and implementing unit testing concurrently with each incremental development.• System test and usability feedback.• Management of software quality of project.

Training

The project developers are responsible for providing informal demonstrations of the product'scapabilities after each incremental release. These sessions are intended to provide an overview of thesystem's functionality and the improvements made. A separate training session for the systemadministrator and data manager may be scheduled to assist in the hand-off of developmentresponsibilities. The project developers will be available to give an overview of the programmer'sguide and answer questions as needed at that meeting.

3.2.3 Support Stage


of 37

During this stage, the system administrator from ISD is responsible for the system installation andmaintenance on the USC Web server based on the instruction in User Manual. The development teamis responsible for training the system administrator for his duty. In the operation of the initial AFDBsystem, there is only one person who can perform the administration.

3.3 Organizational Impacts

In this section we will discuss the impacts to every organization during each one of the stages.


Organizational ImpactsUser • System requirements

Customer • Product performance including prototyping,requirements gathering etc.

• Product progress including staffing, trainingetc.

Developer • Product interface in operational environment• Product architecture design• Operational environment of product


Organizational ImpactsUser • Development progress in each incrementCustomer • Development progress in each increment

• System performance• Product transition and deployment• System testing and acceptance

Developer • Development progress in each increment• System performance• Product transition and deployment• System testing and quality satisfaction

Client • System performance• System testing


of 37

3.3.3 Support Stage

Organizational ImpactsUser • Actual usage on the AFDBCustomer • Operation and maintenance

• Product release• Product evolution

Developer • System operation training• Support for the product running

4. Approach

This Section summarize the project implementation approaches in following aspects:

• Risk assessment;• Tool & environment;• Project reviews;• Communication (with customer, user or team-internal)• Configuration• Quality control• Status Monitor and Control

It will tell how the project will implement the software development strategy described in Section 2.1.It identifies the activities, tools, and techniques which will be employed in performing the projectfunctions. It presents the project’s approach for risk management, and for performing softwarerequirements analysis, design, development, test, and implementation functions. It describes how theproject will perform associated project functions such as technical reviews, project communications,configuration management, quality management, facilities management, security, and subcontractormanagement.

4.1 Risk Management

The risk management plan is to identify the major sources of risk in the development of project, andshow how the project will address, monitor, and resolve these risks.

Unstable requirements


of 37

• Risk:

This will be one of the biggest risk in this project, because currently customers don’t have actualbusiness or system, a large part of requirements are based on customer’s plan. And this system willinvolve global users from outside states, who has very high influence on the decision andrequirements.

• Risk management:

The Architecture Rebaseline review is time to allow the members of the 577b team and the USClibrary to clarify any outstanding design issues. During this time, new requirements may be raisedwhich need to be examined before commencement of the design phase. This phase has to be stoppedon Feb. 2, 1999 for handoff to the Construction Phase. Further issue clarification and addressing maycontinue, but from a schedule and architecture standpoint the fewer drastic changes made past thispoint the better.

Schedule constraints

• Risk

This will be another one of the biggest risks in this project, since the whole project with so manyrequirements should be completed by the end of spring semester in 1999, it can not be changed. Aschedule risk exists because it is not known if the whole of the capabilities requested by the user can beimplemented.

• Risk management:

In order to meet the schedule deadline, the core capabilities were identified and prioritized by thestakeholders with respect to the feasibility of completing those tasks in one semester. This means thatthe highest priority system capabilities will be developed and released to the customer early in theprocess. This allows the stakeholders to keep closer track progress, and to have more time foridentification and resolution of current risks.

Personal shortfalls

• RiskTo the team members of CS577b, There are some factors of risk:

• Unfamiliar with the project they have to implement.• Unfamiliar with each other since many teams of CS577a do not take the CS577b class.

Therefore they do not know the strong and weak points of other team members.• Unfamiliar with the development tools and environment.• Teamwork in the CS577b team.


of 37

• Risk management

To mitigate this risk,• An issue was developed during Win-Win negotiating to specify that the developers who

will work on this system should be required to have or demonstrate a certain minimumlevel of competency with the selected programming language and development tools.

• Two weeks have been allocated for the newly formed teams to rebaseline the LCA package.This allows team members to readjust the materials to reflect any requirements ortechnology changes. Further reduction can be made by assigning different project parts toteam members based on their levels of relevant experience.

External components, COTS

• Risk

It is customer’s choice to select the tools and other software products, and they will focus more on theexpenses, without caring very much with ease-use and their performance and compatibility.

• Risk management

Through the inspection, reference checking, and compatibility analysis of the tools and other softwareproducts based on the system requirements, the development team can go though Win-Win negotiationwith customer regarding the choice of the tools and software products and demonstrate the advantageand disadvantage of the software products. They must reach an agreement on this matter.

User interface mismatch

• Risk

As mentioned above, a lot of key users in the system, like clients and data managers are outside ofstates, which causes it very difficult to collect and work out the user interface to meet all theirrequirements. There are also user interface mismatch between what the developers design and what thecustomers expect in the end of implementation.

• Risk management

Thought the Win-Win negotiation with all stakeholders, the user characterization including thefunctionality, style, and workload has to be identified. Development team will identify the real usersbased on the analysis of user characterization. The development team has firstly demonstrated theprototype to the customers and shows the all operational scenarios in the prototype. If agreement hasbeen reached, it will be not allowed to change during the development.


of 37

Evolution and location requirements

• Risk

Since the huge amount of the films produced each year in the five countries in Asia, the large databaseis asked to store the film data. Thinking about the product evolution described in SSRD 6.1, it is a bigrisk that we may run out of the memory if we just keep storing the film data in the database or weexpand participation to other Asian cinema cultures.

• Risk management

To mitigate this risk, we have divided product development into two steps: short-term goal and long-team goal. To the short-term goal, we just concentrate on the cinema cultures of China, Hong Kong,India, Japan, Korea, and Taiwan with films produced in the past five year. It can reach total 5,000 filmrecords in the database. The size of the database can be designed to store 10,000 film records, which isaccepted. To the long-term goal, we can construct a mirror site in each country and keep master site inUSC. For each mirror site, we just keep the film data in the local language and English. So each mirrorsite can store more film data from the whole world.

4.2 Support Environment, Methods, and Tools

There are many tools we use in the AFDB software development process as follows:

Win-Win tool is used to negotiate among customer, user, and developer for the requirements capture.COCOMO II tool is for budget calculation.Rose 98 for the visual modeling of architecture design.Java JDK 1.1.7 (sun) and Frontpager from Microsoft are used for the project implementation.Microsoft word tool is used to product the documents.

4.3 ReviewsThis section identifies the major project reviews and their objectives. It provides the plans to preparefor, conduct, and follow up on the review meeting in order to achieve the objectives of each review.

The primary objective of each major review is to determine whether or not the project is ready toproceed to the next development phase. If so, the phase products reviewed are baselined and put underconfiguration management, to provide a stable foundation for the following phase.

4.3.1 Architecture Review Board I

The participants in this review contain user, customer, and developer and other stakeholders involvedin the project.


of 37

Reviews will be performed to satisfy the requirements of system development. The requirements willbe analyzed for feasibility and satisfaction of the all the results of the Win-Win negotiations.Requirements not satisfied will require a signed waiver from all the major stakeholders listed in theOCD.

CS577a ARB reviews need to put review materials on the Web a week in advance, and to arrange asatisfactory review time for their customers. Reviews include short highlight presentations by eachteam member, including a prototype demo.

4.3.2 Architecture Review Board II

The architecture designed, the developers in CS 577a team have to make sure that they have notforgotten any requirements or import features. All the risks have resolved. The development team willprovide the final project documents in the LCA package:

• Operational Concept Description• System and Software Requirement Description• System and Software Architecture Description• Life Cycle Plan• Feasibility Rational• System prototype

4.3.3 Architecture Review Board III

The LCA Architecture Rebaseline review is firstly to allow the members of the 577b team and theUSC library to review the overall content of the LCA package and make sure no other changes haveoccurred. During this review, the product improvement opinion from the individual critiques forCS577a team members should be considered. If new elements have come out, they must be integratedat this time in the system before commencement of the Construction Phase.

The review must verify that no interface design errors have been made for any module of the system.The review also checks that each individual module is well designed. So the final LCA architecturemust be fixed and used in the Construction Phase.

System Development Documents

• Project Plan• Software Requirements Specification• Software Development Files


of 37

4.3.4 Reviews/Inspections

This is the project-internal review hold for each unit of the software product. The participants onlycontain the developers in the CS577b team.

The team insures that each sub-module is tested and to make sure that the development of the project isin the right time schedule, and meets all associated requirements.

System Design and Test Documents

• Software Design Specification• Software Test Plan• Software Test Description and Results• Software Test Description and Documents

4.3.5 Transition Readiness ReviewThis review focuses mainly on the acceptability of the system. The customer will meet with thedevelopment team to discuss whether or not the software products are acceptable as it meets thecriteria agreed on for their acceptability. This is the final stage in the testing process before the systemis accepted for the operational use.

4.3.6 Release Readiness ReviewThis review is done at the end of the Construction Phase. It must verify that all stakeholders aresatisfied with the system acceptance test. Everything that is produced by the development team isaccepted.

The development team reviews with customers about the system release preparations including thequality of the system, training plan for the data manager and system administrators, user manual, andsupport for the system evolution in the future with the specific documents as following:

Version Description Documents

• System Configuration Description• Software User Manual, Data Manager Manual, System Administrator Manual• Software Version Description Document• Application Source Code(Hardcopy or Softcopy)


of 37

4.4 Project Communications

In order to develop the project smoothly and avoid the misunderstanding and going to the wrongdirection during the period of development, the communication between development members andcustomers is important, which is listed as follows:

CS577a development team CS577b development teamMeeting schedule withindevelopment teammembers

Once a week• To make sure the documents

are consistent and prototypecan cover the corecapabilities of system

Once a week• Reviews/inspections for the

unit test completion• Product progress monitoring• Programming problem

consultingMeeting schedulebetween the developerwith customers

Once a week• Through the Win-Win

negotiation to reachagreements for the criticalissues

• To describe the content ofeach document and demo theprototype to customers andmake sure that the system tobe designed is what theyreally need

• Ask for any changes for thesystem requirements in theearly stage

Each time when• Each incremental software

release• Software transition

Conference calls Each time for the ArchitectureReview Board I and II.• Analyze the LCO package in

ARB I• Analyze the LCA package in

ARB II

Each time for the system review.• ARB rebaseline review• Transition Readiness Review• Release Readiness Review

Tools for documentintegration

Use Microsoft word 7.0 forwriting the documents

Use Microsoft word 7.0 or thesupplied electronic templatesprovided for CS577b studentsfor writing the documents


of 37

4.5 Configuration Management

In this section, we provides a stable foundation for software development by establishing baselineversions of the key products, and maintaining them under a formal changes control process by thefollowing five functions:

• Configuration Identification

The key products to be baselined and the project milestones at which they enter the configurationmanagement process are described in the following table:

Stages:Phases:

Engineering Production

Inception Elaboration Construction Transition

Milestones: LCO LCA IOC

Requirements Set

Prototype

Architecture Design

Implementation Details

Management Set:• Business case• Work breakdown structure• Software development plans• Status assessments• Release description• Deployment documents

Deployment Set:• Integration• Associated run-time files• User’s Manual• Training

: weaker, less defined baselines : strong baselines

• Change Control

Change is happened frequently in the large software systems. Tracking changes to the technicalartifacts is crucial to understanding the true technical progress trends and quality trends to delivering


of 37

an acceptable end product or interim release. The following flow chart is to indicate the sequence oftasks and decisions involved in submitting, analyzing, approving, and procedures.

Customer Manager

Change Request

Change Analysis

Add change?

Need more conditionsAccepted

RejectedClosed

Flow Chart for Change Control

In the above flow chart, the customer manager provides the change request to the development team,and development team will do the change analysis to decide if the change can be received or not underthe budget and schedule of the project. If the change can be done under the current budget andschedule of project, the change can be accepted and processed in the project implementation. If not, thedevelopment team will provide the result of change analysis to the customer manage for either themore support on budget or schedule. If the further support can be satisfied, the change will beaccepted. Otherwise, go through other cycle to negotiate with customer. If the agreement still can notbe reached, the change will be rejected by the development team and inform the rejected report to thecustomer.

The following change request form will be used in the process of change control.


of 37

• Configuration Status Accounting

The development team is to provide the recording and reporting of the information that is needed tomanage a configuration effectively, including a listing of the approved configuration identification, thestatus of proposed changes to the configuration, and the implementation status of approved changes.

The customer has responsibility for anticipating to this activity with monitoring and verifying thecompleteness and correctness of the configuration items.

• Configuration Audits

For the development team, the team manager should verify that all required configuration items havebeen produced, that the current version agrees with specified requirements, that the technicaldocumentation completely and accurately describes the configuration items, and that all changerequests have been resolved.

P r o j e c t N a m e : A F D B

C h a n g e R e q u e s t e r : _ _ _ _ _ _ _ _ _ _ _ _ _ D a t e : _ _ _ _ _ _ _ _ _ _ _

D e s c r i p t i o n N a m e :

D is p o s i t i o n

T e s t

R e s o l u t io n

M e t r i c sC a te g o r y :

( 0 / 1 e r r o r , 2 e n h a n c e m e n t , 3 n e wf e a t u r e . 4 o t h e r )

I n i t i a l E s t i m a t e

B r e a k a g e : _ _ _ _ _ _ _R e w o r k : _ _ _ _ _ _ _

A c t u a l V a lu e s

A n a l y s i s : _ _ _ _ _ _ _ _ T e s t : _ _ _ _ _ _ _ _ _ _I m p le m e n t : _ _ _ _ _ _ _ D o c u m e n t : _ _ _ _ _ _ _ _ _

A n a ly s t : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S o f tw a r e C o m p o n e n t : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

M e t h o d : _ _ _ _ _ _ _ _ _ _ _ _ _ _ ( 1 I n s p e c t i o n . 2 A n a l y s i s .

3 D e m o n s t r a t i o n 4 T e s t )

S t a te : _ _ _ _ _ _ _ _ _ R e l e a s e : _ _ _ _ _ _ _ _ _ P r i o r i t y : _ _ _ _ _ _ _ _ ( 1 l o w , 5 h i g h )

A c c e p t a n c e : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ D a t e : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _C l o s u r e : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ D a t e : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

T e s t e r : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ P l a t f o r m s : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ D a t e : _ _ _ _ _ _ _ _ _ _ _ _ _


of 37

The customer should play a role in monitoring and verifying the whole process for the configurationaudits.

• Project Library Management

The AFDB system will store and operate on the USC Web servers. It should have the capabilities tocontinue work properly without change with the system software or hardware upgrading. The USClibrary should make sure that ISD can give full support for the operation and system maintenanceincluding general usage, storage and release of master copies, security, backup and recovery. In themeantime, the USC library has to perform his responsibility for data management in the AFDB system.

For the evolution of the AFDB system, the USC library should be responsible for finding fund andorganizing development team for the new version release.

4.6 Quality Management

Software quality management will be critical to the success of the whole project. The tester in projectteam who is charge of performing the quality control. It is very important that this team membershould not involve the coding and development to avoid having any assumption and influence.

The quality management usually contains the following functions as follows:

• Develop documentation and coding standards.• Verify the compliance between the products and the documentation and coding standards• Prepare test cases and produce test reports• Audit the project’s compliance with its plans, policies, and procedures. If the quality of project is found not to be satisfied in the part of implementation , the tester shouldcontact with project development team manager to hold a meeting with the programmer or designerwho is charging in this part to seek a solution.

4.7 Facilities and Related Concerns

Project development team will utilize the computer facilities in USC to implement and coding, withoutany investment from customer.


of 37

But customer should be charge of the preparation and maintenance of other essential equipment forfilm data digitalization such as scanner for scanning still film pictures and film digitalizationequipment etc. avoiding any project delay caused by the facilities shortage.

The DBMS construction is the essential part to assure the whole development process smoothly, theUSC library has to get permission for the to use the commercial DBMS provided by ISD in the wholedevelopment process.

4.8 Status Monitoring and Control

The customers from USC library are naturally a part of people who are involved in the statusmonitoring and control of project development because they have responsibility for monitoring theproject implementation and reviewing the system performance. Project development team managerplays a role in bridging between the customers and development team.

The several steps and relative documents should be presented as follows:

Before the project implementation begins, project development team will provide a projectdevelopment plan to customer. And project development team will hold a meeting with customerweekly to review the project progress and present relevant documents. Project team will notifycustomer about any changes about project plan.

During the incremental development of the project, the customer must know which step the systemdevelopment is and if it is developed under the development plan through the several reviewsdescribed above. The development team must provide the related documents according the milestonesof development and major project reviews. The development team manager must consult withcustomer on the development progress and problems in the regular meeting.

5. Resources

We will declaim how much resource the project will require to perform the functions in the previoussections.


of 37

5.1 Work Breakdown Structure

AFDB Work Breakdown Structure

AFDB PROJECT

SystemEngineering

SystemArchitecture design

DataCollection

Test andEvolution

Implementation

SystemDevelopment

DevelopmentManagement

LCAPackage

Reports IntegrationSystemAdministration

DatabaseConstruction

User’sNavigation

DataManagement

Win-WinNegotiation

OCD SSAD FR

Prototype LCPSSRD

Programming


of 37

For the CS577a development team, the following table is to indicate the person responsible for thetasks and budget based on the project’s WBS elements shown above.

TeamManager

TeamMember #1

TeamMember #2

TeamMember #3

TeamMember #4

Win-WinNegotiationOCDSSRDSSADLCPFRPrototypeDevelopmentManagementBudegt Free Free Free Free Free

For the CS577b development team, the following table is to indicate the person responsible for thetasks and budget based on the project’s WBS elements shown above.

TeamManager

SystemArchitect

Programmer# 1

Programmer# 2

Tester

SystemArchitectureDesignDatabaseConstructionUser’sNavigationDataManagementSystemAdministrationReportsIntegrationTest andEvaluationImplementationDevelopmentManagementBudget Free Free Free Free Free


of 37

For the customer, the following table is to indicate the responsible for the tasks and budget based onthe project’s WBS elements shown above.

CustomerData CollectionBudget 12 K for 100 films

5.2 Budgets

The following costs are associated with the software development activity:

• Personnel cost: This cost is essentially zero, since the development activity will be done by a teamof students.

• Related computer costs: This cost includes the installation, and maintenance cost only, since theproposed system does not require additional or special equipment not currently owned by thecustomer. However, since the support of the team of students who developed the system will mostlikely end at the end of the system, the customer may have to pay for personnel to do theinstallation and, later the maintenance. It may cost $80 K / year.

• Software product costs: the proposed system will most likely have costs associated with thelicensing of software components. If it can be provided by ISD, the cost is free too.

• Overhead Costs: office equipment cost, supplies costs, facilities costs, utilities cost. It may cost12K.

• Data preparation costs: $12 k for 100 films• Development Cost : Free• Implementation Cost: Free• Operation Cost: $150 K / year

6. Assumptions

The implementation the this project is based on these assumptions as:

• Stability of software product requirements, including external interfaces;• Stability of software requirement, required development schedules;• Continuity in the development effort;• On-schedule, definitive customer response to review issues and proposed changes.• Dependencies on computer systems or people external to this project.


of 37

7. Appendix

Refer to OCD 7 as the reference for the terms and abbreviation used in this document.

Life Cycle Plan

Documents

Transcript of Life Cycle Plan