Systems Development and Documentation: SDLC, Testing and User Documentation
Systems development and documentation covers how software gets built and handed over: the stages of the development life cycle, how testing proves a system works, how an organisation moves from the old system to the new one, and the two kinds of documentation produced.
The life cycle
Typical stages: problem definition and feasibility study (is the system technically, economically and legally worth building?), requirements analysis (interviews, observation, questionnaires), design (inputs, outputs, files, validation, hardware), implementation, testing, conversion and maintenance (corrective, adaptive, perfective). The waterfall model moves through the stages in order with documentation at each stage; it suits stable requirements but is inflexible and shows no working software until late. Iterative and agile approaches build in repeated cycles with user feedback, adapting better to changing requirements, but demand more user involvement and can drift without documentation.
Testing
Unit testing checks one module, integration testing checks modules together, system testing checks the whole system against requirements, and acceptance testing asks users to confirm it does the job. Black-box testing uses inputs and expected outputs without seeing the code; white-box testing follows paths inside the code. Alpha testing happens at the developer's site; beta testing releases the software to real users to find remaining faults. Test data should include normal, boundary and erroneous data. Debugging fixes faults that testing reveals - the two are not the same.
Conversion and documentation
Direct changeover is fast and cheap but risky; parallel running keeps both systems live until confidence is gained, at double cost; phased conversion replaces one part at a time; pilot conversion runs the new system in one branch or site first. User documentation teaches end users: getting started, screens, tasks, error messages and troubleshooting. Technical documentation serves programmers and maintainers: system specification, data dictionary, flowcharts and pseudocode, file layouts, test plans and installation instructions.
Worked example
A hospital is replacing its patient records system. Parallel running is recommended for the first month: both systems hold records, so if the new one loses data the old one still supports patient care, and totals can be compared to verify accuracy. The cost of duplicated work is outweighed by patient safety; once outputs match consistently, switch over and archive the old system.
Traps
Reversing user documentation and technical documentation; calling beta testing a kind of unit testing; forgetting the maintenance phase; and confusing testing (finding faults) with debugging (correcting them).