A Review of Information System Process

7/31/2019 A Review of Information System Process

1/20

LITERATURE REVIEW

2.0 INTRODUCTION

The literature review covers a review and survey on different areas of the research

study. These areas are very important as they will in one way or the other be

employed in the research development. Areas covered include system design

technology and methodologies, system development life cycle, system development

process activities and models. These areas also elaborate on system analysis methods

and processes in details so as to enable reliable and accuracy in data gathering and

analysis processes of the research. Also covered is the system implementation

activities which includes system deployment, installation, testing and maintenance

activities and models. Several models, techniques, approaches, strategies and

methodologies were reviewed and compared in relation to the research area. A review

of an already developed system that is closely related to the project was carried out

also.

First to be reviewed is the review of a related exiting Sales/Food service management

Information system.

2.1 A REVIEW OF FOOD SERVICE MANAGEMENT INFORRMATION

SYSTEM V(FMIS V)

The Foodservice Management Information System (FMIS V) sold by Genesistems,

Inc. since 1980 on mini and super mini computers is now available on low cost

personal computers and popular networks under FMIS V. According to Genesistems'

President Eric Muench, new programming languages have provided a method of

allowing Genesistems' proven FMIS system to operate with the same speed and

flexibility on the new popular personal computers that was formerly available only on

larger computers. This brings the cost of an automated solution for the foodservice

operator down to a price that is affordable.

"The manager must be able to determine prices and schedules, make forecasts,

perform an ongoing audit of inventory and other company assets, and monitor

performance. More and more managers are turning to the computer to provide this

information on a timely basis," he said.


2/20

"Traditionally, foodservice institutions have had weak in-house accounting systems

based on tedious manual procedures," Muench continued. "The result has been poor

cost control. Food cost information is generally outdated before manual computations

can even be completed. FMIS V solves these and other problems at a reasonable

cost."

FMIS V consists of the following modules: general ledger, accounts payable, payroll,

bank reconciliation, inventory control, recipe control, sales analysis, and management

report writing. Telecommunications input is available for certain cash registers. All

modules are integrated and provide full accounting information automatically to the

general ledger for up-to-date financial statements.

General Ledger

The General Ledger module is the center of the accounting system. It is a powerful

yet easy to use module that can accommodate a single unit restaurant as well as a

large multiple unit operation. The General Ledger is automatically updated from all

other modules being operated. Both 12 and 13 period accounting are supported. The

Trial Balance Report and General Ledger Report provide the necessary documentation

and audit trails required of a professional accounting system. Financial Statements can

be designed to your specifications by you within the General Ledger module. The

optional Management Report Writer gives you the added ability to print complex

financial statements that consolidate or compare multiple time periods and units if

necessary. Account budgets may be set up and used in forecasting and comparisons to

actual activity.

Accounts Payable

The Accounts Payable module is designed to allow you to better manage your vendor

invoices and payments. Inventory purchases that are entered will be automatically

updated to the Inventory, Recipe, and Sales Analysis modules without any additional

work. Invoices may be entered in summary, detail, or a combination of the two. By

entering invoices, you are creating the capability of accumulating unpaid invoices

easily at any time. A purchase history by vendor is also maintained, and check

payment can be accomplished easily in a method that is convenient for your

operation. This module lets you stay on top of your outstanding invoices so that

invoices are never paid for twice.


3/20

Payroll

The Payroll module is designed for time entry, printing payroll checks, general ledger

distribution and year-end W-2 forms. It can operate on a daily, weekly, bi-weekly,

semi-monthly, or monthly basis with all input verified, copied, and employee records

updated during the End-Pay-Period procedure. Other useful options are included such

as payroll history inquiry, earnings summary report, employee payroll history, tip

allocation, tip reporting and is integrated to the optional Federal Magnetic Media

Reporting module.

The module is easy to use due to its one-step nature. After set-up with a General

Ledger file and initial data entry, payroll tracking becomes relatively easy. Time is

entered, then the register is printed. If corrections are necessary, they can be made to

the appropriate entries and the register re-printed. After everything balances, checks

