BCIT COMP 8081 Attribute Definition Assignment by Wesley Kenzie, November 2010

BCIT Computing and Information Technology COMP 8081 Management Issues in Software Engineering Due Date: November 24, 2010 Author: Arthur (Wesley) Kenzie A00242330 Assignment 3: Attribute Definition (Final Version) ______________________________________________________________________________

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

This assignment is intended to demonstrate an understanding of Attribute Specification, which is applied to the same microprocessor-based bottle filling system functionally defined in the previous Assignment 2. Each of the ten high-level quality requirements listed below are given a minimum of three realistic attributes, with defined properties of scale, test, worst case, best case and planned. 1. Usability ....................................................................................... page 2 2. Portability ....................................................................................... page 3 3. Reliability ....................................................................................... page 3 4. Maintainability ............................................................................. page 4 5. Availability ....................................................................................... page 5 6. Cost ................................................................................................ page 6 7. Schedule ....................................................................................... page 6 8. Accuracy ....................................................................................... page 7 9. Security ....................................................................................... page 8 10. Error Handling ............................................................................. page 9 Bibliography ....................................................................................... page 9



1. Usability Operational training time required for Line Operator » scale: number of days » test: after completion of training, quiz is given to confirm learning outcomes » worst case: score of 80% on quiz after 2 days of training » best case: score of 100% on quiz after 2 days of training » planned: Line Operator scores 90% on quiz after 2 days of training Preventive Maintenance training time required for Line Operator » scale: number of days » test: after completion of training, quiz is given to confirm learning outcomes » worst case: score of 80% on quiz after 2 days of training » best case: score of 100% on quiz after 2 days of training » planned: Line Operator scores 90% on quiz after 2 days of training Training time required for Supervisor » scale: number of days » test: after completion of training, quiz is given to confirm learning outcomes » worst case: score of 80% on quiz after 7 days of training » best case: score of 100% on quiz after 7 days of training » planned: Supervisor scores 90% on quiz after 7 days of training Customization time to support new bottle sizes » scale: number of hours » test: after customization of software, try new bottle size in all areas of system and compare measurements to expected operational standards, and if not within tolerance, then continue with additional customization and repeat » worst case: 5 hours of software customization to get operational variances within 5% tolerance levels » best case: all operational variances within 5% tolerance levels after less than 2 hours of software customization » planned: after 2 hours of software customization, new bottle size can go through Bottle Release Gate, go down Bottle Line Chute, sit on Bottle Line Scale, and be filled through Bottle Filling Valve all within operational standards Customization time to support any liquid having viscosity level below 0.8 Pa.s at 15˚C » scale: number of hours » test: after customization of software, try new liquid in all areas of system and compare measurements to expected operational standards » worst case: any excessive operational variances encountered in any component after 2 hours of software customization » best case: all operational variances within tolerance levels after less than 2 hours of software customization



» planned: after 2 hours of software customization, new liquid can fill vat through Input Control Valve, exit from vat through Bottle Filling Valve, fill bottles on Bottle Line Scale, and be read by both pH Sensor and Level Sensor in the vat all within operational standards 2. Portability Software porting time to run on new microprocessor CPU hardware » scale: number of days » test: compile and run software on new hardware, plus run all unit tests successfully » worst case: 120 days of porting effort are required to get software to compile and run on new hardware » best case: all software modules compile, run and pass unit tests on new microprocessor CPU hardware in less than 90 days » planned: all software modules compile, run and pass unit tests on new microprocessor CPU hardware in 90 days Software porting time to run on new Linux-based operating system (“OS”) » scale: number of days » test: compile and run software on new OS, plus run all unit tests » worst case: 120 days of porting effort are required to get software to compile and run on new OS » best case: all software modules compile, run and pass unit tests on new OS in less than 90 days » planned: all software modules compile, run and pass unit tests on new OS in 90 days Operation in temperate climate without requiring additional HVAC infrastructure » scale: amount of HVAC infrastructure required » test: measure quantity and/or cost of additional HVAC infrastructure that must be installed in the plant/warehouse in order to operate filling system within spec » worst case: minimal (10% of total system cost) HVAC infrastructure required to operate within spec when outside temperature is between 5˚C and 25˚C » best case: same as planned » planned: no HVAC infrastructure required to operate within spec when outside temperature range is between 5˚C and 25˚C 3. Reliability Unexpected shut-downs from malfunction, assuming that preventive maintenance schedule is followed » scale: number of unexpected shut-downs from malfunction » test: count number of unexpected shut-downs from malfunction » worst case: 2 unexpected shut-down from malfunction per bottle line per month » best case: no unexpected shut-downs from malfunction » planned: 1 unexpected shut-down from malfunction per bottle line per month



