SPMP

Carnegie Mellon University CMU-MSE-GRYPHON-SPMP–1.81.8School of Computer Science Spring 2000Master of Software Engineering

Gryphon

Software Project Management Plan

Version 1.8 April 25, 2000

Bob LindmanSteven Schirripa

Document Approvals

The following signatures are required for approval of this document. Note that since roles will change during the course of the project, the appropriate names should be added as needed, but the roles should remain the same.

___________________________________________ ______________________Bob Lindman – CMU MSE Program DateGryphon Team Lead

___________________________________________ ______________________Sid Kaul – CMU MSE Program DateGryphon Quality Assurance Manager

___________________________________________ ______________________Tony Lattanze – CMU Faculty or DateCliff Huff – SEI StaffGryphon Mentors

Gryphon SPMP version 1.8 2

Revision Log

Rev. Date Author(s) Comment

1.0 Sep. 14, 1999 Steven Schirripa Initial creation – based on Zephyr SPMP. This version was not baselined.

1.1 Oct. 13, 1999 Steven Schirripa Rework and incorporation of sections from Sid Kaul and George Tsang was completed.

1.2 Dec. 1, 1999 Steven Schirripa Rework and initial creation of many sections to meet requirements of Managing Software Development (MSD) course was done. This version begins compliance with the CM Plan[7]

1.3 Feb. 2, 2000 Bob Lindman Significant modifications in preparation for Cycle 3. Reformatted to match IEEE Std 1058-1998, added sections 2, 3, Table of contents, signature page, and Index. Reformatted all other sections and made substantial content additions.

1.4 Feb 8, 2000 Anne Jackson Edited file w/track changes in place: blue means suggested new text; strikethrough means suggested deletions.

1.5 Feb 10, 2000 Bob Lindman Incorporated Anne’s changes, fixed broken references.

1.6 Feb 15, 2000 Bob Lindman Incorporated some additional grammatical changes from Anne

1.7 Feb 24, 2000 Bob Lindman Made multiple format/grammar changes based on the document review. Some minor wording issues were corrected as well

1.8 April 25, 2000 Bob Lindman Made minor wording and format changes as suggested by our tech writer


Preface

The Software Project Management Plan (SPMP) for the Gryphon project outlines the managerial aspects of the project, including a description of deliverables and deadlines. The system to be built is an extension of the Zephyr AQP (ZAPS) product built by the 1998-99 Zephyr team at Carnegie Mellon University (CMU) in fulfillment of the Master of Software Engineering (MSE) Program. During the 1999-2000 academic year, the Gryphon team will continue the work started by Zephyr. Gryphon’s work will also serve to fulfill the requirements of the MSE Program at CMU. The customer for this project is Volant Systems, represented by K.D. VanDrie.

The Gryphon team consists of Sid Kaul, Bob Lindman, Steven Schirripa, Anne Jackson, Zia Syed, George Tsang, and Andy Zhou under the mentorship of Cliff Huff and Tony Lattanze. Note that Anne is the technical writer for the Spring 2000 semeser, and will likely be replaced by another technical writer for subsequent semesters.

Sections 1 through 3 provide an overview of the project. They include the project deliverables, plans to evolve this document, and acronym definitions.

Section 4 details the organization of the team and the project’s management structure.

Sections 5 and 6 include the process plans for the project.


Table of Contents

Document Approvals......................................................................................................................................2Revision Log....................................................................................................................................................3Preface.............................................................................................................................................................4Table of Contents............................................................................................................................................5List of Figures.................................................................................................................................................6List of Tables...................................................................................................................................................61 Overview..................................................................................................................................................7

1.1 Project summary...............................................................................................................................71.1.1 Purpose, scope and objectives..................................................................................................71.1.2 Assumptions and constraints....................................................................................................71.1.3 Project deliverables..................................................................................................................8

1.1.3.1 Software deliverables...........................................................................................................81.1.3.2 Documentation Deliverables................................................................................................8

1.1.4 Schedule and budget summary.................................................................................................81.2 Evolution of the plan........................................................................................................................9

2 References...............................................................................................................................................93 Acronyms...............................................................................................................................................104 Project organization.............................................................................................................................11

4.1 External interfaces..........................................................................................................................114.2 Internal structure.............................................................................................................................114.3 Roles and responsibilities...............................................................................................................12

