Information System Development Methodologies

INFORMATION SYSTEM DEVELOPMENT

Learning objectives: 1) Define system development life cycles and methodologies 2) Understand 8 principles of systems development 3) Describe FAST- A System development methodology. 4) Understand and identify cross life cycle activities 5) Describe CASE Introduction: This chapter introduces a system development life cycle-based methodology as the process used to develop information systems. 1. System development life cycles and Methodologies System development life cycle (SDLC): also called application development life cycle. SDLC is a logical process by which systems analysts, software engineers, programmers, and end-users build information systems and computer applications to solve business problems and needs. It defines the phases and tasks that are essential to systems development and it is used as a project management tool used to plan, execute, and control systems development projects. Methodology: defines step-by step activities for each phase, individual and group roles in each activity, deliverables and quality standards for each activity and tools and techniques to be used for each activity. It is physical implementation of the logical life cycle of system development. Methodology ensures that a consistent, reproducible approach is applied to all projects. Therefore reducing the risk associated with shortcuts and mistakes. It also produces consistent documentation from one project to the next. Modern methodologies, such as FAST, incorporate the use of several development tools and techniques. 2. Principles of systems development a. Owners and Users Involvement Without users/owner involvement, it is possible that the technological solutions don’t address the real organization problems. Therefore owner and user involvement is necessary to minimize organization or technical problems. For successful systems development, system development should go along with user and owner’s participation. b. Problem-Solving Approach Problem in system development includes real problems, opportunities for improvement, and directives from management. Using some sort of problem-solving approach to all projects increases efficiency and productivity in system development.

IS-Design Notes @ 2008

1