Valve operation, assuming that preventive maintenance schedule is followed » scale: number of valve openings and closings that are not to specification » test: count number of valve openings and closings that are not within standard operational variances » worst case: 0.25% of automatic opening and closing of valves outside of standard operational variances » best case: all automatic opening and closing of valves is within standard operational variances » planned: automatic opening and closing of valves 99.9% of the time within standard operational variances Bottle movement along Chute, assuming that preventive maintenance schedule is followed » scale: number of bottles moved that are not to specification » test: count number of bottles moved from Release Gate along Chute to Scale that are not within standard operational variances » worst case: 2% of automatic movement of bottles outside of standard operational variances » best case: all automatic movement of bottles is within standard operational variances » planned: automatic movement of bottles 99% of the time within standard operational variances Bottle filling, assuming that preventive maintenance schedule is followed » scale: number of bottles filled with liquid that are not to specification » test: count number of bottles filled that are not within standard operational variances » worst case: 2% of automatic filling of bottles outside of standard operational variances » best case: all automatic filling of bottles is within standard operational variances » planned: automatic filling of bottles 99% of the time within standard operational variances 4. Maintainability Bottle line hardware component repair » scale: mean time to repair (“MTTR”) hours » test: count number of hours to repair bottle line hardware components, and update MTTR for each repair » worst case: MTTR of 2 hours » best case: MTTR of less than 1 hour » planned: MTTR of 1 hour Vat hardware component repair » scale: mean time to repair (“MTTR”) hours » test: count number of hours to repair vat hardware components, and update MTTR for each repair » worst case: MTTR of 6 hours » best case: MTTR of less than 4 hours » planned: MTTR of 4 hours



Software component repair » scale: mean time to repair (“MTTR”) hours » test: count number of hours to repair software components, and update MTTR for each repair » worst case: MTTR of 12 hours » best case: MTTR of less than 8 hours » planned: MTTR of 8 hours 5. Availability Vat filling start-up time » scale: number of minutes until vat begins filling after system start-up » test: count number of minutes from system start-up until vat starts to fill with liquid » worst case: 6.5 minutes from system start-up » best case: less than 5 minutes from system start-up » planned: 5 minutes from system start-up Vat filling elapsed time » scale: number of minutes to finish filling vat after filling starts » test: count number of elapsed minutes from start of liquid entering vat until vat is full » worst case: 18 elapsed minutes » best case: less than 16 elapsed minutes » planned: 16 elapsed minutes Vat preventive maintenance time » scale: number of hours to complete preventive maintenance of vat » test: count number of hours to do preventive maintenance of vat » worst case: 5 hours » best case: less than 4 hours » planned: 4 hours Bottle Line preventive maintenance time » scale: number of hours to complete preventive maintenance of bottle line » test: count number of hours to do preventive maintenance of bottle line » worst case: 4 hours » best case: less than 3 hours » planned: 3 hours



6. Cost Customer Return on Investment (“ROI”) compared to manual system » scale: percentage of cost saving dollars per year » test: calculate total purchase and implementation cost of (investment in) bottle filling system, calculate total costs to operate manual bottle filling system, and calculate ROI as manual system costs divided by investment » worst case: 25% » best case: more than 50% » planned: 50% Operational unit cost per bottle, assuming that preventive maintenance schedule is followed » scale: dollars per bottle filled » test: when filling at least 15,000 bottles per month, calculate total cost of operating entire system in terms of labour, energy, financing, etc. (but exclusive of raw material and fixed asset costs) and divide this cost by the number of bottles filled » worst case: $0.09 per bottle » best case: less than $0.05 per bottle » planned: $0.05 US per bottle Annual software maintenance cost » scale: percentage of annual maintenance cost compared to purchase price of system » test: calculate cost of annual software maintenance as percentage of purchase price of system » worst case: 25% » best case: less than 20% » planned: 20% 7. Schedule Customer setup and implementation time » scale: number of days » test: count number of days after complete system delivery to a prepared warehouse/factory site location until entire system is ready for use by customer » worst case: 150 days » best case: less than 120 days » planned: 120 days Step 1 delivery time » scale: number of months » test: count number of months after development work has begun on Step 1 until it is delivered » worst case: 12 months » best case: less than 10 months » planned: 10 months



