The Development Life Cycle of an Information System

The Development Life Cycle of an Information System

📘 Overview An information system does not appear all at once. It passes through a life cycle of stages, from the first idea to years of use. The development life cycle describes these stages at a high level, whether an organization builds a system itself, configures a packaged product or has a vendor supply it. Development approaches arrange the stages differently, and people from across the organization take part.

🧠 Key Idea The life cycle is a way to organize the work of creating and keeping an information system so that it meets the organization's needs. Most approaches share the same stages, but whether they are organized as planned stages or repeated in shorter cycles depends on the approach, and users and managers take part throughout, not only technical staff.

⚔️ Core Details: - Life-cycle models differ in how many stages they name. One common version has seven: planning, analysis, design, construction or acquisition, testing, implementation, and operation and maintenance. The stages themselves are widely shared. - Planning decides what problem or opportunity the system should address and whether to go ahead. Analysis studies the current work and states what the system must do. Design describes how the system will do it, including screens, data and procedures. - The system is made or obtained at the construction or acquisition stage: staff may build it, configure a packaged product or have a vendor supply it. The organization may evaluate build, buy or vendor options during planning and analysis, then carry out the selected approach during construction or acquisition. - Testing checks that the system works as designed and meets the stated needs. Implementation puts it into use by training users, moving existing records into the system and switching from the old way of working. Operation and maintenance keep it running, correct problems and update it as needs change. - Consider a fictional community water cooperative replacing paper meter readings with a billing system. Planning decides that paper records cause delays. Analysis lists what billing staff and members need, and the cooperative decides to use a packaged billing product instead of building one. Design sketches the screens and billing rules, and acquisition configures the chosen product. Staff test it with sample accounts, implementation trains staff and moves member records, and operation and maintenance later add a new rate schedule. - Development approaches arrange the stages differently. A plan-driven approach emphasizes upfront planning, documented requirements and organized stages, although teams may revisit earlier work when necessary. An iterative approach repeats shorter cycles of design, building and testing and delivers the system in parts, adjusting as users respond. Agile methods are a widely used example of iterative approaches, and prototyping, building an early model for users to try, can be used with either approach. - Neither approach is better in every situation. Plan-driven approaches suit needs that are clear and stable, while iterative approaches suit needs that are expected to change or are not yet fully understood. - People from across the organization take part at particular stages. Managers approve the plan and decide when to go live, users describe the current work in analysis and try the system in testing, and technical staff design, build and support it. In an iterative approach, users take part repeatedly as each part is delivered.