Analysis
Consider existing system:-
- data - origin, uses, volume, characteristics
- procedures - what, when, where, how and how errors are handled
- future - development plans, expected growth rates
- management reports - requirements for new reports (content and frequency)
- problems with existing system
Fact finding:-
- observation
- reading documentation
- questionnaires
- interview
Data dictionary
- file that stores definitions of data elements and data characteristics such as usage, physical representation, ownership, authorisation and security
- shows which programs and reports in the database system use the data
Volumetrics
- the volume of data to be processed and the characteristics of the users
- consider the number of input documents or online requests to the system each day
- consider the number of users and whether online or batch processing is required
Design
Considerations:-
- output (content, format, sequence, frequency, medium)
- input (volume, frequency, documents used, input methods)
- user interface
- type of system (e.g. batch, online, real-time)
- files (contents, record layout, organisation, access methods)
- processing (programs and procedures needed and their detailed design)
- security
- testing strategies
- hardware
Prototyping
- building a working model of a system in order to evaluate it, test it or have it approved before building the final product
- user can experience 'look and feel' of the input process and suggest alterations
- spiral model - life cycle model which spirals towards a final solution
Throwaway prototyping - prototype is discarded before the real system is started
Evolutionary prototyping - prototype developed into a working system
Systems flowchart - diagram showing an overview of a complete system (pictorial representation of how the system will work)
- tasks to be carried out in the new system
- devices (disk drives, tape drives, terminals) to be used in the system
- media used for input, storage and output
- files used by system
User interface:-
- consider who will use it, what tasks, the environment, what is technically feasible
- screen display should have title, not too cluttered, indicate size and format of data to be entered, logical sequence, default values where possible, facility to go back and correct previous entries, full exit and help facilities
Development - coding and testing of the programs which make up the system and the testing of the system as a whole
Testing strategies:-
- Bottom-up testing
- each individual module is tested as soon as it is written using pre-prepared data
- each complete program is tested (data chosen to ensure every route is tested, every statement is executed at least once and to verify the accuracy of the processing and that it meets the original specifications)
- Top-down testing - skeleton of complete system is tested with individual modules being replaced by stubs which display a message to say a certain procedure has been executed
- Unit testing - testing each part of the system (as individual modules are completed)
- Black box (functional) testing - carried out independently of the code but considered all inputs and outputs
- White box (structural) testing - program code is studied and each possible path is tested at least once (will not detect missing functions)
- Integration testing - when all modules have been individually tested, they are tested to ensure they work together correctly
Implementation
Methods of conversion:-
- direct changeover - user stops using the old system one day and starts using the new one the next
- fast and efficient
- minimum duplication of work involved
- normal operation could be seriously disrupted if the new system had errors or does not work as expected
- parallel conversion - old system continues alongside the new system for a few weeks or months
- results from new system can be checked against known results
- operations can continue on old system while errors on new system are corrected
- more effort required to keep both systems running
- phased conversion - with larger systems, different modules can be implemented separately at different times
- also when a few customers are processed under the new system while the rest remain under the old system for a time
- pilot conversion - new system will be used for a time by only a portion of the organisation e.g. one branch
Software testing:-
- unit testing - each individual component of the new system is tested
- module testing - each module (collection of dependent components) is tested
- subsystem testing - collections of modules which have been integrated into subsystems are tested
- system testing - subsystems are integrated to make up the entire system and are tested to reveal errors from the interaction of different subsystems (also to ensure the system meets all the requirements of the original specification)
- acceptance testing - before the system is accepted for operational use it is tested with test data provided by the purchaser to confirm the system meets the original specification, to find out whether any major changes in operating procedures will be needed and to test the system in the environment in which it will run with realistic volumes of data
Alpha (acceptance) testing - testing continues until an agreement is reached between the developer and the system purchaser that the system works correctly and fulfils all the system requirements
Beta testing - involves giving the package to a number of potential users who agree to use the system and report any problems to the developers -> detects errors that may not have been anticipated by the developers
Post implementation review
- critical examination of the system three to six months after it has been put into operation
- comparison of system's actual performance with anticipated performance objectives
- assessment of each aspect of the system against pre-set criteria
- analyse errors made during system development
- consider unexpected benefits and problems
Software maintenance:-
- perfective maintenance - making the system better without changing its functionality e.g. made to run faster
- adaptive maintenance - due to changing needs in the company e.g. adapting a single-user system to multi-user or due to changes in hardware
- corrective maintenance - correction of previously undetected errors
Laws of software maintenance:-
- A program used in the real-world environment must change or become less useful over time
- As programs evolve, the structure becomes more complex. Extra resources should be devoted to simplifying the structure
- Program evolution is a self-regulating process. The number of changes which may be implemented at any one time is limited.
- Rate of program development is approximately constant for the life of a program (and is independent of the resources devoted to system development)
- The incremental change in each release of a system is approximately constant
Factors affecting maintainability:
- good program design
- well-structured, modular programs, well commented, meaningful variable names
- use of appropriate high level language
- good system and program documentation
- record of all maintenance work carried out, when, why and by whom
Installation manual:-
- hardware requirements
- OS requirements
- details of how to install
- how to customise system
- special instructions for multi-user or networked versions
- how to set up new data files or set parameters for first time
- software registration instructions
- upgrade instructions if upgrading from previous versions
Operations manual - used by anyone concerned with the day-to-day operation of the computer system
- details of how to start program
- details of disks or tapes required
- special stationary to be used
- number of copies of each report and who is to receive them
- backup procedures
- recovery procedures (in event of hardware failure)
User manual - aimed at various levels of end-user (senior managers, middle managers, clerical workers) who will be using the system
- menu structure
- how to navigate around package
- how to enter data
- format or reports and how to print them
- how to undo actions when an error has been made
- how to get on-line help
- user support telephone number
Training
- users at different levels of the company may require different levels of training
e.g. clerical worker may need to know how to enter daily or weekly sales figures; sales staff may need to know how to enter customer details and put through a sale; managers need to be able to extract information for decision-making
Methods of training:-
- training manual
- on-line tutorial
- video training course
- formal, instructor-led training course