bcit comp 8081 evolutionary delivery planning assignment by wesley kenzie, november 2010

BCIT Computing and Information Technology COMP 8081 Management Issues in Software Engineering Due Date: November 10, 2010 Author: Arthur (Wesley) Kenzie A00242330 Assignment 2: Evolutionary Delivery Planning (Final Version) ______________________________________________________________________________

______________________________________________________________________________Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. of 18

1. Introduction and Assumptions .......................................................... page 2 2. Step Descriptions ............................................................................. page 3 2.1 Step 1: Supervisor Control .................................................................... page 3 2.1.1 Rationale 2.1.2 Functionality Planned 2.1.3 Development and Target Environment 2.1.4 Customer 2.1.5 Testing 2.2 Step 2: Vat Quantity Control .......................................................... page 5 2.2.1 Rationale 2.2.2 Functionality Planned 2.2.3 Development and Target Environment 2.2.4 Customer 2.2.5 Testing 2.3 Step 3: Vat pH Control .................................................................... page 7 2.3.1 Rationale 2.3.2 Functionality Planned 2.3.3 Development and Target Environment 2.3.4 Customer 2.3.5 Testing 2.4 Step 4: Bottle Movement .................................................................... page 9 2.4.1 Rationale 2.4.2 Functionality Planned 2.4.3 Development and Target Environment 2.4.4 Customer 2.4.5 Testing 2.5 Step 5: Bottle Filling .................................................................... page 10 2.5.1 Rationale 2.5.2 Functionality Planned 2.5.3 Development and Target Environment 2.5.4 Customer 2.5.5 Testing 3. Schedule and Labour Estimate .......................................................... page 12 4. Bibliography ............................................................................. page 18



1. Introduction and Assumptions This assignment is intended to demonstrate an understanding of the Evolutionary Delivery lifecycle, which is applied to the development of a microprocessor-based bottle filling system as shown in the following high-level diagram:

Five evolutionary steps are described: Supervisor Control, Vat Quantity Control, Vat pH Control, Bottle Movement, and Bottle Filling. It is assumed that the Input Control Valve, the Bottle Filling Valve, and the pH Control Valve can each be opened to any partial amount, from flow rates of 1% to 100%, in measurable increments of 1%. A 0% open amount is equivalent to the valve being closed. It is assumed that the Bottle Line Chute can be set to any speed from 1% to 100% of maximum, in measurable increments of 1%. A 0% speed is equivalent to the chute being stopped. It is assumed that the vat can be filled through the Input Control Valve in 16 minutes if the valve is 100% open, and the valve is working properly. It is assumed that the Bottle Filling Valve can operate at only half the flow rate of the Input Control Valve, such that at maximum flow rate it would take 32 minutes for a single Bottle Filling Valve to empty the vat, or 16 minutes for two of them. This means that with 3 or more



Bottle Lines in operation, the Bottle Filling Valve cannot be operated at continuous, maximum flow rate without causing the vat to empty even when being filled at maximum flow rate through the Input Control Valve. It is assumed that the specified calculation time intervals are initially to be set to 16 minutes, 8 minutes, 4 minutes, 2 minutes, 1 minute, 20 seconds, 10 seconds, and 1 second. It is assumed that the Bottle Release Gate can be either opened or closed, with no partial opening or closing. It is assumed that a tolerance level of 5% (measured difference from expected) is acceptable unless specified otherwise. It is assumed that the capabilities of the software developers working on this system are above average. It is assumed that lots of memory will be available for the software to execute in, that the hardware CPU being used is fast and supports lots of memory, and that the CPU is new to the company. It is assumed that modern practices and familiar development tools will be used by the software development team. It is assumed that the C++ programming language used by the software development team is familiar to them. It is assumed that this project is of high complexity overall, given the number of real-time interconnections between hardware and software components. It is assumed that some new technology and third-party software components are being used by the software development team. It is assumed that deadlines and other constraints are not overly demanding. 2. Step Descriptions 2.1 Step 1: Supervisor Control