5 Managerial process plans.....................................................................................................................135.1 Start-up plan...................................................................................................................................13

5.1.1 Staffing plan...........................................................................................................................135.1.2 Resource acqusition plan........................................................................................................145.1.3 Project staff training plan.......................................................................................................14

5.2 Control plan....................................................................................................................................145.2.1 Requirements control plan......................................................................................................145.2.2 Schedule control plan.............................................................................................................145.2.3 Quality control plan................................................................................................................155.2.4 Reporting plan........................................................................................................................155.2.5 Metrics collection plan...........................................................................................................15

5.3 Risk management plan...................................................................................................................155.4 Closeout plan..................................................................................................................................15

6 Technical process plans........................................................................................................................166.1 Process model.................................................................................................................................16

6.1.1 TSPe overview........................................................................................................................166.1.2 Modifications to TSPe............................................................................................................17

6.2 Methods, tools and techniques.......................................................................................................186.3 Infrastructure plan..........................................................................................................................186.4 Product acceptance plan.................................................................................................................18


1 List of Figures

Figure 1 - Gryphon Team Structure...............................................................................................................12Figure 2 - TSPe process for each cycle..........................................................................................................17

List of Tables

Table 1 - Software Deliverables.......................................................................................................................8Table 2 - Documentation Deliverables.............................................................................................................8Table 3 - Top Level Schedule..........................................................................................................................9Table 4 - Acronym List..................................................................................................................................10Table 5 - Roles and Responsibilities..............................................................................................................13Table 6 - Resource Acquisition Roles............................................................................................................14


1 OverviewThis section gives an overview of the purpose, scope, and objectives of the project. It also lists the assumptions and constraints, project deliverables; gives a brief summary of the schedule and budget, and ends with a plan for change in the SPMP.

1.1 Project summaryThe Gryphon project is a continuation of the Zephyr AQP System (ZAPS). As such, it is intended to extend the functionality of the existing product, and provide additional functionality to the final AQP system to be developed by Volant Systems.

1.1.1 Purpose, scope and objectivesConsidering the current state of ZAPS, Gryphon believes that a requirement analysis of the whole AQP system needs to be completed before deciding on a final statement of work. Based on comprehensive risk analysis done by Gryphon, following goals are set for GAPS (Gryphon AQP System):

1. Do a complete requirement analysis of the AQP system. Based on the requirements gathered in the requirement analysis phase come up with a final statement of work that is acceptable to both the customer and the Gryphon team.

2. Fine-tune and validate performance of the Data Model developed by the Zephyr team.

3. Develop a database population application that will create Task Analysis, Qualification Standards and Curriculum Development tables from the existing Excel spreadsheets.

After these items are accomplished, the Gryphon team will work with the customer to develop additional goals based on the results of these three items.

In addition, as the Gryphon project is under the guidance of the MSE program at Carnegie Mellon University, the focus of the project will be to produce a quality product using the techniques taught in the MSE Program. These include, for example, the use of a software process, planning techniques, and coding standards. The project will employ the use of the Studio Processes[3], and Team Software Process for Education (TSPe)[1], with modifications.

1.1.2 Assumptions and constraintsThe following assumptions will apply for the duration of the Gryphon project:

1. The development team has enough experience as a whole to complete the project.

2. Success or failure of the project is based on performance relative to the development process, and not the actual customer deliverables.

3. The customer will provide adequate access to potential users of the system, and will respond in a timely manner to all questions and requests for information.

The following constraints will also apply for the duration of the Gryphon project:

1. Team members’ time on the project (including studio time) will be limited to approximalty 12 hours per week for the fall and spring semesters, and 48 hours per week for the summer semester.


2. All studio time must be split between project work and other studio activities (classes, studio wide role, etc)

3. Additional resources (people or money) are not available for the project.

4. The Gryphon software will be built as a suplement to the software developed by Dave this year, which is based on the work Zephy did last year.

1.1.3 Project deliverablesThe Gryphon team will deliver all of the software and documentation associated with its product(s) to Volant Systems on August 4, 2000. In addition, a final report and presentation will be given to the studio audience at that time. These deliverables are described below.

Only a single copy of each deliverable shall be provided. For material given to the customer, an electronic copy of the material on a CD-ROM shall be sufficient. For studio deliverables, a printed hardcopy shall be provided.

Customer deliverables shall be considered delivered when presented to the customer contact. Studio deliverables shall be considered delivered when given to either of the Gryphon studio mentors, or their designee.