and reports are printed and then the pay period can be closed.

This module is designed to operate in conjunction with other modules that may be

installed. Programs are explained as if the General Ledger module were included.

Information is transferred to all integrated modules as a function of the End-Pay-

Period procedure or is transferred each month through the End-of-Month posting

procedure.

Bank Reconciliation

The Bank Reconciliation module is used to manage your bank accounts. It is

automatically updated as checks are written and deposits are entered. A simple

method of canceling checks allows you to reconcile the account to the bank statement

in very little time. Multiple bank accounts can be maintained simply and easily. Ahistorical check register is maintained for up to five years for your review.

Other features includes Accurate, "on demand" financial statements tighten

management control and eliminate monthly accounting fees, True, double entry

accounting with forced balancing of entries eliminates costly posting errors,

Comparisons of business units permit management to make intelligent analysis and

take effective action, Reporting accommodates easy consolidation of multiple units or

companies for corporate requirements, Simple invoice entry organizes and validates

invoices for accuracy and automatically updates the Inventory module if necessary,


4/20

Accounts Payable Cash Requirements Report provides immediate access to a list of

currently due invoices and the total cash required, Controlled payment of Accounts

Payable invoices eliminates duplicate payments, conserves cash, and accrues interest,

Selection and printing of Accounts Payable computer checks saves time and

eliminates errors, Bank Reconciliation provides an easy way to control and reconcile

any bank accounts.

Inventory Control

The Inventory Control module is designed to allow you a fast and easy way to keep

track of your inventory. You are able to track what you have purchased and what

prices you are paying from various suppliers for any length of time. In-house batch

production items can be processed along with multiple location transfers. Inventory is

first categorized into major classifications that you choose such as meat, dairy and

produce. Inventory can be kept on a perpetual basis by entering your purchases for

those items and taking a physical count monthly or as frequently as desired to get your

actual usage on each item. Inventory may also be kept on a periodic basis which does

not require entering all your purchases. The periodic method allows for entry of a

physical count and last cost at any point in time and will automatically extend the

inventory for you. Both methods provide inventory count sheets by specific storage

location and fast inventory count entry methods. The two methods can also be

combined to allow detailed control of high cost items and less detailed control of less

significant items.

Recipe Control

The Recipe Control module works hand in hand with the Inventory Control module. It

provides you with an organized method of entering your recipes. You can take

advantage of the ability to monitor your costs at all times before cost increases erode

your profit margins. Unlimited levels of sub-recipes can be maintained very easily.

Recipes can include a plate cost for items that you may not want to set up. Recipes

can be costed in seconds at Last Cost or Average Cost and can be printed or displayed

on the screen. Each recipe can also have detailed preparation instructions set up for

use as a training manual. Other features include Quick, accurate food and beverage

cost percentages can spot increasing costs before it is too late, "What If" capability for

quick, profitable decisions on effect of price and cost changes to a menu or individual

item, Easy, timely, accurate trend information on profit margins and popularity of


5/20

menu items, Regular variance reporting on Actual versus Potential Inventory Usage

flags items to watch for excessive use, Prompt, accurate comparisons of multi-unit

sales for better management analysis and decisions, Server analysis tells you who is

and who isn't selling items such as specials and desserts, Usage, waste and pilferage

information is available at any time for management corrective action to maximize

profits, Inventory Use and Purchase History allows more accurate inventory planning,

Provides a clear, precise way of standardizing recipes for easier employee use,

Inventory transfers between multiple units are tracked for proper allocation of charges

and better management relations, Inventory Production allows the tracking of in-

house prep items to show actual inventory usage and real costs, Friendly, flexible set

up allows you to track only information you need and not data that you don't care

about.

Sales Analysis

The Sales Analysis module completes the operations triangle. Both Inventory and

Recipe Control are related heavily to Sales Analysis. Menu items are set up and

defined at this point. A menu item can refer to a recipe or directly to an inventory

item. Daily sales can be entered manually or transferred from a point of sale device if

one is available. Sales history is maintained on a daily basis for any number of years.

Entering your sales will generate your potential or optimal use of each inventory item