2.1.1 Rationale

All components in the bottle filling system must communicate with the Supervisor Control system, which takes manual input from the Area Supervisor, sends operational parameter values to each component, sends start-up and shut-down signals to each component, and takes readings from each of the components. It is a pre-requisite for almost all other functionality and is therefore specified as the first step.

2.1.2 Functionality Planned

The Supervisor Control system needs to be able to communicate bi-directionally with each other component in the bottle filling system: the Input Control Valve (“ICV”), Bottle Filling Valve (“BFV”), pH Control Valve (“PCV”), Level Sensor (“LS”), pH Sensor (“PS”), Bottle Filling Scale (“BFS”), Bottle Line Chute (“BLC”), Bottle Release Gate (“BRG”), and Bottle Line Operator Control (“BLOC”).

It needs to be able to send start-up and shut-down signals to each of the other components, either individually or in broadcast mode to all of them at once.

It needs to be able to accept user-entered component-specific operational parameter values, save them in a persistent data store, and send them to each applicable component.

It needs to be able to accept user-entered global operational parameter values, save them in a persistent data store, and send them to each of the components.



It needs to be able to read the operational parameter values assigned to each component, and automatically shut-down a component if any of these parameters do not match their intended values.

It needs to be able to automatically shut-down the entire bottle filling system if it loses communication with any component.

It needs to be able to passively listen for readings sent to it by any of the components, and actively probe for these readings whenever it needs to.

It needs to be able to passively listen for “critical condition” messages from any of the components, and initiate either a selected component shut-down or system-wide shut-down in response.

It needs to be able to store all readings from all components to a persistent data store for historical record keeping purposes.

It needs to require that an operator authenticate to it in some manner before being allowed to use it.

It needs to be able to display to an operator the current status of the bottle filling system, and key historical usage and operational data.

2.1.3 Development and Target Environment

This step will not involve any actual liquids or bottles. Only the bare hardware and software components are included in the development and target environment, as well as the connections between each of them. A single bottle line will be used, to go along with the single vat.

2.1.4 Customer

In place of an actual end-user customer, the hardware engineering and software architecture teams will be considered the customer for this step. The components used in the bottle filling system and the connections between them are being delivered here.

2.1.5 Testing

The use cases to be targeted for testing in this step are as follows: » Accept manual input of ICV, PCV and BFV parameter values » Start-up ICV, PCV and BFV » Send ICV, PCV and BFV parameter values » Read and process ICV, PCV and BFV parameter values » Open ICV, PCV and BFV at 100% flow rate » Close ICV, PCV and BFV » Open ICV, PCV and BFV sequentially for all flow rates from 1% to 100% » Close ICV, PCV and BFV sequentially for all flow rates from 100% to 0% » Open ICV, PCV and BFV randomly for any flow rates from 1% to 100% » Read and process ICV, PCV and BFV settings passively » Read and process ICV, PCV and BFV settings proactively » Read and process ICV, PCV and BFV “critical condition” messages » Shut-down ICV, PCV and BFV



» Accept manual input of LS and PS parameter values » Start-up LS and PS » Send LS and PS parameter values » Read and process LS and PS parameter values » Read and process LS and PS settings passively » Read and process LS and PS settings proactively » Read and process LS and PS “critical condition” messages » Shut-down LS and PS » Accept manual input of BRG, BLC, BFS and BLOC parameter values » Start-up BRG, BLC, BFS and BLOC » Send BRG, BLC, BFS and BLOC parameter values » Read and process BRG, BLC, BFS and BLOC parameter values » Open BRG » Close BRG » Set BLC speed at 100% maximum rate » Set BLC sequentially for all speeds from 1% to 100% » Set BLC sequentially for all speeds from 100% to 0% » Set BLC randomly for any speeds from 1% to 100% » Read and process BRG, BLC, BFS and BLOC settings passively » Read and process BRG, BLC, BFS and BLOC settings proactively » Read and process BRG, BLC, BFS and BLOC “critical condition” messages » Shut-down BRG, BLC, BFS and BLOC » Start-up all components together » Shut-down all components at once » Authenticate area supervisor user » Log out user » Display current status of the bottle filling system to user » Display key historical usage and operational data to user » Allow user to initiate shut-down and start-up of any component