1.1.3.1 Software deliverables

Software Delivery DateAutopopulation Prototype Software March, 2000Autopopulation Software V1.0 April, 2000Gryphon Software v1.0 August 4, 2000

Table 1 - Software Deliverables

1.1.3.2 Documentation Deliverables

Document Delivery DateGryphon Statement of Work (SOW) Dec 1, 1999Gryphon Fall Semester Presentation Dec 8, 1999Initial Gryphon Software Requirements Specification (SRS) March, 2000Revised SOW with August deliverables defined March 2000 Gryphon Spring Semester Presentation May 2000Final Gryphon Software Requirements Specification (SRS) August 2000Gryphon Final Report and Presentation August 2000

Table 2 - Documentation Deliverables

1.1.4 Schedule and budget summaryTable 3 - Top Level Schedule gives a high level schedule for the Gryphon project. It summarizes when the major presentations will be given, when the primary deliverables will be given to the customer, and the start and end dates for the project.


A similar budget summary is not given, since the Gryphon team has little control over the budget. The major costs associated with the project are the time and and effort of the team members and associated personnel. Should this change, this section will be updated to reflect the new information.

Milestone DateProject Start August 1999Gryphon Fall Semester Presentation Dec 8, 1999Gryphon Spring Semester Presentation May 2000Final Gryphon Software / Document Delivery August 4, 2000Project End / Gryphon Final Report and Presentation August 4, 2000

Table 3 - Top Level Schedule

1.2 Evolution of the planThe SPMP is intended to be an evolving document. As management policies change from cycle to cycle, the SPMP should be updated by the team leader. Therefore, this document shall be placed under configuration management, in accordance with the CM Plan[7]. The document is to be revisited at the beginning of each cycle. These cycle dates are approximately six weeks in duration and are documented in the Gryphon project plan. Although the team leader is responsible for the revisions to this document, responsibility for sections may be delegated to other members of the team.

2 References

[1] Humphrey, Watts. Introduction to the Team Software Process. Draft Manuscript, 3/13/99.

[2] Jackson, Michael. Software Requirements and Specifications. Harlow, England: Addison-Wesley, 1995.

[3] MSE Studio Process Handbook. http://dogbert.mse.cs.cmu.edu/Process_Matrix_Role/proc_hand_index.html, Pittsburgh, PA, 1998.

[4] ANSI/IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans.

[5] Zephyr team, “Zephyr Software Project Management Plan 1.0,” Carnegie Mellon University, Master of Software Engineering Program, Pittsburgh, PA, February 1999.

[6] Gryphon Team, “Gryphon Software Requirements Specification 1.0,” Carnegie Mellon University, Master of Software Engineering Program,. Pittsburgh, PA, TBD.

[7] Gryphon Team, “Gryphon Configuration Management Plan 1.0,” Carnegie Mellon University, Master of Software Engineering Program, Pittsburgh, PA, December 1999.

[8] Gryphon Team, “Gryphon Quality Plan 1.0,” Carnegie Mellon University, Master of Software Engineering Program, Pittsburgh PA, TBD.


3 Acronyms

The following acronyms may be used in this SPMP.

Acronym DefinitionAQP Advanced Qualification ProgramCCB Configuration Control BoardCM Configuration ManagementCMU Carnegie Mellon UniversityEOSP End of Semester PresentationGAPS Gryphon AQP SystemLOC Line of CodeMSE Master of Software EngineeringPSP Personal Software ProcessSOW Statement of WorkSPMP Software Project Management PlanSQL Structured Query LanguageSRS Software Requirements SpecificationTBA To Be AnnouncedTBD To Be DeterminedTSPe Team Software Process for EducationWBS Work Breakdown StructureZAPS Zephyr AQP System

Table 4 - Acronym List


4 Project organizationSection 4.1 describes the external interfaces to the Gryphon team; 4.2, the internal structure of the team, and 4.3 gives a brief description of each of the roles held by the team members.

Knowledge of TSPe is assumed in describing the team’s organization. Readers lacking the background in TSPe are referred to Humphrey’s [1] book. Deviations from TSPe are seen with the customer liaison role and the splitting of the process/quality assurance (QA) manager into both a process manager and a QA manager.

