You are on page 1of 18

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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 1 of 18
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 2 of 18
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)
______________________________________________________________________________
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 3 of 18
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)
______________________________________________________________________________
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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 4 of 18
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)
______________________________________________________________________________
» 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.
2.2.2 Functionality Planned
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 5 of 18
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)
______________________________________________________________________________
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.
2.2.3 Development and Target Environment
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 6 of 18
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)
______________________________________________________________________________
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).
2.3.2 Functionality Planned
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 7 of 18
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)
______________________________________________________________________________
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.
2.3.3 Development and Target Environment
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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 8 of 18
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)
______________________________________________________________________________

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.
2.4.2 Functionality Planned
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 9 of 18
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)
______________________________________________________________________________
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.
2.4.3 Development and Target Environment
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.
2.5.2 Functionality Planned
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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 10 of 18
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)
______________________________________________________________________________
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.
2.5.3 Development and Target Environment
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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 11 of 18
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)
______________________________________________________________________________
» 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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 12 of 18
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)
______________________________________________________________________________
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.
1.2
Nominal Effort = 2.8 * ( KLOC ) = about 1920 person-months

Cost Drivers Rating Overall Product Attributes


RELY H - high 1.15 Required Reliability
VH - very
CPLX high 1.3 Complexity
NOM -
DATA nominal 1 Relative Database Size

Computer Attributes
NOM -
TIME nominal 1 Required % CPU Usage
NOM - Required % Memory
STOR nominal 1 Usage
Virtual Environment
VIRT L - low 0.87 Volatility

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 13 of 18
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)
______________________________________________________________________________
Turn Around Time of
Development
TURN L - low 0.87 Environment

Personnel Attributes
ACAP H - high 0.86 Analyst Capability
NOM -
AEXP nominal 1 Applications Experience
PCAP H - high 0.86 Programmer Capability
Experience with Virtual
VEXP H - high 0.9 Environment
Experience with
LEXP H - high 0.95 Language

Project Attributes
Use of Modern Software
MODP H - high 0.91 Practices
VH - very
TOOL high 0.83 Use of Tools
NOM -
SCED nominal 1 Schedule

Product of all Cost Drivers = 0.5405

Adjusted Effort = Nominal Effort * Product of all Cost Drivers = about 1038 person-months.
0.32
Duration = 2.5 * ( Adjusted Effort ) = about 23 months duration to complete the entire
project.

Development team size should be 1038/23 = about 45 persons.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 14 of 18
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)
______________________________________________________________________________

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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 15 of 18
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)
______________________________________________________________________________
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

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 16 of 18
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)
______________________________________________________________________________

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:

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 17 of 18
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)
______________________________________________________________________________

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.

______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 18 of 18

You might also like