2.2 Step 2: Vat Quantity Control

2.2.1 Rationale

Controlling the quantity of liquid in the vat is of significant importance to the entire bottle filling system, and a pre-requisite for all functionality outside of Supervisor Control. It is therefore specified as the second step.


In general, the vat needs to be filled to a certain level and then kept above a certain minimum level as liquid is drained from the vat to service the bottle lines.

The Input Control Valve (“ICV”) needs to be opened to allow liquid into the vat, and closed to stop liquid from coming into the vat.



The Bottle Filling Valve (“BFV”) needs to be opened to allow liquid to flow out of the vat, and closed to stop liquid from flowing out of the vat.

The Level Sensor (“LS”) inside the vat needs to be reading the level of liquid in the vat at a frequency specified by the Supervisor Control system.

Readings from the LS that are below the maximum level parameter value and above the minimum level parameter value will trigger “open” signals to be sent to the ICV so that additional quantities of liquid are allowed to flow into the vat.

The Supervisor Control system needs to be tracking the rate at which the level of liquid is changing over the time intervals specified.

How much the ICV should be opened (the rate of flow) is dependent on calculations done on level changes over the various time intervals being tracked. This rate of flow needs to be sent to the ICV by the Supervisor Control system.

The ICV, BFV and LS need to read their operational parameter values sent to them by the Supervisor Control system, and to send these same parameter values back to the Supervisor Control system. The ICV and BFV parameters will specify the frequency of readings and the tolerance level. The LS parameters will specify the minimum liquid level, maximum liquid level, critical liquid levels, calculation time intervals, frequency of readings, and tolerance level.

The ICV needs to be listening for signals from the Level Sensor and the Supervisor Control system indicating how much it should be open (its flow rate).

The BFV needs to be listening for signals from the Bottle Lines and the Supervisor Control system indicating how much it should be open (its flow rate), but the bottle lines are not yet implemented so their signals must be manually sent at this point.

The ICV, BFV and LS need to be listening for signals from the Supervisor Control system to start-up or shut-down.

The ICV, BFV and LS need to send “critical condition” messages to the Supervisor Control system in case of any detected malfunction or condition outside of standard tolerance levels.

The LS needs to send a “critical condition” message to the Supervisor Control system if the liquid level exceeds the critical maximum or minimum level parameter values.

The ICV and BFV need to shut themselves down if either is not able to communicate with the Supervisor Control system.


The actual vat hardware and software components will be part of the development and target environment in this step. This step will not include any hardware or software connections from the bottle lines. It will also not include any of the pH control components of the vat. Liquid coming into the Input Control Valve will be coming from a manually operated “stub” source, and liquid going out of the Bottle Filling Valve will exit into a manually operated “stub” destination.



2.2.4 Customer

This step will be developed for use by the area supervisor, the person responsible for this part of the bottle filling system. In place of a actual end-user customer, the QA team will be considered the customer for this step.

2.2.5 Testing

The use cases to be targeted for testing in this step are as follows: » Repeat of relevant use cases listed in Step 1 (with actual liquid rather than simulation) » Initial filling of vat with liquid through ICV at 100% flow rate » Automatic stop filling of vat when Level Sensor indicates maximum level » Draining of vat through BFV at 100% flow rate » Automatic re-filling of vat as level decreases below LS maximum » Draining of vat through BFV at various flow rates from 100% down to 1% » Automatic refilling of vat through ICV at various flow rates from 1% up to 100% » Automatic closing of BFV when liquid level falls below LS minimum » Automatic re-opening of BFV when liquid level rises above LS minimum » Automatic self-shut-down of ICV and BFV if either cannot communicate with Supervisor Control » LS sends “critical condition” message to Supervisor Control when liquid level is above critical maximum or below critical minimum » ICV and BFV send “critical condition” messages to Supervisor Control