4.1 External interfacesThe primary customer contact for Volant Systems is K.D. Van Drie. The Gryphon customer liaison is responsible for formal interaction between the Gryphon team and the customer contact. Though interaction can be done through anyone in the team, any discussions with the customer should be documented clearly for records.

All customer requests for services or changes to baseline Gryphon system configuration items must be in writing and approved by the project’s Configuration Control Board (CCB).

For all contractual interactions with the customer, Dr. James Tomayko is the representative for the team. He will coordinate his activities with the Gryphon team leader.

4.2 Internal structureThe basic Gryphon Team Structure is given in Figure 1 - Gryphon Team Structure. The reporting links in the structure imply that though the structure has a hierarchical shape, the reporting is not traditionally hierarchical. All members have specified areas of responsibility and everybody contributes equally to the project.

The team has a democratic structure in that all the team members can provide input to all decisions that the team makes. However, in general, greater weight will be given to the recommendations of the appropriate manager. This allows a democratic structure to exist, without burdening each team member with every decision that needs to be made. Note that the team roles will change throughout the life of the project.


Figure 1 - Gryphon Team Structure

4.3 Roles and responsibilitiesProject responsibilities in the Gryphon team are delegated in two ways. First, development tasks are divided among all six development engineers. Second, project management tasks are allocated according to the TSPe role held by each person during a given cycle. Project responsibilities specific to TSPe manager roles are listed in Table 5 - Roles and Responsibilities.

TSPe Role ResponsibilitiesTeam Lead Motivate the team to perform tasks and resolve issues

Track status of committed assignments Check that team members have submitted the required project data Check on change and issue tracking activity Press late team members to promptly submit the required work Report team status and progress to the instructor Lead the team in allocating tasks to individuals Act as facilitator in all team meetings Maintain the project notebook

Planning Manager Lead the team in producing the task plan (WBS) for the next cycle Lead the team in producing the schedule for the next cycle Lead the team in producing the balanced team development plan Track the team’s progress against the plan


Customer Liaison

Technical Writer

Team Leader

Development Manager

Support Manager

Process Manager

QA Manager

Planning Manager

TSPe Role ResponsibilitiesDevelopment Manager Lead the team in producing the development strategy

Produce initial size estimates for products to be developed Lead the development of the Gryphon SRS[6] Lead the team in producing the product conceptual design Lead the team in implementing the product Lead the development of the build and integration plan Lead the team in producing the system test plan Lead the team in producing the user documentation

Customer Liaison Keep frequent interaction with the customer Get information from the customer Communicate the interests of the team to the customer Manage communication for the team with all external entities

Process Manager Lead the team in defining and documenting its processes Maintain process improvement Maintain Process Improvement Proposals

QA Manager Lead the team in producing and tracking its quality plan Track where performance falls short of objectives and alert the team lead,

Studio Advisor, and the team Establish and maintain the team’s development standards and the system

glossary Setup and follow through on the teams reviews

Support Manager Lead the team in determining its support needs Obtain the needed tools and facilities Lead the team Change Control Board Manage the configuration management system Handle the team’s issue and risk tracking system Act as the team reuse advocate

Technical Writer Act as the primary editor for formal documents Ensure documents follow a consistent pattern Review written material intended for the customer

Table 5 - Roles and Responsibilities

5 Managerial process plans

5.1 Start-up planThis section conveys what materials, resources, etc. are required to start the project. Since most of this information was pre-defined for the Gryphon team, this section will not go into detail on the rationale for many of these choices.

5.1.1 Staffing planSection 4.2 Internal structure, shows the staffing resources for the project. Each team member will be available for 12 hours per week (this number includes all project and studio time) in the fall and spring semesters and 48 hours per week in the summer semester.

In addition to the core members shown in section 4.2, there will be several peripheral resources shared among all the studio teams. These include Studio Manager, Toolsmith, Configuration Manager, Librarian, and Process Manager. All of these resources will be available from August 1999 to August 2000.


5.1.2 Resource acqusition planAll resources for the project will be available at the start of the project and will not change substantially over time. The only planned changes are

The technical writer will change each semester The team member’s roles will change each semester

Many resources are provided for the MSE students. For example, computers are available with a variety of software. Additional software and support for computers is to be obtained through the Studio Toolsmith and Librarian, as described in the MSE Studio Process Handbook [3]. Other resources and their point of contacts are listed in Table 6 - Resource Acquisition Roles, including whose responsibility it is to obtain that resource.