Created by PDF Generator (http://www.alientools.com/), to remove this mark, please buy the software.

The Classical problem solving approach is as follow:

c. Phases and Activities set up The classical system life cycle consists of four phases:

• system support (iterate the life cycle) At the beginning of the development, early concerns are with the business and then, as development progresses, later concerns become more technology-driven. Each phase can also be subdivided into smaller activities and tasks, which can be more easily managed and accomplished.

d. Standards for consistent development and documentation Establishing standards promote good communication between users and information systems professionals. Sometimes, users can be changed. With the standards and documentation, the project ensures consistent systems development. These standards describe activities, responsibilities, documentation guidelines or requirements and quality checks. Documentation should be a working by-product of the entire systems development effort. Documentation should go parallel with the project.


2


e. Systems as capital investments System should be considered as capital investments of the organization. After evaluating possible solutions for a given problem, the systems analyst should study each possible solution for feasibility, especially for cost-effectiveness. Cost-Effectiveness: is the result obtained by striking a balance between the cost of developing and operation a system, and the benefits derived from that system. f. Constant project scope revision Multiple feasibility check-points are built into the system development methodology in creeping commitment approach. At this point, all cost are considered irrecoverable and the project has to be reevaluated to determine if it is still feasible. Analysts should consider cancellation of the project if it is no longer feasible, reevaluating of costs and schedule if project scope is to be increased or reduction of scope if the project budget and schedule are frozen, but not sufficient to cover all project objectives. g. System to more manageable subsystems Virtually all systems, which are part of supersystem, contain smaller systems (subsystems). Problemsolving process can be simplified by dividing this larger system into more easily managed pieces. h. System design for growth and change Systems that are designed to meet only current requirements are difficult to modify in response to new requirements. However, it’s very important to build systems that can grow and change as requirements grow and change. Entropy: is the term describing the natural and inevitable decay of all systems. System entropy can be managed. During the support phase, the analyst encounters the need for change directing the analyst and programmer to rework former phases of the life cycle. Eventually, the cost of maintenance exceeds the costs of starting over, the system has become obsolete. Different phases and entropy of system development life cycles are illustrated in Figure3.1.


3


3. FAST- A System development methodology a. Starting FAST project Planned, unplanned, the cause for most projects is some combination of problems, opportunities, or directives. Some definitions: Problems: undesirable situations that prevent the organization from fully achieving its purpose, foal and objectives. Current, suspected, or anticipated. Opportunities: a chance to improve the organization even in the absence of specific problems. Directive: a new requirement that’s imposed by management, government, or some external influence. Unplanned system request: When system owners, users and sy7stem analysts initiate a project. They are frequently screened and prioritized by a steering committee of system owners to determine which requests get approved. Those requests that are not approved are often said to be backlogged. Planned system initiative: opposite of unplanned system request and result of an information strategy plan or business process redesign. James Wetherbe has developed a useful framework for classifying problems, opportunities, and directives.(PIECE)

a.

P

The need to improve performance

I

The need to improve information and data

E

The need to improve economics

C

The need to improve control or security

E

The need to improve efficiency of people and processes

S

The need to improve service to customers, suppliers, partners, employees

FAST life cycle and Methodology Two formal project triggers are unplanned system request and planned system initiative. The final deliverable of the methodology is the production system. Three data stores are used for the projects. These are repository, database and program library. Repository: place where system analysts and other developers store documentation about the system. Database: place where actual business data are stored. The application programs written for the information system maintain this database. Program library: where any application software and programs will be stored once they are written.


4


The FAST methodology consists of eight phases. These phases are not necessarily sequential. Fig 3.2 shows the system development phases of FAST methodology.


5


1. The Survey Phase Establishes the project context, scope, budget, staffing and schedule. This phase describes the system and project from the perspective of system owners. System owners are executive sponsors, technical sponsor and project managers. They are the only participants in this phase. System analysts are the facilitators, which help system owners to make decisions. PIECES framework provides an excellent outline for making decision in this phase. If the system is worth looking at, the project manager should formally plan the project. It is also sometimes called preliminary investigation of the problems, opportunities and/or directives that triggered the project, or feasibility study. Key input of the phase is either the unplanned system request or the planned system initiative. System owners don’t spend too much time for survey phase, since this is to decide whether or not more significant time and resources should be committed to the project. The key deliverable for the survey phase is a feasibility assessment and project plan. Survey phase could be deferred until the study phase for those projects that have already been determined to be worth looking at. 2. The Study Phase Identifies and analyzes both the business and technical problem domain for specific problems. This phase provides the project team with a more thorough understanding of the problems, opportunities and/or directives that triggered the project. "Are the problems worth solving?" and " Is a new system worth building?" are the questions that has to me answered in this phase. System users are actively involved in the study. Key input is the statement of project and system scope from the survey phase. The project team gains a better understanding of the system’s problems and limitations. During the study phase, we need to address the causes and effects of the problems, opportunities and directives. The outputs of this phase are business problem statement and feasibility analysis. System objectives define the business criteria on which any new system will be evaluated. 3. The Definition Phase Identifies and analyzes both the business and technical problem domains for specific problems, causes, and effects. This phase defines and prioritizes the business requirements.(Requirement analysis). What the system does is their main concerns and not how the system functions. The analyst approaches the users to find out what they need or want out of the new system. Essentially, the purpose of requirements analysis is to identify the data, process, interface and geography requirements for users of a new system. This phase specify the requirements without expressing computer alternatives and technology details. Analysis is carried out in the business level. The input of the phase is approved statement of system objectives. Sometimes, business requirements are not discovered fully until some level of design or prototyping activity occurs. The real challenge is to organize and synchronize these requirements in a way that permits system users to validate and prioritize the business requirements. The most popular approach to documenting and validating users’ requirements from business point of view is modeling, which is act of drawing one or more graphical representations of a system. The other way is prototyping: the act of building a small-scale, representative or working model of the users’ requirements to discover or verify those requirements. These who approach to users’ requirements are usually organized into a business requirement statement. Time boxing is a technique that divides the set of all business requirements for a system into subsets, each of which will be implemented as a version of the system. Essentially, the project team has to guarantee the new version of the system on a regular and timely basis.


6


4. The Configuration Phase Identifies and analyzes candidate technical solutions that might solve the problem and fulfill the business requirements. This phase recommends a system that will be designed and implemented. System users, owners and designers are be involved to make decisions. This phase is triggered by complete specification of business requirement. Technology-oriented system owners review any technology standards but not precise details of the elements. This phase identifies input, output, databases, key functions or programs for the project. Some possible solutions are proposed as design ideas and opinions by various sources. Each candidate is evaluated by technical feasibility, operational feasibility, economic feasibility and schedule feasibility. The key deliverable of the configuration phase is a formal systems proposal to system owners. Configuration phase is not always required. But developing application architecture is encouraged. Application architecture defines an approved set of technologies to be used when building any new information system. 5. The Procurement Phase Identifies and analyzed hardware and software and software products that will be purchased as part of the target solution. This phase is also called acquisition or purchasing phase. It is only required if purchases of new technologies are necessary. The purpose of the procurement phase is to research the information technology marketplace, solicit vendor proposals, and recommend the proposal that best fulfill the business and technology requirements. Analysts, information technology vendors, users and owners get involved. The key inputs are business requirements from the definition phase and technology requirements from the configuration phase. This phase considers the perspectives of system designers. Team communicates to vendors as request for proposals. The key deliverable of the procurement phase is a technology proposal to system owners to acquire specific hardware and software. When a purchased system fully meets requirements, project proceeds immediately to the delivery phase or integrates the purchased system into the overall system.

6. The Design Phase Specifies the technical requirements for the target solution. This phase is to design the new system and to integrate the new system with the existing system. The purpose of the design phase is to transform the business requirements from the definition phase into a set of technical design blueprints for construction. FAST encourages an iterative design and construct strategy. System analysts, database specialists, network specialists, microcomputer specialists are involved in this design phase. Two triggers are business requirements and design requirements. This views the system from the perspectives of the system designers. These days, the design and construction phases are merged together. The basic idea of RAD is to actively involve system users in the design process, to accelerate the definition/design/construction process by catching errors and omissions earlier in the process, and to reduce the amount of time that passes before the users begin to see a working system. The final deliverable is a technical set of design specifications. These specifications can take several forms, but the most common approach is modeling. General design models will picture the structure of the database, the structure of the overall application, the overall look and feel of the user interface, the structure of the computer network and the design structures for any completes software to be written.


7


7. The Construction Phase Builds and tests the actual solution or interim prototypes of the solution After several iterations of the design/construction loop that implements rapid application development, functional system is implemented. The purpose of this phase is to build and test a functional system that fulfills business and design requirements and to implement the interfaces between the new system and existing production systems. Design specification is the key input to the construction phase. Important aspect of application programming is testing. Unit tests: ensure that the applications programs work properly when tested in isolation from other applications programs. System tests: ensure that applications programs written in isolation work properly when they are integrated into the total system. The final deliverable is the functional system . 8. The Delivery Phase Is to install, distribute and place the new system into operation or production. Every information workers are active in this phase. Functional key information system is the input to the delivery phase. Tests are conducted to ensure that the new system works properly. The final deliverable of the phase is the production system for the system users. The other outputs are training and supports c. System support. Is ongoing maintenance of a system after it has been placed into operation. This includes program maintenance and system improvements. These activities include fixing software bugs, recovering the system, assisting users and adapting the system to new requirements.

4. Cross life cycle activities Are activities that overlap different phases of the methodology. They are influenced or performed in conjunction with several phases. Cross life cycle activities include fact-finding, documentation and presentations, estimation and measurement, feasibility analysis and project and process management. a. Fact-finding Information about the systems, requirements, and preferences. The information is collected using research, interviews, meetings, questionnaires, sampling, and other techniques. Important activities performed on survey, study, and definition phases of FAST projects. Project team learns about the business’s and system’s vocabulary, problems, opportunities, constraints, requirements, and priorities. b. Documentation and Presentations Documentation and Presentation are common communication skills for successful project completion. Documentation: activity of recording facts and specifications for a system. Presentation: written or verbal. Related activity of formally packaging documentation for review by interested users and managers. These activities have to be supported by all the phases in FAST.


8


c. Estimation and measurement Are commonly performed to address the quality and productivity of systems. Estimation: activity of approximating the time, effort, costs, and benefits of developing systems. Measurement: activity of measuring and analyzing developer productivity and quality. Software and systems metrics: provides an encyclopedia of techniques and tools that can both simplify the estimation process and provide a statistical database of estimates versus performance. d. Feasibility Analysis Feasibility analysis is performed several times in creeping commitment approach in system development life cycle. Feasibility: a measure of how beneficial the development of an information system would be to an organization. e. Project and Process Management Project management is the ongoing activity, by which an analyst plans, delegates, directs and controls progress to develop an acceptable system within the allotted time and budget. Similarly, process management is ongoing activity that establishes standards for activities, methods, tools, and deliverables of the life cycles. 5. Computer-aided systems engineering (CASE)

Is the application of information technology to systems development activities, techniques, and methodologies. CASE tools are software that automate or support one or more phases of a systems development life cycle. This accelerates the process of developing systems and to improve the quality of the system. CASE is not the methodology but It is a technology supporting a methodology. a. A case Tool Framework Upper-CASE: tools support the survey, study, definition, and design phases of the methodology. (System architect) Lower-CASE: tools support the design, construction, and delivery phases of the methodology. (Power builder) There can be overlap between upper and lower CASE tools. b. Case Tool Architecture CASE tools are built around an automated repository. Around that repository is a collection of tools or facilities to create documentation or other system components. CASE tools are able to use and update some other tool’s repository. CASE repository: is a developers’ database. It is a place where the developers can store diagrams, descriptions, specifications, and other by-products of systems development. Facilities and Functions: Representative CASE tools provide some of the following facilities: diagramming tools, description tools, prototyping tools, inquiry and reporting tools, quality management tools, decision support tools, documentation organization tools, design generation tools, code generator tools, testing tools, data sharing tools, version control tools and housekeeping tools.


9


d. The benefits of CASE • Improved productivity • Improved quality • Better documentation • Reduced lifetime maintenance • Methodologies that really work Development center is a central group of information system professionals who plan, implement, and support a systems development environment for other developers.


10


Information System Development Methodologies

Recommend Documents