2.3 Step 3: Vat pH Control

2.3.1 Rationale

Controlling the pH of the liquid in the vat is of significant importance to completing the basic vat control system, and therefore specified as the third step. This will then allow development of the bottle line functionality in the next step(s).


In general, the pH of the liquid in the vat needs to be maintained at a constant value.

The pH Control Valve (“PCV”) needs to be opened to allow a chemical additive liquid into the vat, and closed to stop this additive from coming into the vat.

The pH Sensor (“PS”) inside the vat needs to be reading the pH value of the liquid in the vat at a frequency specified by the Supervisor Control system.

Readings from the PS that are below the maximum level parameter value and above the minimum level parameter value will trigger “open” signals to be sent to the PCV so that additional quantities of liquid are allowed to flow into the vat.

The Supervisor Control system needs to be tracking the rate at which the pH of the liquid in the vat is changing over the time intervals specified.



How much the PCV should be opened (the rate of flow) is dependent on calculations done on pH changes over the various time intervals being tracked. This rate of flow needs to be sent to the PCV by the Supervisor Control system.

The PCV and PS need to read their operational parameter values sent to them by the Supervisor Control system, and to send these same parameter values back to the Supervisor Control system. The PCV parameters will specify the frequency of readings and the tolerance level. The PS parameters will specify the minimum pH level, maximum pH level, critical pH levels, calculation time intervals, frequency of readings, and tolerance level.

The PCV needs to be listening for signals from the PS and the Supervisor Control system indicating how much it should be open (its flow rate).

The PCV and PS need to be listening for signals from the Supervisor Control system to start-up or shut-down.

The PCV and PS need to send “critical condition” messages to the Supervisor Control system in case of any detected malfunction or condition outside of standard tolerance levels.

The PS needs to send a “critical condition” message to the Supervisor Control system if the pH level exceeds the critical maximum level parameter value.

The PCV needs to shut itself down if it is not able to communicate with the Supervisor Control system.


As for Step 2, this step will not include any hardware or software connections from the bottle lines. The actual vat hardware and software components will be part of the development and target environment. Liquid coming into the pH Control Valve will be the actual chemical additive used to adjust pH levels.

2.3.4 Customer

As for Step 2, this step will be developed for use by the area supervisor, the person responsible for this part of the bottle filling system. In place of a actual end-user customer, the QA team will be considered the customer for this step.

2.3.5 Testing

The use cases to be targeted for testing in this step are as follows: » Repeat of relevant use cases listed in Steps 1 and 2 (with actual liquid and pH additive chemical rather than simulations) » Automatic closing of PCV when pH level is within allowed range » Automatic re-opening of PCV as pH level approaches bounds of allowed range » Automatic self-shut-down of PCV if it cannot communicate with Supervisor Control » PS sends “critical condition” message to Supervisor Control when pH level is below critical minimum or above critical maximum » PCV sends “critical condition” message to Supervisor Control



2.4 Step 4: Bottle Movement

2.4.1 Rationale

After the basic vat control system is complete, the bottle line functionality can be developed. Bottles must be reliably and predictably transported to the Bottle Filling Scale before they can be filled. Bottle movement is therefore specified as the fourth step.


In general, bottles needs to be lined up behind the Bottle Release Gate so that they can be released down a chute to the Bottle Filling Scale.

The Bottle Release Gate (“BRG”) needs to be opened to allow a single bottle onto the chute, and closed to stop bottles from moving onto the chute.