Integrity checks of hardware component readings by Supervisor Control module » scale: interval hours between integrity checks » test: calculate number of hours between recorded integrity check results in system log » worst case: within 10% of 8 hour interval » best case: 8 hour interval » planned: within 2.5% of 8 hour interval 8. Accuracy Measurement of vat pH level » scale: percentage difference between pH sensor readings » test: use two additional, standardized pH sensors to compare their pH readings with the pH sensor in the vat, and assume that each of them is correct » worst case: 90% accuracy » best case: more than 95% accuracy » planned: 95% accuracy Measurement of vat quantity level » scale: percentage difference between level sensor readings » test: use two additional, standardized level sensors to compare their readings with the level sensor in the vat, and assume that each of them is correct » worst case: 95% accuracy » best case: more than 98% accuracy » planned: 98% accuracy Measurement of bottle filling » scale: percentage difference between sample fill measurements, over time » test: take random samples of filled bottles and measure their “fill” level; accumulate history of sample fill measurements to determine accuracy rate over time » worst case: 90% accuracy 98% of the time » best case: more than 95% accuracy 99% of the time » planned: 95% accuracy 99% of the time



9. Security Automatic validation and authentication of software » scale: percentage of software files validated and authenticated each week » test: automatic, intermittent, secure connection established to remote server controlled by, and authenticated to, the software developers/owners to initiate comparison of portion of software file versions and authentication signatures on local system owned by customer against standard versions and signatures on remote server, with results recorded in system log, and with the complete set of software files validated and authenticated each week » worst case: 50% of software files validated and authenticated successfully each week » best case: more than 95% of software files validated and authenticated successfully each week » planned: 95% of software files validated and authenticated successfully each week Automatic software updates » scale: number of software update checks and required updates completed successfully each week » test: automatic, daily secure connection established to remote server controlled by, and authenticated to, the software developers/owners to initiate comparison of current software version on local system owned by customer against latest available version on remote server, and to initiate update of local system files to latest available version if required, with results recorded in system log » worst case: 2 update checks, and all required updates completed each week » best case: 7 update checks and all required updates completed each week » planned: successful update checks once per day, and successful updates when required Blocked access from removable media » scale: number of accesses allowed from removable media » test: record start of all file, socket and device access in system log and count them » worst case: 2 file, socket or device accesses allowed per day from removable USB or optical drive media » best case: no file, socket or device access allowed to come from any removable USB or optical drive media » planned: 1 file, socket or device access allowed per day from removable USB or optical drive media



10. Error Handling Remote logging of error event messages » scale: percentage of local error log entries recorded on remote server » test: automatic remote logging of all Supervisor Control software module error event messages over secure connection to remote server controlled by, and authenticated to, the software developers/owners » worst case: 95% of all Supervisor Control module error event messages transmitted to remote logging server » best case: all Supervisor Control module error event messages transmitted to remote logging server » planned: 99% of all Supervisor Control module error event messages transmitted to remote logging server Automatic shut-down of bottle line » scale: elapsed seconds for bottle line shut-down » test: each real-time reading from bottle line sent to Supervisor Control module is verified, and if verification is unsuccessful, or differs from initial reading, then bottle line is automatically shut-down within a few measured seconds » worst case: bottle line is not shut-down within 15 seconds » best case: shut-down of bottle line within 5 seconds » planned: shut-down of bottle line in 10 seconds Automatic component self-shut-down » scale: elapsed seconds for component to shut-down itself » test: every component performs a shut-down of itself within a few measured seconds if it is unable to communicate with the Supervisor Control module » worst case: component does not shut-down itself within 15 seconds » best case: shut-down of component within 5 seconds » planned: component shut-down of itself in 10 seconds 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.

BCIT COMP 8081 Attribute Definition Assignment by Wesley Kenzie, November 2010

Documents

Transcript of BCIT COMP 8081 Attribute Definition Assignment by Wesley Kenzie, November 2010