Information System Development Methodologies

IS-Design Notes @ 2008 1

INFORMATION SYSTEM DEVELOPMENT

Learning objectives:1) Define system development life cycles and methodologies2) Understand 8 principles of systems development3) Describe FAST- A System development methodology.4) Understand and identify cross life cycle activities5) Describe CASE

Introduction:

This chapter introduces a system development life cycle-based methodology as the process used to developinformation systems.

1. System development life cycles and Methodologies

System development life cycle (SDLC): also called application development life cycle. SDLC is a logicalprocess by which systems analysts, software engineers, programmers, and end-users build informationsystems and computer applications to solve business problems and needs. It defines the phases and tasksthat 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. Itis physical implementation of the logical life cycle of system development. Methodology ensures that aconsistent, reproducible approach is applied to all projects. Therefore reducing the risk associated withshortcuts and mistakes. It also produces consistent documentation from one project to the next. Modernmethodologies, such as FAST, incorporate the use of several development tools and techniques.

2. Principles of systems development

a. Owners and Users InvolvementWithout users/owner involvement, it is possible that the technological solutions don’t address the realorganization problems. Therefore owner and user involvement is necessary to minimize organization ortechnical problems. For successful systems development, system development should go along with userand owner’s participation.

b. Problem-Solving ApproachProblem in system development includes real problems, opportunities for improvement, and directivesfrom management.

Using some sort of problem-solving approach to all projects increases efficiency and productivityin system development.

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

http://www.alientools.com/


The Classical problem solving approach is as follow:

c. Phases and Activities set upThe 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 developmentprogresses, later concerns become more technology-driven. Each phase can also be subdivided into smalleractivities and tasks, which can be more easily managed and accomplished.

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




e. Systems as capital investmentsSystem should be considered as capital investments of the organization. After evaluating possible solutionsfor a given problem, the systems analyst should study each possible solution for feasibility, especially forcost-effectiveness.

Cost-Effectiveness: is the result obtained by striking a balance between the cost of developing andoperation a system, and the benefits derived from that system.

f. Constant project scope revisionMultiple feasibility check-points are built into the system development methodology in creepingcommitment approach. At this point, all cost are considered irrecoverable and the project has to bereevaluated to determine if it is still feasible. Analysts should consider cancellation of the project if it is nolonger feasible, reevaluating of costs and schedule if project scope is to be increased or reduction of scopeif the project budget and schedule are frozen, but not sufficient to cover all project objectives.

g. System to more manageable subsystemsVirtually all systems, which are part of supersystem, contain smaller systems (subsystems). Problem-solving process can be simplified by dividing this larger system into more easily managed pieces.

h. System design for growth and changeSystems that are designed to meet only current requirements are difficult to modify in response to newrequirements. However, it’s very important to build systems that can grow and change as requirementsgrow and change.

Entropy: is the term describing the natural and inevitable decay of all systems. System entropycan be managed.

During the support phase, the analyst encounters the need for change directing the analyst andprogrammer to rework former phases of the life cycle. Eventually, the cost of maintenanceexceeds 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. FAST- A System development methodology

a. Starting FAST projectPlanned, unplanned, the cause for most projects is some combination of problems, opportunities, ordirectives.Some definitions:

Problems: undesirable situations that prevent the organization from fully achieving its purpose, foaland 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 externalinfluence.

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 determinewhich 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 informationstrategy plan or business process redesign.

James Wetherbe has developed a useful framework for classifying problems, opportunities, anddirectives.(PIECE)

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

a. FAST life cycle and Methodology

Two formal project triggers are unplanned system request and planned system initiative. The finaldeliverable 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 theinformation system maintain this database.Program library: where any application software and programs will be stored once they are written.




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




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 areexecutive sponsors, technical sponsor and project managers. They are the only participants in thisphase. System analysts are the facilitators, which help system owners to make decisions. PIECESframework provides an excellent outline for making decision in this phase. If the system is worthlooking at, the project manager should formally plan the project. It is also sometimes calledpreliminary investigation of the problems, opportunities and/or directives that triggered the project, orfeasibility study. Key input of the phase is either the unplanned system request or the planned systeminitiative. System owners don’t spend too much time for survey phase, since this is to decide whetheror not more significant time and resources should be committed to the project. The key deliverable forthe survey phase is a feasibility assessment and project plan. Survey phase could be deferred until thestudy 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. Thisphase provides the project team with a more thorough understanding of the problems, opportunitiesand/or directives that triggered the project. "Are the problems worth solving?" and " Is a new systemworth building?" are the questions that has to me answered in this phase. System users are activelyinvolved 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 thestudy 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 objectivesdefine 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 systemdoes is their main concerns and not how the system functions. The analyst approaches the users to findout what they need or want out of the new system. Essentially, the purpose of requirements analysis isto identify the data, process, interface and geography requirements for users of a new system. Thisphase 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 systemobjectives. Sometimes, business requirements are not discovered fully until some level of design orprototyping activity occurs. The real challenge is to organize and synchronize these requirements in away that permits system users to validate and prioritize the business requirements.