The Bottle Line Chute (“BLC”) needs to be reading the speed at which bottles are moving from the BRG to the Bottle Filling Scale (“BFS”) at a frequency specified by the Bottle Line Operator Control (“BLOC”) system.

The BLOC system needs to be created to provide local, independent control of the Bottle Line components, in the manner (conceptually) of a separate thread of the Supervisor Control system, but also under control of the Supervisor Control system.

The BLOC system needs to re-transmit all information it receives from the Bottle Line components to the Supervisor Control system, in order for the Supervisor Control system to be able to co-ordinate all Bottle Lines in operation.

The BLOC system needs to be tracking the rate at which the BLC speed is changing over the time intervals specified.

How quickly the BLC should be running (chute speed) is dependent on calculations done on speed changes over the various time intervals being tracked. This chute speed needs to be sent to the BLC by the BLOC system.

The BLOC system needs to accept manual input from the Bottle Line operator to start-up or shut-down the Bottle Line, to select different bottle sizes, and to manually override any automatic calculations of chute speed and bottle filling speed.

The BLOC system needs to listen for information from the Supervisor Control system about vat liquid types, start-up of the Bottle Line, shut-down of the Bottle Line, and operating parameter values to be used by each of the Bottle Line components.

The BRG and BLC need to read their operational parameter values sent to them by the BLOC system, and to send these same parameter values back to the BLOC system. The BLC parameters will specify the frequency of readings, tolerance level, minimum chute speed, maximum chute speed, critical chute speeds, and calculation time intervals.

The BRG and BLC need to be listening for signals from the BLOC system to start-up or shut-down.



The BRG and BLC need to send “critical condition” messages to the BLOC system in case of any detected malfunction or condition outside of standard tolerance levels.

The BLC needs to shut itself down if it is not able to communicate with the BLOC system.


This step includes the hardware and software bottle line components up to but not including the Bottle Line Scale. It will not include any hardware or software connections from the vat. Bottles will be coming through the Bottle Release Gate and down the Bottle Line Chute in this step.

2.4.4 Customer

This step will be developed for use by the bottle line operator, the person responsible for this part of the bottle filling system. In place of a actual end-user customer, the QA team will be considered the customer for this step.

2.4.5 Testing

The use cases to be targeted for testing in this step are as follows: » Repeat of relevant use cases listed in Step 1 (with actual bottles rather than simulation) » Transport of bottles through BRG to chute » Transport of bottle along BLC to BLS at 100% speed » Transport of bottle along BLC at various speeds from 100% down to 1% » Transport of different size bottles along chute » Automatic stopping of BLC when speed rises above maximum speed » Automatic self-shut-down of BLC if cannot communicate with BLOC » BRG and BLC send “critical condition” messages to BLOC

2.5 Step 5: Bottle Filling

2.5.1 Rationale

After the bottles are moved to the Bottle Filling Scale they must be filled with liquid to complete the integration of vat and bottle lines. Bottle filling is therefore specified as the fifth step.


In general, bottles needs to be filled with liquid after they arrive from the Bottle Line Chute (“BLC”) onto the Bottle Filling Scale (“BFS”).

The BFS needs to read when an empty bottle from the BLC arrives, read the weight of an empty bottle, and read the weight of the bottle as it is being filled with liquid.

The BFS needs to send an “open” trigger to the Bottle Filling Valve (“BFV”) when an empty bottle arrives, and a “close” trigger to the BFV when the bottle weight indicates the bottle is nearly full.



The BLOC system needs to be tracking the rate at which the BFS bottle weight is changing over the time intervals specified.

How quickly the BLC should be running (chute speed) is also dependent on calculations done on bottle filling speed changes and bottle weight changes over the various time intervals being tracked. This chute speed needs to be sent to the BLC by the BLOC system.

How much the BFV should be opened (the rate of flow) is dependent on calculations done on bottle filling speed changes and bottle weight changes over the various time intervals being tracked. This rate of flow needs to be sent to the BFV by the BLOC system.

