Professional Documents
Culture Documents
______________________________________________________________________________
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)
______________________________________________________________________________
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
______________________________________________________________________________
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
______________________________________________________________________________
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
______________________________________________________________________________
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)
______________________________________________________________________________
______________________________________________________________________________
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
______________________________________________________________________________
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
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:
______________________________________________________________________________
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
FP per input 4
FP per output 5
FP per inquiry 4
FP per master file 10
FP per interface 7
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
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
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.
______________________________________________________________________________
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)
______________________________________________________________________________
______________________________________________________________________________
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
______________________________________________________________________________
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