A scooping Example
The Communication with the customer leads to a definition of the functions, data, and behavior which must be implemented, the performance and constraints which bound the related information and system. For example, consider software which must be established to drive a conveyor line sorting system. The statement of scope for the CLSS follows.
The conveyor line sorting system (CLSS) sorts boxes moving along a conveyor line. Each box is known through a bar code which contains a part number and is sorted into one of six bins at the end of the line. The boxes pass through a sorting station which contains a PC and bar code reader. The sorting station PC is connected to a shunting mechanism which sorts the boxes in the bins. Boxes pass in random order and are evenly spaced. The line is moving at 5 feet per minute. A CLSS is depicted schematically show in the Figure.
CLSS software receives input information to a bar code reader at time intervals which conform to the conveyor line speed. The Bar code data will be decoded into box identification format. The proper bin location is passed to a sorting shunt which will position boxes in the appropriate bin. The software will do a look-up into category number data base containing a maximum of 1000 entries to determine proper bin location for the box currently at the reader sorting station. A record of the bin destination for each box will be maintained for reporting and later recovery. CLSS software will also receive input from a pulse tachometer which will be used to synchronize the control signal to the shunting mechanism. Based on the number of pulses which will be generated among the sorting station and the shunt the software will produce a control signal to the shunt to properly position the box.
Figure - A Conveyer Line Sorting System
The project planner will examine the statement of scope and the extracts to all important software functions. This process is called decomposition which is was discussed in the past lecture and results in the following functions.
- Determine bin location
- Produce control signal for shunt
- Maintain record of box destinations'
- Read bar code input
- Read pulse tachometer
- Decode part code data
- Do database look-up
With this case performance is dictated through conveyor line speed. The Processing for each box must be completed at the bar code reader before the next box arrives. The CLSS software is constrained by the hardware it must access the bar code reader, the shunt, the PC that available memory and the overall conveyor line configuration evenly spaced boxes.
The Function performance and constraints must be evaluated together. The similar function can precipitate and order of magnitude various in development effort when considered in the context of various performance bounds. The effort and cost needed to develop CLSS software would be dramatically it function remains the similar but performance varies. For instance if conveyor line average speed rise through a factor of 10 performance and boxes are no longer spaced evenly a constraint software would become considerably more complex and by need more effort. Function performance, and constraint are intimately connected.
The Software will interact with other elements of a computer based system. The planner considers through the nature and complexity of each interface to determine any affect on development cost, respires, and schedule. The concept of an interface is interpreted to mean (1) hardware machines, displays which are indirectly controlled through the software (2) software which already exists database access routines, reusable software components, operating system and must be linked to the new software (3) people who use the software via keyboard or other I/O devices and (4) the procedures which precede or succeed the software as a sequential series of operations. With the each case the information transfer across the interface must be clearly understood.
The Software reliability measures do exist but they are rarely used at this stage of a project. The least precise aspect of software scope is a discussion of reliability. Classic hardware reliability characteristics like meantime-between failures MTBF can be hard to translate to the software domain. Moreover, the general nature of the software may dictate special considerations to ensure reliability. For example software for area traffic controls system or the Space Shuttle both human-rated systems must not fail or human life may be lost. With an inventory control system or word-processing software should not fail but the impact of failure is considerably less dramatic. However it may not be possible to quantify software reliability as precisely as we would like in the statement of scope we can use the nature of the project to cost to assure reliability and aid in formulating estimates of effort.
A system specification has been commonly established nearly all information needed for a description of software scope is available and documented in previously software project planning starts. In the other cases where a specification has not been developed the planner must take on the role of system analyst to determine attributes and bounds which will influence estimation tasks.