The BFS needs to read its operational parameter values sent to it by the BLOC system, and to send these same parameter values back to the BLOC system. The BFS parameters will specify the frequency of readings, tolerance level, minimum bottle weights, maximum bottle weights, critical bottle weights, and calculation time intervals.

The BFV needs to be listening for signals from the Level Sensor (in the vat) and the Supervisor Control system indicating how much it should be open (its flow rate).

The BFS needs to be listening for signals from the BLOC system to start-up or shut-down.

The BFS needs to send “critical condition” messages to the BLOC system in case of any detected malfunction or condition outside of standard tolerance levels.

The BFS needs to shut itself down if it is not able to communicate with the BLOC system.


The Bottle Filling Scale components will form the development and target environment for this step. Hardware and software connections to the vat and to the rest of the bottle line will also be included. Liquid coming through the Bottle Filling Valve will be coming from the vat, bottles will be coming down the Bottle Line Chute, and bottles will be filled at the Bottle Filling Scale with appropriate liquid in this step.

2.5.4 Customer

This step will be developed for use by the area supervisor, the person responsible for this part of the bottle filling system. In place of a actual end-user customer, the QA team will be considered the customer for this step.

2.5.5 Testing

The use cases to be targeted for testing in this step are as follows: » Repeat of relevant use cases listed in Step 1 (with actual liquid rather than simulation) » Filling of bottle with liquid through BFV at 100% flow rate » Filling of different size bottles » Use of different liquids coming from vat



» Automatic closing of BFV when BFS indicates bottle is full » Filling of bottle through BFV at various flow rates from 100% down to 1% » Automatic self-shut-down of BFS if it cannot communicate with BLOC » BFS sends “critical condition” message to BLOC when bottle weight is above critical maximum or below critical minimum

3. Schedule and Labour Estimate Based on the Intermediate COCOMO 81 Model[3], the total project size in Function Points (“FP”) and KLOC (thousand lines of code) is estimated as follows: Modules Size (in FP) Supervisor Control (inputs) 200 Bottle Line Operator Control (inputs) 80 Vat level control (inputs) 20 Vat pH control (inputs) 20 Bottle Line movement (inputs) 20 Bottle Line filling (inputs) 20 Supervisor Control (outputs) 500 Bottle Line Operator Control (outputs) 250 Vat level control (outputs) 50 Vat pH control (outputs) 50 Bottle Line movement (outputs) 50 Bottle Line filling (outputs) 50 Supervisor Control (inquiries) 300 Bottle Line Operator Control (inquiries) 160 Vat level control (inquiries) 32 Vat pH control (inquiries) 32 Bottle Line movement (inquiries) 32 Bottle Line filling (inquiries) 32 Supervisor Control (master files) 250 Bottle Line Operator Control (master files) 180 Vat level control (master files) 100 Vat pH control (master files) 100 Bottle Line movement (master files) 100 Bottle Line filling (master files) 100



Supervisor Control (interfaces) 700 Bottle Line Operator Control (interfaces) 350 Vat level control (interfaces) 210 Vat pH control (interfaces) 210 Bottle Line movement (interfaces) 210 Bottle Line filling (interfaces) 210

Total FP's 4618 C++ LOC per FP[2] 50 Size (in KLOC) 230.9

FP per input 4 FP per output 5 FP per inquiry 4 FP per master file 10 FP per interface 7

230.9 KLOC is considered a Large Project Size[3]. The development mode is considered to be “embedded”[3], since the project must operate within a real-time system, with a strongly coupled mix of hardware, software and user-operators. Nominal Effort = 2.8 * ( KLOC 1.2 ) = about 1920 person-months Cost Drivers Rating Overall Product Attributes RELY H - high 1.15 Required Reliability

CPLX VH - very

high 1.3 Complexity

DATA NOM -

nominal 1 Relative Database Size

Computer Attributes

TIME NOM -

nominal 1 Required % CPU Usage

