Systems Development Life Cycle

Lancez-Vous. C'est gratuit
ou s'inscrire avec votre adresse e-mail
Systems Development Life Cycle par Mind Map: Systems Development Life Cycle

1. 4). Development

1.1. A process of turning the design specifications into a real working system.Development includes a complex mix of scheduling, purchasing, installation, documentation, and programming.

1.2. For big projects it involves a team of programmers, technical writers, and clerical people under the supervision of a systems analyst.

1.3. A large part of the development section is devoted to testing.

1.3.1. beta testing: testing of the almost-finished software for any bugs.

1.3.2. alpha testing- early-testing of the software to locate and eliminated any bugs before modifications are made to the system.

2. 5). Implementation

2.1. Commercial software packages: this phase involves extensive training and technical support to supplement sales and marketing efforts.

2.2. Large custom systems: this phase includes end-use education and training, equipment replacement, file conversion, and monitoring of the new system for problems.

2.3. To convert to the new system the analyst can do one of four things:

2.3.1. 1). The direct cutover approach simply replaces the old system with the new system.

2.3.2. 2). The parallel system approach operates the old system along with the new system for a period of time. The old system is gradually phased out.

2.3.3. 3). The phase-in approach implements subsystems if the new system gradually over a period of time or, alternatively, the system is implemented in only a few departments, branch offices, or plant locations at a time.

2.3.4. The pilot approach implements the new system in one department or work site. The new system is used and modified at this test site until the systems analyst believes the system can be successfully implemented throughout the organization.

2.4. End-user training is critical to implementing an information system successfully. During training, clerical and managerial end users learn how to use the new system effectively and how to handle problems when they arise. Training is often handled by the end-user representatives from the project team rather than by technicians.

3. 6). Maintenance

3.1. This phase involved monitoring, evaluating, repairing, and enhancing the system throughout the lifetime of the system.

3.2. Some software problems don't surface until the system had been operational for a while or the organization's needs change. Systems often need to be adjusted to keep up to date with the new products, services, customers, industry standards, and government regulations.

3.3. Ongoing maintenance enables organizations to deal with those problems and take advantage of opportunities for improvements when they arise.

4. 7). Retirement

4.1. At some point, ongoing maintenance is no longer enough to keep the system going. Because of changes in organizational needs, user expectations, technological changes, increasing maintenance costs, and other factors, the system may no longer meet the needs of the organization.

4.1.1. It is ready for retirement.

5. 1). Investigation

5.1. Purpose is to study the existing business problem or opportunity and determine whether it is feasible to develop a new system or redesign the existing system.

5.1.1. Technical feasibility: Can the required hardware and software be purchased or developed?

5.1.2. Economic feasibility: Will the costs of developing and operating the proposed system be offset by the benefits of using the system?

5.1.3. Operational feasibility: Does the proposed system meet the need go the organization?

5.1.4. Organizational feasibility: Does the proposed system support the goals and strategy of the organization?

5.2. Based on its investigation, the project team makes one of three recommendations: leave the current system as is, improve or enhance the current system, or create a new system.

6. 2). Analysis

6.1. The systems analyst gathers documents, interviews users of the current system, observes the system in action, and gathers and analyzes data to understand the current system and identify new requirements.

6.1.1. Input/output requirements: The characteristics of the user interface, including the content, format, an timing requirements for data-entry screens and managerial reports.

6.1.2. Processing requirements: The calculations, decision rules, data processing capacity, and response time needed.

6.1.3. Storage requirements: The con ten of records and databases and the procedures for data retrieval.

6.1.4. Control requirements: The desired accuracy, validity, and security of the system; for example, to prevent data-entry errors and guarantee an easy-to-use, user-friendly system.

6.2. The report describes the current business procedures and the current system, identifies the problems wit the current procedures and system, and describes the requirements for the new or modified system.

7. 3). Design

7.1. The system analyst develops the specifications that ascribe how the system requirements, identified in the analysis phase, will be met.

7.1.1. User interface design: How will the output of the system be designed?

7.1.2. Database design: How will the data elements and structure of the files that compose the database be designed?

7.1.3. Process design: how will the programs and the procedures be designed?

7.2. The analyst answers those questions, sometimes proposing alternative solutions through a design approach called prototyping- prototype: a limited working system that gives users and management an idea of how the completed system will work.