Resource Contact Responsibility to Obtain ResourceSoftware Matrix Librarian Individual team member/Support ManagerHardware Matrix Toolsmith Support ManagerExternal inspections Matrix QA Specialist QA ManagerPresentation rehearsal advisors Linda Hutz Pesante,

mentorsCustomer Liaison

Rooms for meetings Matrix Studio Manager Customer LiaisonTraining Matrix Toolsmith,

Matrix Studio ManagerSupport Manager

Administrative assistance Phyllis Lewis Team Leader

Table 6 - Resource Acquisition Roles

5.1.3 Project staff training planMost of the training for the project will come from the MSE program courses, which include training on the studio process, TSPe, methods, models, etc. Since most of the team is not familiar with the problem domain, much of the first two cycles were devoted to AQP and airline training from the customer. (Refer to the plans and postmortems in Source Safe for cycles 1 and 2 for more details.) Additionally, training will be provided on demand for Visual Basic, Entity-Relation Modeling, and SQL.

5.2 Control planThis section specifics the required metrics, reporting frequency, and control systems to be used on the project.

5.2.1 Requirements control planAll requirements for the Gryphon project shall be documented in the SRS [6]. After the SRS is formally released, all changes shall be documented and approved via the guidelines established in the Configuration Management Plan [7].

5.2.2 Schedule control planThe Gryphon planning manager will maintain the schedule in a project document. He will be responsible for gathering the individual tasks for each team member and generating the plan for each cycle at the start of the cycle, including reasonable milestones based on the goals of each cycle. Each team member will record all time spent working on the Gryphon project by sending e-mail to the planning manager by the deadline each week, with a minimum resolution of at least 15 minutes. This will be tallied by the planning manager and reviewed in the weekly status meeting. In the case where the team goes more than one week


without correcting any delays introduced into the schedule, members will either re-plan or take other corrective actions to ensure the team both (1) has a reasonable schedule and (2) follows that schedule.

5.2.3 Quality control planQuality control is addressed in the QA Plan [8]. It is currently in a draft format that has not been distributed throughout the team. It addresses the process by which internal inspections are called and conducted. The interface with the external Matrix QA support is described in the MSE Studio Process Handbook [3]. To summarize, quality control will be enforced by requiring at a minimum internal inspections on all documents under CM. Checklists for the review of documents, for example, are available and have been used to review [7]. Verification and validation techniques have not been developed to date.

5.2.4 Reporting planInternal reporting for the Gryphon team will be relatively informal. Each team member will provide a status report to the planning manager by the deadline each week. The planning manager will use this information to compile a team status report for discussion at the team’s weekly team meeting. Mentors will be invited to attend the weekly meeting for general status issues. Additionally, each team member will have a regularly scheduled one-on-one meeting with their mentor to further discuss any issues.

External reporting will be more formal. Once at the end of each semester, the team will give a presentation on what items of significance were discovered that semester. Typically, this will be the team’s end of semester presentation (EOSP) for Studio. In addition, the team will give regular status reports to the customer to indicate progress. These reports need not be on a regular basis, but there should be at least two per semester. Where possible they should take the form of face-to-face meetings with the customer, however, if the customer is not available, a written report will be sufficient.

5.2.5 Metrics collection planThe metrics collected on the project will be limited to time spent on the project, lines of code (LOC) developed and defects discovered. Time spent will be recorded and analyzed as mentioned in section 5.2.2 Schedule control plan. Defects will be recorded and analyzed as described in the Gryphon Quality Plan [8].

5.3 Risk management planRisks will be managed through a list or spreadsheet to be developed by the Support Manager. The top few risks will be reviewed at each team meeting. This list will be maintained and updated by the Support Manager on as necessary.

5.4 Closeout planSince this project has a “normal” end associated with the completion of the MSE program, the closeout plan is minimal. At the end of the project, the following actions will occur:

All documents, source code, plans, etc. generated by the Gryphon team will be archived on the MSE server (currently dogbert)

A copy of all material will be given to the customer in electronic format on a CD-ROM All team members will graduate and no longer be the responsibility of the MSE program

6 Technical process plansThis section covers the tools and methods that will be used in the Gryphon Project to develop GAPS.


In particular it focuses on the methods, tools and techniques used in the project. A part of this section will also deal with the plan for the software documentation and support functions like quality assurance, configuration management and validation. All these elements of the project when put together will show the technical process being followed by the team.