STOR NOM -

nominal 1 Required % Memory Usage

VIRT L - low 0.87 Virtual Environment Volatility



TURN L - low 0.87

Turn Around Time of Development Environment

Personnel Attributes ACAP H - high 0.86 Analyst Capability

AEXP NOM -

nominal 1 Applications Experience PCAP H - high 0.86 Programmer Capability

VEXP H - high 0.9 Experience with Virtual Environment

LEXP H - high 0.95 Experience with Language

Project Attributes

MODP H - high 0.91 Use of Modern Software Practices

TOOL VH - very

high 0.83 Use of Tools

SCED NOM -

nominal 1 Schedule Product of all Cost Drivers = 0.5405 Adjusted Effort = Nominal Effort * Product of all Cost Drivers = about 1038 person-months. Duration = 2.5 * ( Adjusted Effort 0.32 ) = about 23 months duration to complete the entire project. Development team size should be 1038/23 = about 45 persons.



On a per Step basis, these estimates are as follows: Modules (per Step) Size (in FP) Supervisor Control (inputs) 200 Supervisor Control (outputs) 500 Supervisor Control (inquiries) 300 Supervisor Control (master files) 250 Supervisor Control (interfaces) 700 Total FP's 1950 C++ LOC per FP 50 Size (in KLOC) 97.5 Percent of Total KLOC Size 42.2% Duration (months) 9.7 Duration (weeks) 42.2

Vat level control (inputs) 20 Vat level control (outputs) 50 Vat level control (inquiries) 32 Vat level control (master files) 100 Vat level control (interfaces) 210 Total FP's 412 C++ LOC per FP 50 Size (in KLOC) 20.6 Percent of Total KLOC Size 8.9% Duration (months) 2.1 Duration (weeks) 8.9

Vat pH control (inputs) 20 Vat pH control (outputs) 50 Vat pH control (inquiries) 32 Vat pH control (master files) 100 Vat pH control (interfaces) 210 Total FP's 412 C++ LOC per FP 50 Size (in KLOC) 20.6 Percent of Total KLOC Size 8.9% Duration (months) 2.1 Duration (weeks) 8.9

Bottle Line movement (inputs) 20 Bottle Line Operator Control (inputs) 80



Bottle Line movement (outputs) 50 Bottle Line Operator Control (outputs) 250 Bottle Line movement (inquiries) 32 Bottle Line Operator Control (inquiries) 160 Bottle Line movement (master files) 100 Bottle Line Operator Control (master files) 180 Bottle Line movement (interfaces) 210 Bottle Line Operator Control (interfaces) 350 Total FP's 1432 C++ LOC per FP 50 Size (in KLOC) 71.6 Percent of Total KLOC Size 31.0% Duration (months) 7.2 Duration (weeks) 31.0

Bottle Line filling (inputs) 20 Bottle Line filling (outputs) 50 Bottle Line filling (inquiries) 32 Bottle Line filling (master files) 100 Bottle Line filling (interfaces) 210 Total FP's 412 C++ LOC per FP 50 Size (in KLOC) 20.6 Percent of Total KLOC Size 8.9% Duration (months) 2.1 Duration (weeks) 8.9

Total FP's 4618 Total Size (in KLOC) 230.9 Total Percents 100.0% Total Duration Months 23.1 Total Duration Weeks 100.0



A Gantt Chart for the above looks like the following, including 4-week durations between each Step for processing feedback from the previous Step into the subsequent Step:



4. Bibliography [1] Link, Bruce. BCIT COMP 8081 Management Issues in Software Engineering course notes and slides. 2010. [2] McConnell, Steve. Rapid Development. Redmond, WA, USA. Microsoft Press. 1996. [3] Boehm, Barry. Software Engineering Economics. Englewood Cliffs, NJ, USA. Prentice-Hall. 1981.

bcit comp 8081 evolutionary delivery planning assignment by wesley kenzie, november 2010

Documents