|
The logical design produced during the analysis is turned into a physical design - a detailed description of what is needed to solve the problem.
How detailed should it be? Try assuming that after your design is finished, you are fatally injured by a falling elephant. Could your design be used by someone to successfully implement the solution? If not, it is not detailed enough. Also consider that you, as a solution designer, may not even be involved in the implementation! You may be hired solely to design the solution and another team will be responsible for implementing it. Your design must be self-explanatory and complete.
The finished design of a solution should contain:
- alternative solutions to the problem - in what different ways could the problem be solved?
- data structure (e.g. field names, data types and lengths, filenaming, folder structure schemes, colour coding, style guide requirements).
- how the data is to be acquired (what procedures and equipment will be needed?)
- data input procedures and equipment (e.g. keyboard? barcode reader? OCR?)
- interfaces (e.g. what will a data entry screen look like? Will people need to leave the main screen to access functions? How will menus be organised into commands and submenus? What shortcut keys will be used? Will you use a text box, listbox, combo box, tickbox for a particular item of data entry? What colour scheme will be used? What navigation scheme will be used? What icons represent what meaning? Will the layout of the data entry form help users enter data in the required order and the required format?
- control procedures - What validation rules will be used on what fields to check for data reasonableness, existence or format?) What will different error messages say? How can output be checked for accuracy (e.g. an average can be compared with the data items from which it was calculated). How can procedural errors or problems be detected? (e.g. an order may be cross-checked against the stock database to ensure the ordered item is in stock, or whether it needs to be backordered and the potential customer notified of the delay)
- Equipment sources - will equipment be tailor-made or 'off the shelf'? In either case, hardware and software specifications must be given. It should consider:
- What features are required
- What hardware requirements the software has (e.g. memory, peripheral devices, storage volumes)
- What software requirements the hardware has (e.g. operating system)
- The cost
- How long the equipment will take to develop
- What training and documentation will be required
- Whether the equipment can be adapted to cater for future needs
- Whether the system can be maintained or repaired
- What warranties apply
- Whether spare parts or consumables will be available in the future
- How reliable the components will be
- Who the supplier will be
- For more on this, see Choosing Hardware and Software
- what workloads and capacities the system must be capable of - e.g. storage capacities, number of transactions per hour, disaster-recovery abilities
- documentation and training requirements for different types of users
- validation and storage methods to be used
- how to produce the output (i.e. processing actions)
- procedures to be followed to use the solution
- backup requirements and procedures - what needs to be backed up, how often, how backups are stored, what backup scheme will be used?
- how the solution is to be tested to ensure it works properly - what needs to be tested? Functionality, presentation, usability, accessibility, communication of message. How will you test?
- staffing requirements to use the solution (e.g. new experts or operators, moving workers to new areas)
- changeover - how will the solution be brought online to replace the existing system (implementation strategy)
- evaluation - how is the finished solution going to be evaluated to see if it meets expectations
- how the problem solving project is to be managed (this is a chapter in itself!)
The physical design should finish with a documented system specification.
Some useful tools for designing solutions are:
- flow charts- to describe sequencing of processes
- N-S (Nassi-Schneiderman) charts - as above, but more concise
- organisational charts - describing the structure of an organisation's employees' roles
- structure charts - a top-down description of a process and its sub-processes
- data structure diagrams - describes (for example) a database's fields, types, lengths, validation rules, formulae
Project management tools include (but you don't need to use them for VCE IT)
- PERT charts - "Program Evaluation Review Technique" graphically shows a project as nodes connected by lines. Similar in use to a GANTT chart but shows task dependencies a little more clearly. Can be hard to interpret with complex projects.
- Gantt charts - a detailed timeline of events in a project laid out so concurrent events and dependent events are clearly seen.
Complete design tool reference is here. |
Note: Note: system flow charts are referred to in the 2007-2010 study design. They are not the same as [program] flow charts... This description comes from tiscali.reference ...
A system flow chart, or data flow chart, is used to describe the flow of data through a complete data-processing system. Different graphic symbols represent the clerical operations involved and the different input, storage, and output equipment required. Although the flow chart may indicate the specific programs used, no details are given of how the programs process the data. In other words, it's like a DFD.
A program flow chart is used to describe the flow of data through a particular computer program, showing the exact sequence of operations performed by that program in order to process the data. Different graphic symbols are used to represent data input and output, decisions, branches, and subroutines. |
