Life Cycle Plan
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
891
On Slideshare
891
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Asian Film Database System - LCP 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 Page 1 of 37
  • 2. Asian Film Database System - LCP TABLE OF CONTENTS: 1. INTRODUCTION......................................................................................................................................................... 3 1.1 PURPOSE OF THE LIFE CYCLE PLAN DOCUMENT ......................................................................................................... 3 1.2 REFERENCES ............................................................................................................................... ................................ 3 2. MILESTONES AND PRODUCTS...................................................................................................... ........................ 3 2.1 OVERALL LIFE CYCLE STRATEGY ............................................................................................................................... 4 2.2 SCHEDULES AND PHASE MILESTONES, DELIVERABLES, AND COMPLETION CRITERIA .............................................. 8 2.2.1 Engineering Stage............................................................................................................................................. 8 2.2.2 Production Stage ............................................................................................................................................ 10 2.2.3 Support Stage.................................................................................................................................................. 11 3. RESPONSIBILITIES ................................................................................................................................................. 11 3.1 ORGANIZATIONAL RESPONSIBILITIES........................................................................................................................ 12 3.1.1 Global Organization Charts ........................................................................................................................... 13 3.1.2 Organization commitment responsibilities ..................................................................................................... 13 3.2 STAKEHOLDER RESPONSIBILITIES ............................................................................................................................. 14 3.2.1 Engineering Stage........................................................................................................................................... 14 3.2.2 Production Stage ............................................................................................................................................ 18 3.2.3 Support Stage.................................................................................................................................................. 20 3.3 ORGANIZATIONAL IMPACTS ...................................................................................................................................... 21 3.3.1 Engineering Stage........................................................................................................................................... 21 3.3.2 Production Stage ............................................................................................................................................ 21 3.3.3 Support Stage.................................................................................................................................................. 22 4. APPROACH ................................................................................................................................................................ 22 4.1 RISK MANAGEMENT ................................................................................................................................................. 22 4.2 SUPPORT ENVIRONMENT, METHODS, AND TOOLS .................................................................................................... 25 4.3 REVIEWS ................................................................................................................................................................... 25 4.3.1 Architecture Review Board I........................................................................................................................... 25 4.3.2 Architecture Review Board II ......................................................................................................................... 26 4.3.3 Architecture Review Board III ........................................................................................................................ 26 4.3.4 Reviews/Inspections ........................................................................................................................................ 27 4.3.5 Transition Readiness Review .......................................................................................................................... 27 4.3.6 Release Readiness Review .............................................................................................................................. 27 4.4 PROJECT COMMUNICATIONS ..................................................................................................................................... 28 4.5 CONFIGURATION MANAGEMENT............................................................................................................................... 29 4.6 QUALITY MANAGEMENT........................................................................................................................................... 32 4.7 FACILITIES AND RELATED CONCERNS....................................................................................................................... 32 4.8 STATUS MONITORING AND CONTROL ....................................................................................................................... 33 5. RESOURCES .............................................................................................................................................................. 33 5.1 WORK BREAKDOWN STRUCTURE ............................................................................................................................. 34 5.2 BUDGETS .................................................................................................................................................................. 36 6. ASSUMPTIONS.......................................................................................................................................................... 36 7. APPENDIX.................................................................................................................................................................. 37 Page 2 of 37
  • 3. Asian Film Database System - LCP 1. Introduction This document is to identify the life-cycle stakeholders and life-cycle process model in top-level stage and increments. It mainly demonstrates top-level evidence to achieve objective to answer the common questions about the AFDB project, to plan the development schedule, to tell who will be responsible for performing the various software development functions, to tell where they will be performed, to tell how the project will implemented the software development strategy, to tell how much resources the project 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 software product 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 also important for customer, and useful for other stakeholders. 1.2 References Operational Concept Description System and Software Requirements Definition System and Software Architecture Description Feasibility Rationale 2. Milestones and Products This section tells what project functions will be performed during development, and what products will be developed. It contains schedules and milestones which indicate when each function and product will be completed. Page 3 of 37
  • 4. Asian Film Database System - LCP 2.1 Overall Life Cycle Strategy In the process of AFDB development, there are three stages of life cycle plan, which are Engineering Stage (consists of Inception and Elaboration Phases), Construction Stage (consists of Construction and Transition Phases) and Support Stage. The primary development process model to use in developing the AFDB is the spiral model. Each phase involves a spiral cycle in the developmental process, and each phase’s lessons learned are carried through to the next. In each phase of the model are several sequential activities, such as determining objectives, alternatives, and constraints for this phase; evaluating alternatives, identifying risks, and selecting an alternative; developing and verifying the product; and planning for the next phase. While the spiral model will be the primary overarching methodology used, a risk-driven waterfall model will be used to allow users to test the system as it is incrementally released, and provide timely feedback for inclusion in future incremental releases. Using this internal model is most effective when the core functionality is released to the customer in early increments, particularly when that core functionality covers the major risks identified from the initial spiral model iterations. This is because the primary benefit of the spiral model lies in its identification and resolution of critical risks associated with complex systems early in the development process. The risk-driven waterfall model reduces the possible disturbances arising from the inevitable requirement changes, and its explicit risk- management process assists resolution of risks associated with complex systems and schedule constraints. The major schedule constraint is that the system should have its hand-off to the USC library and the maintenance stakeholders completed on May 4, 1999. The risk-driven waterfall model strategy will implement the highest-risk system capabilities in the early incremental release, the final incremental release is scheduled to be completed by April 24, 1999. The core system capabilities will be guaranteed in this release. Features which are designated as non-essential may be included in this release if time and system reliability permit. Otherwise, continuation of further incremental releases to add additional non-essential features may be negotiated. The inclusion of such features will be made in the 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 major life-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 Architecture Rebaseline Review; followed by a risk-driven waterfall cycle, completed by a Transition Readiness Review) Page 4 of 37
  • 5. Asian Film Database System - LCP • 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 among stakeholders on the life-cycle objectives for the project. The primary objectives and activities of the Inception 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 what is 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 is the completion of the system's Life Cycle Objectives (LCO) document to demonstrate the concurrence of each stakeholder with the system. The project's scope is established by the LCO, defining the system's top-level objectives, requirements, architecture, core capabilities, and software development plan. 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 to commit to the Construction Phases. The primary objectives and activities of the Elaboration Phase includes: • 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 stable enough, and risks sufficiently mitigated. Page 5 of 37
  • 6. Asian Film Database System - LCP The system’s core capabilities are divided into the main components as developed during the LCO process. The capabilities are categorized based on standard object oriented analysis, that the capabilities within a module are both data and functionally cohesive. In this phase, the milestone is determination of the Life Cycle Architecture (LCA), which is primarily concerned with elaborating the elements specified in the LCO. The definition of the system architecture is key to the LCA. As with the LCO, the LCA milestone is the concurrence of each stakeholder with the system described in the LCA documents. A series of basic prototypes of the system, largely "snapshot prototypes" which give an indication of the types of GUIs which could be produced and their relative benefits, were developed during the Inception Phase, and have been demonstrated to team members and the customer. The completion of the LCA ARB Review is the final milestone for this phase. Construction Phase The Construction Phase of the software development process implements the all system essential functions 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 Phase includes: 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 the core capabilities of user, data manager, and system administration; and do the unit test for each function. • HTML generator to create HTML pages with each query functions for the user, data manager, and system 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 Page 6 of 37
  • 7. Asian Film Database System - LCP • Perform all essential applications including user’s navigation, manager’s update, client’s data entry, 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 the members of the 577b team and the USC library to clarify any outstanding design issues. During this time, new issues may be raised which need to be examined before commencement of the Construction Phase. 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 issue clarification and addressing may continue, but from a schedule and architecture standpoint the fewer drastic changes made past this point the better. The Construction Phase specifies how the LCA is to be implemented. The creation of a Construction Specification, which specifies the detailed design for the system's architecture and software modules, is to be completed in this phase. Also commencing in this phase is the development of an Integration and Test Plan, as well as a System Acceptance Test Plan. The risks identified by the Construction Review will be included in the scope of the system prototype to aid in their assessment. The completion of the Construction Review is the milestone signifying the end of the Elaboration Phase. The Construction phase of each software development release requires the detailed design of the modules in the Construction Specification. The modules and their core system capabilities are listed below. The end of the Construction Phase is marked by satisfaction of the listed core capabilities (See the system priority outlined in section 3.1 of FR), confirmed during an Inspection Review for that incremental release. The Integration and Test plan of each incremental release involves testing and integration of the new modules contained within that release, as well as regression testing of modules contained in prior releases. Upon completion of the integration and testing for this increment, the development team will hold a Unit Test Completion Review for each incremental development release. The milestone for each incremental release is the completion of this review. The Construction Phase of each incremental release involves the addition of the new increment into the existing system. Following the System Acceptance Test Plan, system level tests are run to verify the correct functioning of the system. The Construction Phase milestone is the completion of a System Acceptance 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 user feedback. Page 7 of 37
  • 8. Asian Film Database System - LCP • Achieve stakeholders concurrence that deployment baselines are complete and consistent with the evaluation 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 the CS577 a/b course spanning over two semesters. Based on the different phases shown in Life Cycle Plan 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 synchronized with milestones for preparation of test drivers, facilities, equipment, data, post- processors, etc. for the various increment. 2.2.1 Engineering Stage The CS577a team members will gather the requirements through Win-Win negotiation used within the all stakeholders from the AFDB system, then formulate operational concepts, requirement specifications, architectures, prototypes, life cycle plans, and integrating rationale for the proposed capabilities. During this stage, the customers from USC library will have to participate in the validation of the AFDB prototype is exactly meet what they need. They have to make a clear schedule time to communicate with development team and give them a feedback on the project implementation. If they have to change some functions that may influence the prototype, they have to make sure that this improvement 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 Criteria Win-Win Oct. 19, 1998 Document Most win conditions for all the Negotiation stakeholder properly identified, and some of the conflicting win conditions properly resolved. Initial Oct. 19, 1998 Web-based Availability of the basic Prototype Application prototype to customer for initial feedback. LCO Drafts Oct. 28, 1998 Web-based See a draft for every artifact with Document TBD’s. Page 8 of 37
  • 9. Asian Film Database System - LCP Give your team members the opportunity to review your work, and to ensure consistency between the various artifacts. LCO Package Nov. 4, 1998 Web-based Establish the system boundary Document and specify the scope of project by defining the top-level objectives of the system. Intermediate Nov. 4, 1998 Wed-based TBD’s in initial prototype should Prototype Document have been cleared by now. Functionality added, or refined according to refinement in requirements, and results of win- win negotiation. LCO Package Nov. 9, 1998 - Wed-based Demo the every artifact in LCO Architecture Nov. 13, 1998 Document package with customers and get Review and Application feedback on it and give an Boards initially solution for TBD’s LCA Drafts Dec. 2, 1998 Web-based See a draft for every artifact Document without TBD’s. Give your team members the opportunity to review your work, and to ensure consistency between the various artifacts. LCA Package Dec. 7, 1998 - Web-based Demo the every artifact in LCA Architecture Dec. 11,1998 Document and package with customers and get Review Application feedback on it Boards LCA Package Dec. 14, 1998 Web-based The critical element is the Document definition of the system and software architecture. It includes the definitions of the system and software components, connectors, and constraints. The specifications of COTs and architectural evolution are also the key features of the LCA Final Dec 14, 1998 Web-based The critical element is the Prototype Application definition of the system and software architecture. It includes the definitions of the system and software components, connectors, and constraints. The specifications of COTs and architectural evolution are also the key features of the LCA Page 9 of 37
  • 10. Asian Film Database System - LCP 2.2.2 Production Stage In CS577b team members will plan to have student teams develop initial operational capability products based on the best results from CS577a. For the development team, they should have to be familiar with the operation of DBMS and complete the 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 team Jan. 26, 1999 Five students selected to be the formation development team and one was elected to be development manager ARB Rebaseline Feb. 2, 1999 Web-based • Discuss the individual critiques Review document from CS577a team members • Revise LCA Software Feb. 9, 1999 document • Project plan Development Plan • Software requirements specification • Initial software development files • Metrics report Increment I Feb.23, 1999 Web-based • Incremental software release I Development and application and • Test review for this release Unit Test document • Metrics report Increment II Apr. 6, 1999 Web-based • Incremental software release II Development and application and • Test review for this release Unit Test document • Metrics report Increment III Apr. 20, 1999 Web-based • Incremental software release III Development and application and • Test review for this release Transition Plan document • Metrics report • System acceptance review report • Transition plan and preparation Transition Readiness Apr. 20, 1999 Web-based • Software Acceptance Review Review application and document Software transition May 4, 1999 Web-based • Transition activities application and • Software user manual document • Software version description document Release Readiness May 4, 1999 Web-based • System Acceptance Review Review application and • Review system preparation, Page 10 of 37
  • 11. Asian Film Database System - LCP document training, usage, and evolution support with customers System operation May 14, 1999 Web-based • System operation and maintenance and maintenance application on 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 the development team at the beginning of the Construction Phase. They also are responsible for the product release version when the product is operated on the USC Web server. In the future, the different 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 the new 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. It defines the major organizational components of the development project, and indicates their responsibilities across the phases of the development cycle. It presents organization charts showing individual 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 Page 11 of 37
  • 12. Asian Film Database System - LCP 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 release System 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 Page 12 of 37
  • 13. Asian Film Database System - LCP 3.1.1 Global Organization Charts Other Countries USA China India Taiwan Japan Korea Users USC Users Clients Users UCS USC Library USC Students Administrator Asian Film Database CSCI577a CSCI577b Manager Team 3 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 be ratified by all organizational stakeholders directly involved with the development, operation, and maintenance of the AFDB system. Those organizations include the Library Department at USC, and the development team from the Fall 1998 CS577a class to the development team from Spring 1999 CS577b class. Page 13 of 37
  • 14. Asian Film Database System - LCP The Development Team Manager from each team is responsible for committing the development team to any changes in the project schedule, scope, or budget. Prior to committing the development team to any project changes, The Development Team Manager will gather input from development team members 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 for committing 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. 3.2.1 Engineering Stage The stakeholders’ responsibilities in the engineering stage are listed as follows: Inception Elaboration User • Specify the definition of • Review project development requirements architecture, designs and • Define the operational concepts prototypes during ARB • Prepare the operational plan • Negotiate the win-win conditions with other stakeholders Customer • Support the definition from the • Monitor and evaluate the customer’s concern project progress at the • Review the definition of milestones and schedule of requirements, operational deliverable concepts and plan from user • Supply data for the testing of • Accept or reject options during the system under negotiation with the win-win development and for testing conditions with other of the database stakeholders • Review project development • Identify, negotiate transition architecture, designs and requirements, strategies, and prototypes during ARB deliverables Developer • Prepare the documents of OCD, • Modify and refine SSRD, LCP, FR, sketch SSAD architecture and design based Page 14 of 37
  • 15. Asian Film Database System - LCP and prototype on the good feedback for • Support the interface LCO from ARB specification • Present the LCA package • Present the LCO package during during the ARB the ARB • Modify and refine architecture and design based on the good feedback for LCA from ARB Development Responsibilities A team of five students from CS577a (Fall 1998 semester) will be responsible for the system engineering of the AFDB system. In the roughly 12-week period between September 23, 1998 and December 14, 1998, Team members will be responsible for formulating the LCO and LCA versions of the 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 primary responsibilities 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 Development Team Manager (CS577a student) Project Development Project Development Project Development Project Development Team Member # Team Member Team Member #3 Team Member #4 (CS577a student) (CS577a student) (CS577a student) (CS577a student) Page 15 of 37
  • 16. Asian Film Database System - LCP Detailed roles and responsibilities for each development team member in this stage are as follows: Team Responsibilities Life Cycle Objectives Life Cycle Architecture Members (LCO) (LCA) Team Operational • Top-level system • Elaboration of system Member #1 Concept objectives and scope objectives and scope by Definition such as system increment (OCD) boundary, environment • Elaboration of parameters and operational concept by assumptions, evolution increment parameters • Operational concept such as operations and maintenance scenarios and parameters, organizational life- cycle responsibilities (stakeholders) Team System • Exercise key usage • Exercise range of usage Member #2 Prototype(s) scenarios scenarios • Resolve critical risks • Resolve major outstanding risks Team Definition of • Top-level functions, • Elaboration of functions, Member #3 System and interfaces, quality interfaces, quality Software attribute levels, attributes by increment Requirements including growth • Identification of TBDs (SSRD) vectors, priorities (to-be-determined items) • Stakeholders’ • Stakeholders’ concurrence on concurrence on their essentials priority concerns Project System and • Top-level definition of • Choice of architecture Development Software at least one feasible and elaboration by Team Architecture architecture including increment Manager Definition physical and logical • Physical and logical (SSAD) elements and components, relationships and connectors, choices of COTS and configurations, reusable software constraints elements • COTS, reuse choices • Identification of • Domain-architecture and unfeasible architecture architectural style choices options • Architecture evolution Page 16 of 37
  • 17. Asian Film Database System - LCP parameters Team Life-Cycle • Identification of life- • Elaboration of Member #4 Plan (LCP) cycle stakeholders WWWWWHH* for • Users, customers, Initial developers, Operational Capability maintainers, general (IOC) public, others • Partial elaboration, • Identification of life- identification of key cycle process model TBDs for later • Top-level stages, increments increments • Top-level WWWWWHH* by stage Team Feasibility • Assurance of • Assurance of consistency Member #1 Rationale (FR) consistence among among elements above and #3 and elements above • All major risks resolved #4 and Team • Via analysis, or covered by risk Manager measurement, management plan prototyping, simulation, etc. • Business case analysis for requirements, feasible architectures * 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 support Object-oriented Language UML 4.0 for Object-oriented software architecture designing. Page 17 of 37
  • 18. Asian Film Database System - LCP 3.2.2 Production Stage The stakeholders’ responsibilities in the production stage are listed as follows: Construction Transition User • Short win-win spiral cycle between • Evaluate the product and give usage the stakeholders feedback to the system • Review and test each increment in administrator the development environment. • Review and test each increment in • Provide test support. the development environment. Customer • ARB rebaseline Review • Monitor the product progress • Facility preparation (computer, • Provide administrative support to scanner, the product transition • Short win-win spiral cycle between • Refine transition strategy; Prepare the stakeholders for transition • Monitor the product progress at the • Review system performance development milestones and • Operate and maintain system schedule of deliverable • Perform data manager and system administrator’s responsibilities • Review system performance Developer • Short win-win spiral cycle between • Validate interface in operational the stakeholders environment • Implement and integrate product • Adapt the product to operate in • Perform and support test different environment. • Provide administrative support to the product transition Clients • Short win-win spiral cycle between • Evaluate the product and give usage the stakeholders feedback to the system • Perform and support test with administrator providing film data Development Responsibilities A team of five students from CS577b (Spring 1999 semester) will be responsible for the development of the AFDB system. In the roughly 12-week period between Jan. 26, 1999 and Apr. 20, 1999, this team will be responsible for the product design and four incremental development phases associated with the development process. Page 18 of 37
  • 19. Asian Film Database System - LCP Development Organization Chart Project Development Team Manager (CS577b student) System Architect Programmer1 Programmer 2 Tester (CS577b student) (CS577b student) (CS577b student) (CS577b student) Detailed roles and responsibilities for each development team member are described in the following sections. Project Development Team Manager The role of the Project development team manager will be assumed by one of the CS577b team members, who will be responsible for all project-level management functions. The main responsibilities 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 the system’s software modules and other associated project activities. These activities include the product design, programming, module and system level testing, quality assurance, and the production of manuals. Each of the four members reports directly to the Project Development Team Manager. The responsibilities assigned to each of the members are detailed in the following paragraphs. System Architect: (one student) Page 19 of 37
  • 20. Asian Film Database System - LCP • 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's capabilities after each incremental release. These sessions are intended to provide an overview of the system's functionality and the improvements made. A separate training session for the system administrator and data manager may be scheduled to assist in the hand-off of development responsibilities. The project developers will be available to give an overview of the programmer's guide and answer questions as needed at that meeting. 3.2.3 Support Stage Page 20 of 37
  • 21. Asian Film Database System - LCP During this stage, the system administrator from ISD is responsible for the system installation and maintenance on the USC Web server based on the instruction in User Manual. The development team is responsible for training the system administrator for his duty. In the operation of the initial AFDB system, 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. 3.3.1 Engineering Stage Organizational Impacts User • System requirements Customer • Product performance including prototyping, requirements gathering etc. • Product progress including staffing, training etc. Developer • Product interface in operational environment • Product architecture design • Operational environment of product 3.3.2 Production Stage Organizational Impacts User • Development progress in each increment Customer • 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 Page 21 of 37
  • 22. Asian Film Database System - LCP 3.3.3 Support Stage Organizational Impacts User • Actual usage on the AFDB Customer • 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 project functions. It presents the project’s approach for risk management, and for performing software requirements analysis, design, development, test, and implementation functions. It describes how the project will perform associated project functions such as technical reviews, project communications, configuration management, quality management, facilities management, security, and subcontractor management. 4.1 Risk Management The risk management plan is to identify the major sources of risk in the development of project, and show how the project will address, monitor, and resolve these risks. Unstable requirements Page 22 of 37
  • 23. Asian Film Database System - LCP • Risk: This will be one of the biggest risk in this project, because currently customers don’t have actual business or system, a large part of requirements are based on customer’s plan. And this system will involve global users from outside states, who has very high influence on the decision and requirements. • Risk management: The Architecture Rebaseline review is time to allow the members of the 577b team and the USC library to clarify any outstanding design issues. During this time, new requirements may be raised which need to be examined before commencement of the design phase. This phase has to be stopped on Feb. 2, 1999 for handoff to the Construction Phase. Further issue clarification and addressing may continue, but from a schedule and architecture standpoint the fewer drastic changes made past this point the better. Schedule constraints • Risk This will be another one of the biggest risks in this project, since the whole project with so many requirements should be completed by the end of spring semester in 1999, it can not be changed. A schedule risk exists because it is not known if the whole of the capabilities requested by the user can be implemented. • Risk management: In order to meet the schedule deadline, the core capabilities were identified and prioritized by the stakeholders with respect to the feasibility of completing those tasks in one semester. This means that the highest priority system capabilities will be developed and released to the customer early in the process. This allows the stakeholders to keep closer track progress, and to have more time for identification and resolution of current risks. Personal shortfalls • Risk To 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. Page 23 of 37
  • 24. Asian Film Database System - LCP • 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 minimum level 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 or technology changes. Further reduction can be made by assigning different project parts to team 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 the expenses, 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 software products based on the system requirements, the development team can go though Win-Win negotiation with customer regarding the choice of the tools and software products and demonstrate the advantage and 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 of states, which causes it very difficult to collect and work out the user interface to meet all their requirements. There are also user interface mismatch between what the developers design and what the customers expect in the end of implementation. • Risk management Thought the Win-Win negotiation with all stakeholders, the user characterization including the functionality, style, and workload has to be identified. Development team will identify the real users based on the analysis of user characterization. The development team has firstly demonstrated the prototype to the customers and shows the all operational scenarios in the prototype. If agreement has been reached, it will be not allowed to change during the development. Page 24 of 37
  • 25. Asian Film Database System - LCP Evolution and location requirements • Risk Since the huge amount of the films produced each year in the five countries in Asia, the large database is asked to store the film data. Thinking about the product evolution described in SSRD 6.1, it is a big risk that we may run out of the memory if we just keep storing the film data in the database or we expand 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 film records in the database. The size of the database can be designed to store 10,000 film records, which is accepted. To the long-term goal, we can construct a mirror site in each country and keep master site in USC. For each mirror site, we just keep the film data in the local language and English. So each mirror site 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 Reviews This section identifies the major project reviews and their objectives. It provides the plans to prepare for, 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 to proceed to the next development phase. If so, the phase products reviewed are baselined and put under configuration 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 involved in the project. Page 25 of 37
  • 26. Asian Film Database System - LCP Reviews will be performed to satisfy the requirements of system development. The requirements will be 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 the OCD. CS577a ARB reviews need to put review materials on the Web a week in advance, and to arrange a satisfactory review time for their customers. Reviews include short highlight presentations by each team 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 not forgotten any requirements or import features. All the risks have resolved. The development team will provide 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 the USC library to review the overall content of the LCA package and make sure no other changes have occurred. During this review, the product improvement opinion from the individual critiques for CS577a team members should be considered. If new elements have come out, they must be integrated at 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 architecture must be fixed and used in the Construction Phase. System Development Documents • Project Plan • Software Requirements Specification • Software Development Files Page 26 of 37
  • 27. Asian Film Database System - LCP 4.3.4 Reviews/Inspections This is the project-internal review hold for each unit of the software product. The participants only contain 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 is in 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 Review This review focuses mainly on the acceptability of the system. The customer will meet with the development team to discuss whether or not the software products are acceptable as it meets the criteria agreed on for their acceptability. This is the final stage in the testing process before the system is accepted for the operational use. 4.3.6 Release Readiness Review This review is done at the end of the Construction Phase. It must verify that all stakeholders are satisfied with the system acceptance test. Everything that is produced by the development team is accepted. The development team reviews with customers about the system release preparations including the quality of the system, training plan for the data manager and system administrators, user manual, and support 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) Page 27 of 37
  • 28. Asian Film Database System - LCP 4.4 Project Communications In order to develop the project smoothly and avoid the misunderstanding and going to the wrong direction during the period of development, the communication between development members and customers is important, which is listed as follows: CS577a development team CS577b development team Meeting schedule within Once a week Once a week development team • To make sure the documents • Reviews/inspections for the members are consistent and prototype unit test completion can cover the core • Product progress monitoring capabilities of system • Programming problem consulting Meeting schedule Once a week Each time when between the developer • Through the Win-Win • Each incremental software with customers negotiation to reach release agreements for the critical • Software transition issues • To describe the content of each document and demo the prototype to customers and make sure that the system to be designed is what they really need • Ask for any changes for the system requirements in the early stage Conference calls Each time for the Architecture Each time for the system review. Review Board I and II. • ARB rebaseline review • Analyze the LCO package in • Transition Readiness Review ARB I • Release Readiness Review • Analyze the LCA package in ARB II Tools for document Use Microsoft word 7.0 for Use Microsoft word 7.0 or the integration writing the documents supplied electronic templates provided for CS577b students for writing the documents Page 28 of 37
  • 29. Asian Film Database System - LCP 4.5 Configuration Management In this section, we provides a stable foundation for software development by establishing baseline versions of the key products, and maintaining them under a formal changes control process by the following five functions: • Configuration Identification The key products to be baselined and the project milestones at which they enter the configuration management process are described in the following table: Stages: Engineering Production Phases: 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 technical artifacts is crucial to understanding the true technical progress trends and quality trends to delivering Page 29 of 37
  • 30. Asian Film Database System - LCP an acceptable end product or interim release. The following flow chart is to indicate the sequence of tasks and decisions involved in submitting, analyzing, approving, and procedures. Customer Manager Change Request Change Analysis Accepted Add change? Need more conditions Rejected Closed 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 under the budget and schedule of the project. If the change can be done under the current budget and schedule of project, the change can be accepted and processed in the project implementation. If not, the development team will provide the result of change analysis to the customer manage for either the more support on budget or schedule. If the further support can be satisfied, the change will be accepted. Otherwise, go through other cycle to negotiate with customer. If the agreement still can not be reached, the change will be rejected by the development team and inform the rejected report to the customer. The following change request form will be used in the process of change control. Page 30 of 37
  • 31. Asian Film Database System - LCP P r o je c t N a m e : AFD B C h a n g e R e q u e s te r : _ _ _ _ _ _ _ _ _ _ _ _ _ D a te : _ _ _ _ _ _ _ _ _ _ _ D e s c rip tio n N am e: M e tric s ( 0 /1 e rro r, 2 e n h a n c e m e n t, 3 n e w C a te g o r y : fe atu re. 4 o th er) I n i tia l E s tim a te A c t u a l V a lu e s B re ak a g e: _ _ _ _ _ _ _ A n a ly sis:_ _ _ _ _ _ _ _ T e st: _ _ _ _ _ _ _ _ _ _ R e w o rk : _ _ _ _ _ _ _ I m p le m e n t: _ _ _ _ _ _ _ D o c u m e n t: _ _ _ _ _ _ _ _ _ R e s o lu tio n A n a ly s t: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ S o f tw a re C o m p o n e n t: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ T est M e t h o d : _ _ _ _ _ _ _ _ _ _ _ _ _ _ ( 1 I n s p e c ti o n . 2 A n a ly s is . 3 D e m o n s t ra t io n 4 T e s t) T e s te r : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ P la tf o r m s : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ D a te : _ _ _ _ _ _ _ _ _ _ _ _ _ D is p o s itio n S ta te : _ _ _ _ _ _ _ _ _ R e le a s e : _ _ _ _ _ _ _ _ _ P r io r ity : _ _ _ _ _ _ _ _ (1 lo w , 5 h ig h ) A c c e p ta n c e : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ D a te : _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ C lo su re : ____________________________ D ate: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ • Configuration Status Accounting The development team is to provide the recording and reporting of the information that is needed to manage a configuration effectively, including a listing of the approved configuration identification, the status 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 the completeness and correctness of the configuration items. • Configuration Audits For the development team, the team manager should verify that all required configuration items have been produced, that the current version agrees with specified requirements, that the technical documentation completely and accurately describes the configuration items, and that all change requests have been resolved. Page 31 of 37
  • 32. Asian Film Database System - LCP The customer should play a role in monitoring and verifying the whole process for the configuration audits. • Project Library Management The AFDB system will store and operate on the USC Web servers. It should have the capabilities to continue work properly without change with the system software or hardware upgrading. The USC library should make sure that ISD can give full support for the operation and system maintenance including general usage, storage and release of master copies, security, backup and recovery. In the meantime, 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 and organizing 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 project team who is charge of performing the quality control. It is very important that this team member should 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 should contact with project development team manager to hold a meeting with the programmer or designer who 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, without any investment from customer. Page 32 of 37
  • 33. Asian Film Database System - LCP But customer should be charge of the preparation and maintenance of other essential equipment for film data digitalization such as scanner for scanning still film pictures and film digitalization equipment etc. avoiding any project delay caused by the facilities shortage. The DBMS construction is the essential part to assure the whole development process smoothly, the USC library has to get permission for the to use the commercial DBMS provided by ISD in the whole development process. 4.8 Status Monitoring and Control The customers from USC library are naturally a part of people who are involved in the status monitoring and control of project development because they have responsibility for monitoring the project implementation and reviewing the system performance. Project development team manager plays 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 project development plan to customer. And project development team will hold a meeting with customer weekly to review the project progress and present relevant documents. Project team will notify customer about any changes about project plan. During the incremental development of the project, the customer must know which step the system development is and if it is developed under the development plan through the several reviews described above. The development team must provide the related documents according the milestones of development and major project reviews. The development team manager must consult with customer 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 previous sections. Page 33 of 37
  • 34. Asian Film Database System - LCP 5.1 Work Breakdown Structure AFDB Work Breakdown Structure AFDB PROJECT System Development System Engineering Management Development System Data Test and LCA Win-Win Architecture design Collection Evolution Package Negotiation Programming Implementation OCD SSAD FR SSRD LCP Prototype Database User’s Data System Reports Integration Construction Navigation Management Administration Page 34 of 37
  • 35. Asian Film Database System - LCP For the CS577a development team, the following table is to indicate the person responsible for the tasks and budget based on the project’s WBS elements shown above. Team Team Team Team Team Manager Member #1 Member #2 Member #3 Member #4 Win-Win Negotiation OCD SSRD SSAD LCP FR Prototype Development Management Budegt Free Free Free Free Free For the CS577b development team, the following table is to indicate the person responsible for the tasks and budget based on the project’s WBS elements shown above. Team System Programmer Programmer Tester Manager Architect #1 #2 System Architecture Design Database Construction User’s Navigation Data Management System Administration Reports Integration Test and Evaluation Implementation Development Management Budget Free Free Free Free Free Page 35 of 37
  • 36. Asian Film Database System - LCP For the customer, the following table is to indicate the responsible for the tasks and budget based on the project’s WBS elements shown above. Customer Data Collection Budget 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 team of students. • Related computer costs: This cost includes the installation, and maintenance cost only, since the proposed system does not require additional or special equipment not currently owned by the customer. However, since the support of the team of students who developed the system will most likely end at the end of the system, the customer may have to pay for personnel to do the installation and, later the maintenance. It may cost $80 K / year. • Software product costs: the proposed system will most likely have costs associated with the licensing 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 cost 12K. • 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. Page 36 of 37
  • 37. Asian Film Database System - LCP 7. Appendix Refer to OCD 7 as the reference for the terms and abbreviation used in this document. Page 37 of 37