and will give you an actual versus potential usage variance. Sales trends can be

tracked in a wide variety of methods using the Management Report Writer. Sales

Analysis gives you the capability to stay on top of your margins and control them

before they can hurt you.

Management Report Writing

The Report Writer module allows the creation of custom reports wanted by individual

companies. The flexibility and adaptability of this module allows for seemingly

unlimited variations of report types. This module is limited only by your imagination.

Thirty-six columns are available for mathematical and statistical computations (only

limited by your printer's capability). Data to be printed on these reports can be drawn

from a variety of sources. The most common source is General Ledger and the Report

Writer is particularly suited to producing complex financial statements. Reports can

also be produced based on data from Sales Analysis or from the Statistics section of

the Management Report Writer.


6/20

2.2 SYSTEMS DESIGN

Systems design is the process of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. One could see it as

the application ofsystems theory to product development. There is some overlap with

the disciplines ofsystems analysis, systems architecture and systems engineering. If

the broader topic ofproduct development "blends the perspective of marketing,

design, and manufacturing into a single approach to product development," then

design is the act of taking the marketing information and creating the design of the

product to be manufactured. Systems design is therefore the process of defining and

developing systems to satisfy specified requirements of the user. Until the 1990s

systems design had a crucial and respected role in the data processing industry. In the

1990s standardization of hardware and software resulted in the ability to build

modular systems. The increasing importance of software running on generic platforms

has enhanced the discipline ofsoftware engineering. System design comprises of

several activities, phases and sections. These sections has several outputs and

deliverables. All the results of the system design phases is to ensure an effective

breakdown and decomposition of the system to be developed. First of the phases is

the logical design

2.2.1 Logical design

The logical design of a system pertains to an abstract representation of the data flows,

inputs and outputs of the system. This is often conducted via modelling, using an

over-abstract (and sometimes graphical) model of the actual system. In the context of

systems design are included. This is aimed at complete definition of the processes

activities of the system so as to ensure a proper definition of the logic of the system.

2.2.2 Physical design

The physical design relates to the actual input and output processes of the system.

This is laid down in terms of how data is input into a system, how it is

verified/authenticated, how it is processed, and how it is displayed as output.

Physical design, in this context, does not refer to the tangible physical design of an

information system. To use an analogy, a personal computer's physical design

involves input via a keyboard, processing within the CPU, and output via a monitor,

printer, etc. It would not concern the actual layout of the tangible hardware, which for
http://en.wikipedia.org/wiki/Datahttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Systems_theoryhttp://en.wikipedia.org/wiki/Product_developmenthttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Systems_architecturehttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Product_developmenthttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Standardizationhttp://en.wikipedia.org/wiki/Modularity_%28programming%29http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Modularity_%28programming%29http://en.wikipedia.org/wiki/Standardizationhttp://en.wikipedia.org/wiki/Data_processinghttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/Product_developmenthttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_architecturehttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Product_developmenthttp://en.wikipedia.org/wiki/Systems_theoryhttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/Data


7/20


8/20

Requirements analysis - analyzes the needs of the end users or customers

Benchmarkingis an effort to evaluate how current systems perform

Systems architecture - creates a blueprint for the design with the necessaryspecifications for the hardware, software, people and data resources. In many cases,

multiple architectures are evaluated before one is selected.

Designdesigners will produce one or more 'models' of what they see a systemeventually looking like, with ideas from the analysis section either used or discarded.

A document will be produced with a description of the system, but nothing is specific

they might say 'touchscreen' or 'GUI operating system', but not mention any

specific brands;

Computer programming and debugging in the software world, or detailed design inthe consumer, enterprise or commercial world - specifies the final system

components.

System testing - evaluates the system's actual functionality in relation to expected orintended functionality, including all integration aspects.

2.3 SYSTEMS DEVELOPMENT LIFE CYCLE

A life cycle is a diagrammatical illustration of all the activities, processes,activities

and operation that are carried out step by step from the beginning to the end of a

particular development project or object.

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle

in systems engineering, information systems and software engineering, is a process of

creating or altering information systems, and the models and methodologies that

people use to develop these systems.

In software engineering the SDLC concept underpins many kinds of software

development methodologies. These methodologies form the framework for planning

and controlling the creation of an information system: the software development

process.

Systems Development Life Cycle (SDLC) is a process used by a systems analyst to

develop an information system, including requirements, validation, training, and user
http://en.wikipedia.org/wiki/Designhttp://en.wikipedia.org/wiki/Computer_programminghttp://en.wikipedia.org/wiki/Debugginghttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/Methodologieshttp://en.wikipedia.org/wiki/Methodologieshttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/Debugginghttp://en.wikipedia.org/wiki/Computer_programminghttp://en.wikipedia.org/wiki/Design


9/20

(stakeholder) ownership. Any SDLC should result in a high quality system that meets

or exceeds customer expectations, reaches completion within time and cost estimates,

works effectively and efficiently in the current and planned Information Technology

infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer

systems are complex and often (especially with the recent rise of Service-Oriented

Architecture) link multiple traditional systems potentially supplied by different

software vendors. To manage this level of complexity, a number of SDLC models or

methodologies have been created, such as "waterfall"; "spiral"; "Agile software

development"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".

SDLC models can be described along a spectrum of agile to iterative to sequential.

Agile methodologies, such as XP and Scrum, focus on lightweight processes which

allow for rapid changes along the development cycle. Iterative methodologies, such as

Rational Unified Process and Dynamic Systems Development Method, focus on

limited project scope and expanding or improving products by multiple iterations.

Sequential or big-design-up-front (BDUF) models, such as Waterfall, focus on

complete and correct planning to guide large projects and risks to successful and

predictable results.Other models, such as Anamorphic Development, tend to focus on

a form of development that is guided by project scope and adaptive iterations of

feature development.

In project management a project can be defined both with a project life cycle (PLC)

and an SDLC, during which slightly different activities occur. According to Taylor

(2004) "the project life cycle encompasses all the activities of the project, while the

systems development life cycle focuses on realizing the product requirements".

2.4.1 History

The Systems Life Cycle (SLC) is a methodology used to describe the process for

building information systems, intended to develop information systems in a very

deliberate, structured and methodical way, reiterating each stage of the life cycle. The

systems development life cycle, according to Elliott & Strachan & Radford (2004),

"originated in the 1960s,to develop large scale functional business systems in an age

of large scale business conglomerates. Information systems activities revolved around

heavy data processing and number crunching routines".
http://en.wikipedia.org/wiki/Information_Technologyhttp://en.wikipedia.org/wiki/Number_crunchinghttp://en.wikipedia.org/wiki/Number_crunchinghttp://en.wikipedia.org/wiki/Information_Technology


10/20

Several systems development frameworks have been partly based on SDLC, such as

the Structured Systems Analysis and Design Method (SSADM) produced for the UK

government Office of Government Commerce in the 1980s. Ever since, according to

Elliott (2004), "the traditional life cycle approaches to systems development have

been increasingly replaced with alternative approaches and frameworks, which

attempted to overcome some of the inherent deficiencies of the traditional SDLC".

2.4.2 Systems development phases

The System Development Life Cycle framework provides a sequence of activities for

system designers and developers to follow. It consists of a set of steps or phases in

which each phase of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are

essential for developers, such as planning, analysis, design, and implementation, and

are explained in the section below. A number of system development life cycle

(SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid

prototyping, incremental, and synchronize and stabilize. The oldest of these, and the

best known, is the waterfall model: a sequence of stages in which the output of each

stage becomes the input for the next. These stages and phases are elaborated and

carefully studies and evaluated so as to attain a well grounded understanding on their

several areas and domain as they will eventually be employed in the research

development. These stages can be characterized and divided up in different ways,

including the following:

Project planning, feasibility study: Establishes a high-level view of the intendedproject and determines its goals.

An important task in creating a software product is extracting the requirements or

requirements analysis. Customers typically have an abstract idea of what they want as

an end result, but not what software should do. Incomplete, ambiguous, or even

contradictory requirements are recognized by skilled and experienced software

engineers at this point. Frequently demonstrating live code may help reduce the risk

that the requirements are incorrect.

Once the general requirements are gathered from the client, an analysis of the scope

of the development should be determined and clearly stated. This is often called a

scope document.


11/20

Certain functionality may be out of scope of the project as a function of cost or as a

result of unclear requirements at the start of development. If the development is done

externally, this document can be considered a legal document so that if there are ever

disputes, any ambiguity of what was promised to the client can be clarified

Systems analysis, requirements definition: Defines project goals into defined

functions and operation of the intended application. Analyzes end-user information

needs.

Systems design: Describes desired features and operations in detail, including screenlayouts, business rules, process diagrams, pseudocode and other documentation.

Implementation: The real code is written here.

Integration and testing: Brings all the pieces together into a special testingenvironment, then checks for errors, bugs and interoperability.

Acceptance, installation, deployment: The final stage of initial development, wherethe software is put into production and runs actual business.

Maintenance: What happens during the rest of the software's life: changes,correction, additions, moves to a different computing platform and more. This, the

least glamorous and perhaps most important step of all, goes on seemingly forever.

In the following example these stage of the Systems Development Life Cycle are

divided in ten steps from definition to creation and modification of IT work products:

The tenth phase occurs when the system is disposed of and the task performed is

either eliminated or transferred to other systems. The tasks and work products for

each phase are described in subsequent chapters.

Not every project will require that the phases be sequentially executed. However, the

phases are interdependent. Depending upon the size and complexity of the project,

phases may be combined or may overlap.

2.4.3 System analysis

The goal ofsystem analysis is to determine where the problem is in an attempt to fix

the system. This step involves breaking down the system in different pieces to analyze
http://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Work_breakdown_structurehttp://en.wikipedia.org/wiki/Work_breakdown_structurehttp://en.wikipedia.org/wiki/Systems_analysis


12/20

the situation, analyzing project goals, breaking down what needs to be created and

attempting to engage users so that definite requirements can be defined.

Requirements analysis sometimes requires individuals/teams from client as well as

service provider sides to get detailed and accurate requirements; often there has to be

a lot of communication to and from to understand these requirements. Requirement

gathering is the most crucial aspect as many times communication gaps arise in this

phase and this leads to validation errors and bugs in the software program.

2.4.4 Design

In systems design the design functions and operations are described in detail,

including screen layouts, business rules, process diagrams and other documentation.The output of this stage will describe the new system as a collection of modules or

subsystems.

The design stage takes as its initial input the requirements identified in the approved

requirements document. For each requirement, a set of one or more design elements

will be produced as a result of interviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include

functional hierarchy diagrams, screen layout diagrams, tables of business rules,

business process diagrams, pseudocode, and a complete entity-relationship diagram

with a full data dictionary. These design elements are intended to describe the

software in sufficient detail that skilled programmers may develop the software with

minimal additional input design.

2.4.5 Testing

Software testing is an integral and important phase of the software development

process. This part of the process ensures that defects are recognized as soon as

possible.

The code is tested at various levels in software testing. Unit, system and user

acceptance testings are often performed. This is a grey area as many different

opinions exist as to what the stages of testing are and how much if any iteration

occurs. Iteration is not generally part of the waterfall model, but usually some occur at

this stage. In the testing the whole system is test one by one
http://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Requirements_analysis


13/20

Following are the types of testing:

Defect testing the failed scenarios, including defect tracking Path testing Data set testing Unit testing System testing Integration testing Black box testing White box testing Regression testing Automation testing User acceptance testing Performance testing

2.4.6 Operations and maintenance

The deployment of the system includes changes and enhancements before the

decommissioning or sunset of the system. Maintaining the system is an important

aspect of SDLC. As key personnel change positions in the organization, new changes

will be implemented, which will require system updates.

Implementation is the part of the process where software engineers actually program

the code for the project.

Documenting the internal design of software for the purpose of future maintenance

and enhancement is done throughout development. This may also include the writing

of an API, be it external or internal. The software engineering process chosen by thedeveloping team will determine how much internal documentation (if any) is

necessary. Plan-driven models (e.g., Waterfall) generally produce more

documentation than Agile models.

Deployment starts after the code is appropriately tested, is approved for release and

sold or otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to realize that.

It would not matter how much time and planning a development team puts into

creating software if nobody in an organization ends up using it. People are often
http://en.wikipedia.org/wiki/Software_releasehttp://en.wikipedia.org/wiki/Software_release


14/20

resistant to change and avoid venturing into an unfamiliar area, so as a part of the

deployment phase, it is very important to have training classes for new clients of your

software.

Maintaining and enhancing software to cope with newly discovered problems or new

requirements can take far more time than the initial development of the software. It

may be necessary to add code that does not fit the original design to correct an

unforeseen problem or it may be that a customer is requesting more functionality and

code can be added to accommodate their requests. If the labor cost of the maintenance

phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall

quality of at least one prior phase is poor. In that case, management should consider

the option of rebuilding the system (or portions) before maintenance cost is out of

control.

Comparison of Methodology Approaches

SDLC RAD Open Source Objects JAD Prototyping End User

Control Formal MIS Weak Standards Joint User User

Time Frame Long Short Medium Any Medium Short Short

Users Many Few Few Varies Few One or Two One

MIS staff Many Few Hundreds Split Few One or Two None

Transaction/DSS Transaction Both Both Both DSS DSS DSSInterface Minimal Minimal Weak Windows Crucial Crucial Crucial

Documentation

and trainingVital Limited Internal In Objects Limited Weak None

Integrity and

securityVital Vital Unknown In Objects Limited Weak Weak

Reusability Limited Some Maybe Vital Limited Weak None

2.4.7 Strengths and weaknesses

Few people in the modern computing world would use a strict waterfall model for

their Systems Development Life Cycle (SDLC) as many modern methodologies have

superseded this thinking. Some will argue that the SDLC no longer applies to models

like Agile computing, but it is still a term widely in use in Technology circles. The

SDLC practice has advantages in traditional models of software development, that

lends itself more to a structured environment. The disadvantages to using the SDLC

methodology is when there is need for iterative development or (i.e. web development

or e-commerce) where stakeholders need to review on a regular basis the softwarebeing designed. Instead of viewing SDLC from a strength or weakness perspective, it


15/20

is far more important to take the best practices from the SDLC model and apply it to

whatever may be most appropriate for the software being designed.

A comparison of the strengths and weaknesses of SDLC:

Strength and Weaknesses of SDLC

Strengths Weaknesses

Control. Increased development time.

Monitor Large projects. Increased development cost.

Detailed steps. Systems must be defined up front.

Evaluate costs and completion targets. Rigidity.

Documentation. Hard to estimate costs, project overruns.

Well defined user input. User input is sometimes limited.

Ease of maintenance.

Development and design standards.

Tolerates changes in MIS staffing.

An alternative to the SDLC is Rapid application development, which combines

prototyping, Joint Application Development and implementation of CASE tools. The

advantages of RAD are speed, reduced development cost, and active user involvement

in the development process.

2.5 SOFTWARE DEVELOPMENT MODELS

Several models exist to streamline the development process. Each one has its pros and

cons, and it's up to the development team to adopt the most appropriate one for the

project. Sometimes a combination of the models may be more suitable.

2.5.1 Waterfall model

The waterfall model shows a process, where developers are to follow these phases in

order:

1. Requirements specification (Requirements analysis)2. Software design3. Implementation and Integration4. Testing (or Validation)5. Deployment (or Installation)6. Maintenance
http://en.wikipedia.org/wiki/Software_Requirements_Specificationhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/System_integrationhttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Validationhttp://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/wiki/Installation_%28computer_programs%29http://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Installation_%28computer_programs%29http://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/wiki/Validationhttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/System_integrationhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Software_Requirements_Specification


16/20

In a strict Waterfall model, after each phase is finished, it proceeds to the next one.

Reviews may occur before moving to the next phase which allows for the possibility

of changes (which may involve a formal change control process). Reviews may also

be employed to ensure that the phase is indeed complete; the phase completion

criteria are often referred to as a "gate" that the project must pass through to move to

the next phase. Waterfall discourages revisiting and revising any prior phase once it's

complete. This "inflexibility" in a pure Waterfall model has been a source of criticism

by supporters of other more "flexible" models.

2.5.2 Spiral model

The key characteristic of a Spiral model is risk management at regular stages in the

development cycle. In 1988, Barry Boehm published a formal software system

development "spiral model", which combines some key aspect of the waterfall model

and rapid prototyping methodologies, but provided emphasis in a key area many felt

had been neglected by other methodologies: deliberate iterative risk analysis,

particularly suited to large-scale complex systems.

The Spiral is visualized as a process passing through some number of iterations, with

the four quadrant diagram representative of the following activities:

1. formulate plans to: identify software targets, selected to implement the program,clarify the project development restrictions;

2. Risk analysis: an analytical assessment of selected programs, to consider how toidentify and eliminate risk;

3. the implementation of the project: the implementation of software development andverification;

Risk-driven spiral model, emphasizing the conditions of options and constraints in

order to support software reuse, software quality can help as a special goal of

integration into the product development. However, the spiral model has some

restrictive conditions, as follows:

1. The spiral model emphasizes risk analysis, and thus requires customers to accept thisanalysis and act on it. This requires both trust in the developer as well as the

willingness to spend more to fix the issues, which is the reason why this model is

often used for large-scale internal software development.
http://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Rapid_application_developmenthttp://en.wikipedia.org/wiki/Rapid_application_developmenthttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Barry_Boehm


17/20

2. If the implementation of risk analysis will greatly affect the profits of the project, thespiral model should not be used.

3. Software developers have to actively look for possible risks, and analyze it accuratelyfor the spiral model to work.

The first stage is to formulate a plan to achieve the objectives with these constraints,

and then strive to find and remove all potential risks through careful analysis and, if

necessary, by constructing a prototype. If some risks cannot be ruled out, the customer

has to decide whether to terminate the project or to ignore the risks and continue

anyway. Finally, the results are evaluated and the design of the next phase begins.

2.5.3 Iterative and incremental development

Iterative development prescribes the construction of initially small but ever-larger

portions of a software project to help all those involved to uncover important issues

early before problems or faulty assumptions can lead to disaster. Iterative processes

can assist with revealing design goals of a client who does not know how to define

what they want.

Nimble Rabbit is a flexible development process or framework with a set of practicesand overlapping roles that are intended to help define what the developers do well,

and the solutions to improve those processes which fall short. Nimble Rabbit is

specifically designed to work well in a telecommuting/distributed environment. It is

intended to avoid many of the false assumptions and traps of existing agile

frameworks such as Scrum.

2.5.4 Agile development

Agile software development uses iterative development as a basis but advocates a

lighter and more people-centric viewpoint than traditional approaches. Agile

processes use feedback, rather than planning, as their primary control mechanism. The

feedback is driven by regular tests and releases of the evolving software.

There are many variations of agile processes:

In Extreme Programming (XP), the phases are carried out in extremely small (or"continuous") steps compared to the older, "batch" processes. The (intentionally

incomplete) first pass through the steps might take a day or a week, rather than the
http://ntobjectives.com/culture-nimble-rabbithttp://en.wikipedia.org/wiki/Extreme_Programminghttp://en.wikipedia.org/wiki/Extreme_Programminghttp://ntobjectives.com/culture-nimble-rabbit


18/20

months or years of each complete step in the Waterfall model. First, one writes

automated tests, to provide concrete goals for development. Next is coding (by a pair

of programmers), which is complete when all the tests pass, and the programmers

can't think of any more tests that are needed. Design and architecture emerge out of

refactoring, and come after coding. Design is done by the same people who do the

coding. (Only the last featuremerging design and codeis common to all the

other agile processes.) The incomplete but functional system is deployed or

demonstrated for (some subset of) the users (at least one of which is on the

development team). At this point, the practitioners start again on writing tests for the

next most important part of the system.

Scrum

2.5.6 Code and fix

"Code and fix" development is not so much a deliberate strategy as an artifact of

naivet and schedule pressure on software developers. Without much of a design in

the way, programmers immediately begin producing code. At some point, testing

begins (often late in the development cycle), and the inevitable bugs must then be

fixed before the product can be shipped.

2.5.7 Process improvement models

Capability Maturity Model Integration

The Capability Maturity Model Integration (CMMI) is one of the leading models and

based on best practice. Independent assessments grade organizations on how well they

follow their defined processes, not on the quality of those processes or the software

produced. CMMI has replaced CMM.

ISO 9000

ISO 9000 describes standards for a formally organized process to manufacture a

product and the methods of managing and monitoring progress. Although the standard

was originally created for the manufacturing sector, ISO 9000 standards have been

applied to software development as well. Like CMMI, certification with ISO 9000

does not guarantee the quality of the end result, only that formalized business

processes have been followed.

ISO 15504

ISO 15504, also known as Software Process Improvement Capability Determination

(SPICE), is a "framework for the assessment of software processes". This standard is
http://en.wikipedia.org/wiki/Refactoringhttp://en.wikipedia.org/wiki/Scrum_%28development%29http://en.wikipedia.org/wiki/Programmerhttp://en.wikipedia.org/wiki/Source_codehttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Computer_bughttp://en.wikipedia.org/wiki/Computer_bughttp://en.wikipedia.org/wiki/Software_testinghttp://en.wikipedia.org/wiki/Source_codehttp://en.wikipedia.org/wiki/Programmerhttp://en.wikipedia.org/wiki/Scrum_%28development%29http://en.wikipedia.org/wiki/Refactoring


19/20

aimed at setting out a clear model for process comparison. SPICE is used much like

CMMI. It models processes to manage, control, guide and monitor software

development. This model is then used to measure what a development organization or

project team actually does during software development. This information is analyzed

to identify weaknesses and drive improvement. It also identifies strengths that can be

continued or integrated into common practice for that organization or team.

2.5.8 Formal methods

Formal methods are mathematical approaches to solving software (and hardware)

problems at the requirements, specification and design levels. Examples of formal

methods include the B-Method, Petri nets, Automated theorem proving, RAISE and

VDM. Various formal specification notations are available, such as the Z notation.

More generally, automata theory can be used to build up and validate application

behaviour by designing a system of finite state machines.

Finite state machine (FSM) based methodologies allow executable software

specification and by-passing of conventional coding

Formal methods are most likely to be applied in avionics software, particularly where

the software is safety critical. Software safety assurance standards, such as DO178B

demand formal methods at the highest level of categorization (Level A).

Formalization of software development is creeping in, in other places, with the

application of Object Constraint Language (and specializations such as Java Modeling

Language) and especially with Model-driven architecture allowing execution of

designs, if not specifications.

Another emerging trend in software development is to write a specification in some

form of logic (usually a variation of FOL), and then to directly execute the logic as

though it were a program. The OWL language, based on Description Logic, is an

example. There is also work on mapping some version of English (or another natural

language) automatically to and from logic, and executing the logic directly. Examples

are Attempto Controlled English, and Internet Business Logic, which does not seek to

control the vocabulary or syntax. A feature of systems that support bidirectional

English-logic mapping and direct execution of the logic is that they can be made to

explain their results, in English, at the business or scientific level.
http://en.wikipedia.org/wiki/Petri_nethttp://en.wikipedia.org/wiki/Z_notationhttp://en.wikipedia.org/wiki/Web_Ontology_Languagehttp://en.wikipedia.org/wiki/Attempto_Controlled_Englishhttp://en.wikipedia.org/wiki/Attempto_Controlled_Englishhttp://en.wikipedia.org/wiki/Web_Ontology_Languagehttp://en.wikipedia.org/wiki/Z_notationhttp://en.wikipedia.org/wiki/Petri_net


20/20

A Review of Information System Process

Documents

Transcript of A Review of Information System Process