The most popular approach to documenting and validating users’ requirements from business point ofview 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 theusers’ 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 techniquethat divides the set of all business requirements for a system into subsets, each of which will beimplemented as a version of the system. Essentially, the project team has to guarantee the new versionof the system on a regular and timely basis.




4. The Configuration Phase

Identifies and analyzes candidate technical solutions that might solve the problem and fulfill thebusiness requirements.

This phase recommends a system that will be designed and implemented. System users, owners anddesigners are be involved to make decisions. This phase is triggered by complete specification ofbusiness requirement. Technology-oriented system owners review any technology standards but notprecise details of the elements. This phase identifies input, output, databases, key functions orprograms for the project. Some possible solutions are proposed as design ideas and opinions by varioussources. Each candidate is evaluated by technical feasibility, operational feasibility, economicfeasibility and schedule feasibility. The key deliverable of the configuration phase is a formal systemsproposal to system owners. Configuration phase is not always required. But developing applicationarchitecture is encouraged. Application architecture defines an approved set of technologies to beused 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 ofthe target solution. This phase is also called acquisition or purchasing phase. It is only required ifpurchases of new technologies are necessary. The purpose of the procurement phase is to research theinformation technology marketplace, solicit vendor proposals, and recommend the proposal that bestfulfill the business and technology requirements. Analysts, information technology vendors, users andowners get involved. The key inputs are business requirements from the definition phase andtechnology requirements from the configuration phase. This phase considers the perspectives of systemdesigners. Team communicates to vendors as request for proposals. The key deliverable of theprocurement phase is a technology proposal to system owners to acquire specific hardware andsoftware. When a purchased system fully meets requirements, project proceeds immediately to thedelivery 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 andto integrate the new system with the existing system. The purpose of the design phase is to transformthe business requirements from the definition phase into a set of technical design blueprints forconstruction. FAST encourages an iterative design and construct strategy. System analysts, databasespecialists, network specialists, microcomputer specialists are involved in this design phase. Twotriggers are business requirements and design requirements. This views the system from theperspectives of the system designers. These days, the design and construction phases are mergedtogether. The basic idea of RAD is to actively involve system users in the design process, to acceleratethe definition/design/construction process by catching errors and omissions earlier in the process, andto reduce the amount of time that passes before the users begin to see a working system. The finaldeliverable is a technical set of design specifications. These specifications can take several forms, butthe most common approach is modeling. General design models will picture the structure of thedatabase, the structure of the overall application, the overall look and feel of the user interface, thestructure of the computer network and the design structures for any completes software to be written.




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 designrequirements and to implement the interfaces between the new system and existing productionsystems. Design specification is the key input to the construction phase. Important aspect ofapplication programming is testing. Unit tests: ensure that the applications programs work properlywhen tested in isolation from other applications programs. System tests: ensure that applicationsprograms written in isolation work properly when they are integrated into the total system. The finaldeliverable is the functional system.

8. The Delivery Phase

Is to install, distribute and place the new system into operation or production. Every informationworkers 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 isthe 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 programmaintenance and system improvements. These activities include fixing software bugs, recovering thesystem, 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 inconjunction with several phases. Cross life cycle activities include fact-finding, documentation andpresentations, estimation and measurement, feasibility analysis and project and process management.

a. Fact-findingInformation about the systems, requirements, and preferences. The information is collected usingresearch, interviews, meetings, questionnaires, sampling, and other techniques.Important activities performed on survey, study, and definition phases of FAST projects. Project teamlearns about the business’s and system’s vocabulary, problems, opportunities, constraints,requirements, and priorities.

b. Documentation and PresentationsDocumentation 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 byinterested users and managers.

These activities have to be supported by all the phases in FAST.




c. Estimation and measurementAre 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 bothsimplify 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 systemdevelopment life cycle.Feasibility: a measure of how beneficial the development of an information system would be to anorganization.

e. Project and Process ManagementProject management is the ongoing activity, by which an analyst plans, delegates, directs andcontrols 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 ormore phases of a systems development life cycle. This accelerates the process ofdeveloping systems and to improve the quality of the system. CASE is not the methodology but Itis a technology supporting a methodology.

a. A case Tool FrameworkUpper-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. (Powerbuilder)There can be overlap between upper and lower CASE tools.

b. Case Tool ArchitectureCASE tools are built around an automated repository. Around that repository is a collection of tools orfacilities to create documentation or other system components. CASE tools are able to use and updatesome 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, qualitymanagement tools, decision support tools, documentation organization tools, design generation tools,code generator tools, testing tools, data sharing tools, version control tools and housekeeping tools.




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, andsupport a systems development environment for other developers.



Documents

Information System Development Methodologies