Category Archives: prep

Prep: SDLC

SDLC is the process of understanding how an information system (IS) can support business needs, designing the system, building it and delivering it to users.

The SDLC has four fundamental phases: Planning, Analysis, Design and Implementation.

The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it.

The first step is called project initiation during which the system’s business value to the organization is identified.
Ideas for a new system come in the form of a system request. the IS department works together with the person/department that presented the system request to conduct a feasibility analysis.

Feasibility Analysis

  • Technical feasibility (can we build it?)
  • Economic feasibility (will it provide business value?)
  • Organizational feasibility (if we build it, will it be used?)

System request and feasibility analysis are presented to an information systems approval committee (steering committee), which decides whether the project should be undertaken. If they approve the second step of project initiation occurs-project management. During project management project manager creates a work plan, staff the project and puts the techniques in place to help him control and direct the project through the entire SDLC. The deliverable for project management is project plan that describes how the project team will go about developing the system.

In the phase the project team investigates any current system(s), identifies improvement opportunities, and develops a concept for the new system.

Analysis begins with the development of an analysis strategy that guides the project teams efforts. Such a strategy usually includes an analysis of the current system (as-is system) and it’s problems ans then an analysis of ways to design a new system (to-be system). The next step is information gathering (through interviews and questionnaires). The analysis of this information and input from project sponsors leads to development of a new system. The system concept is then used as a basis to develop a business process model that describes how the business will operate if the new system was developed. Finally, a data model is developed to describe the information that is needed to support the process.

The analysis, system concept, process model, and data model are combined in a document called the system proposal (SRS?), which is presented to the project sponsor and key members (members of the approval committee), they will decide whether the project should continue to move forward. System proposal is the initial deliverable that describes what the new system should look like.

Te design phase describes how the system will operate in terms of the hardware, software and network infrastructure. The steps in the design phase determine exactly how the system will operate.

The first step in the design strategy, whether the system will be developed by the company’s own programmers, whther it will be outsourced to another firm or whether the company wil buy an existing software package. This leads to the development of the basic infrastructure design for the system that describes the hardware, software and network infrastructure that will be used.

During this phase the system is actually built (or purchased). For most systems this is the longest and most expensive single part of the development process.

The first step in implementation is system construction, during which the system is built and tested to ensure it performs as designed. After that, Installation is the process by which the old system is turned off and the new one turned on. Installation approaches:

  • Direct cut-over approach (new system immediately replaces the old system)
  • Parallel conversion approach (both new and old systems are operated for a month or two untill it is clear that there are no bugs in the new system)
  • Phased conversion strategy (new system is installed in one part of the organization as an initial trial and then gradually installed in others)
  • One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system.

    Once the system has been installed, the analyst team establish a support plan for the system. This plan usually includes a formal or informal post implementation reviews as well as a systematic way for identifying major and minor changes needed for the system.

Prep : Functional and Non-Functional requirements

Functional and Non-Functional Requirements

Functional Requirements.
Functional requirement specifies what the system should do
Functional requirements specify specific behavior or functions, for example:
“Display the heart rate, blood pressure and temperature of a patient connected to the patient monitor.”

  • Administrative functions
  • Authentication
  • Audit Tracking
  • External Interfaces
  • Reporting Requirements

Non-Functional Requirements
Non-functional requirement specifies how the system should behave
Non-functional requirements specify all the remaining requirements not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors, for example: “Display of the patient’s vital signs must respond to a change in the patient’s status within 2 seconds.”

  • Performance – Response Time, Throughput, Utilization, Static Volumetric
  • Availability
  • Recoverability
  • Maintainability
  • Security
  • Data Integrity
  • Usability

Original Source