6.1 Process model The Gryphon project will primarily use the Team Software Process for Education – TSPe [1]. Any deviations from this process will be documented in this section.

6.1.1 TSPe overviewBefore entering into any phase the team ensures that all the entry criteria for the phase have been fulfilled; similarly, at the end of every phase the completion of all the exit criteria needs to be ensured. The team begins the project by selecting roles for the team members and then setting the goals. Next, the team proceeds to the strategy phase, then the cycles are defined. In the strategy phase, team members create a list of strategies for the whole project and tasks to complete during the upcoming cycle. The planning and workload balance phases follow. All tasks required to implement the allocated requirements are determined and scheduled during these phases. Tasks from the development and the integration phases are executed throughout the cycle until the established end date, at which time the postmortem phase begins. In the postmortem phase, the team reflects on the previous cycle and generates a report containing all of the lessons it has learned. The team also documents tasks which were not completed so they can be scheduled in the next cycle. A detailed description of the activities in each phase of a TSPe cycle can be found in Humphrey’s [1] book.

Cycle Cycle Dates Cycle Goals1 Sept. 10, 1999 to Oct.

15, 1999 Learn the AQP/ZAPS system Train on VB Information gathering from various sources

2 Oct. 15, 1999 to Dec. 3, 1999

Deliver an SRS for Curriculum Development Build an Autopopulation prototype

3 Feb 4, 2000 to March 23, 2000

Complete Autopopulation tool Complete preliminary SRS Develop final SOW

4 March 23, 2000 to May 5, 2000

TBD

Table 7 - Gryphon Cycles

There will be changes in the way these cycles actually take place and these changes will be included in the updated versions of this document. These cycles shown are only for the fall 1999 / spring 2000 semesters.


The TSPe process has the following structure:

Figure 2 - TSPe process for each cycle

6.1.2 Modifications to TSPeResponsibilities of roles are adjusted and new roles are created and defined in section 4. Checklists and forms are not used in practice for every day-to-day activity, but if not otherwise mentioned, these forms are used. For example, the TSPe [1] requires checklists for inspections and the CM Plan [7] requires change request forms to be filled out. However, the STRAT and PLAN forms are not necessarily followed to the letter, rather, they are used as a guideline. Any formal documentation that would normally be in a form according to TSPe is instead included in a Word document with the meeting minutes for that meeting. If there are no minutes from the meeting, a Word document (or other text form) is created and placed in SourceSafe. This way the team has access to most documents in an electronic format.


LAUNCHchoose TSPe rolesdefine cycle goals

STRATEGYdefine deliverablesselect methods

PLANNINGdefine & assign tasksbalance workload

DEVELOPMENTproduce deliverablerecord datatrack project statusmanage risks

INTEGRATION & TESTtest deliverablesrecord data

POSTMORTEMreview goals vs. dataimprove processes

6.2 Methods, tools and techniques

All development for the project will be done in Microsoft Visual Basic 6.0. The team will also use some features of Microsoft SQL Server 7.0 (to interface with the databases). Additionally we may use Rational Rose and general purpose office software (MS Word, Excel, Visio, etc.). The methods that will be used may include E-R modeling and UML.

6.3 Infrastructure plan

The team has access to six Pentium II Windows NT Workstations and limited access to multiple laptops owned by members of the team. Apart from these systems the team also has access to two NT Servers. This hardware is available in the MSE Cave, Wean Hall 4615. In addition, the resources from the MSE program are available to the team such as office space in Wean 4615, copiers, fax machines, meeting rooms and other standard office equipment and resources.

6.4 Product acceptance planThere will be two forms of product acceptance for the project. The first is customer acceptance, the second is Studio acceptance.

For customer acceptance, the product will be delivered as per the Closeout plan section 5.4. Before closeout, the customer will be invited to review the material, both at the formal end of semester presentation for the studio class, and in a second, formal customer review. At that time, the program developed will be demonstrated, and it will be considered delivered and accepeted. This is because the team will disband at the end of the summer semester, so further work will not be possible.

For studio acceptance, all deliverables mentioned in section 1.1.3 Project deliverables will be provided to the appropriate people. In addition, the end of semester presentation will give an overview of the progress and results of the project. Again, since the team will disband at that time, the product will be considered delivered and accepted at the end of semester presentation.


Technology

SPMP