Information System

• IS: a set of related components working together in some environment to perform functions that achieve some objective.

Process

Standard operatingprocedures

Organizationalpolicies

Input Output

Customers

Competitors

GovernmentRegulations

Shippers

• IS Functions– Input, Processing, Output, Storage, Controls

• IS Components– People, Procedures, Data, Software, Hardware

Alternative: Object-oriented view of a system

Systems Development: the process

• System lifecycle: – development phase *– production phase

• Systems approach– divide and conquer

conversion

• System Analysis– study business problem domain,

existing system– identify requirements– specify characteristics of new system

• System decomposition– by functions performed– in terms of objects

Systems Development: the process

• System Design– evaluate alternative solutions,

design a chosen solution– design document: basis for implementation

Systems Development: the process

Two system development approaches

• Functional Decomposition– identify major activities, break up into composite

steps (structured analysis and design)– focus on verbs (what a system does)

• Objects that comprise the system and how they act and relate– object structure and behavior analysis– focus on nouns (objects performing functions)

SDLC

• System development methodology– activities to solve a problem

• A methodology uses certain techniques

(used to model a system)• Model

– representation of real world– used in analyzing and communicating what we

understand

DATA MODELS, PROCESS MODELS, OBJECT MODELS, etc.

System development catalysts

• User demandproblems in current system, need for enhancements, improved efficiency

• Technology pushnew technology as catalysts

• Strategic pullsystem to support new business strategies/ products to stay competitive

Projects of varying complexity• Upto 1000 lines

– trivial, single person, few days/week

• 1000-10,000 lines

– simple, 3/4 progr/analyst, 6-12 months

– often formal analysis and design not used, but could be - leads to more maintainable system

• 10,000-100,000 lines

– difficult, 6-12 people, 2-3 years

– formal analysis and design essential

– requirements/users change over time

• 100,000 - 1 million lines

– complex. 50-100 people, 3-5 years

– diverse community of users

• 1-10 million lines

– nearly impossible

• > 10 million

– absurd??

Why do IS projects fail?

• Did not support business strategy & objectives• poor planning, project management• failure to understand user requirements

– user involvement in system development

• inadequate cost vs. benefit analysis– escalating costs, intangible benefits

• myriad of design defects/ errors• installation of incompatible or inadequate

technology• no adequate controls implemented• unstructured, un-maintainable software

Successful systems development

• Informal, sloppy art structured, engineered and managed approach (SDLC)

• stress user involvement in system development• system planning and project management• evaluate alternate designs before committing• clean, complete and up-to-date documentation• design for growth and change

Bugs!

• software errors cost U.S. users $59.5 billion each year. (National Institute of Standards and Technology (NIST)

– just the cost of routine work-arounds and corrections by users, along with the added cost of buggy software that had to be fixed late in the development process. The real cost of bugs is much higher.

– $22.2 billion of that $59.5 billion, or 37%, could be saved through "feasible improvements" in software testing.

– “We indulge ourselves with the idea that all software has bugs, so trying harder to get rid of them is pointless perfectionism. Intellectually we should know better” !

Software: the product

• Software: a strategic business issue, not just a low-level support activity

• Can software be “manufactured” like physical products? (software “factories”)– Costs are concentrated on engineering (design)

and support– “mythical man-month” Adding people to a project that is late will only worsen the situation. Why?

• Efficiency through re-use

Time

Failure Rate

Hardware Software

Infant mortality

Wear out

Ideal

Changes

Failure Curves

Actual

The Systems Analyst

• Roles– as a CONSULTANT (external)

• provide a fresh perspective

• disadvantage: organizational culture may not be known

– as a SUPPORTING EXPERT– as a CATALYST FOR CHANGE

• interact with management

• excellent with people and machines

• analyze need for change, design change with consensus, implement change

The Systems Analyst

• Qualities– problem solver

• good analysis skills

• tools and techniques for analysis

– communicator– computer skills– knowledge of business processes– self-disciplined and self-motivated

Systems Development Process set of activities, methods, best practices and deliverables that are used to develop and maintain information systems.

Process maturityas the development process matures, project costs decrease, timelines improve, productivity and quality increase.

Software development - The Process

Guiding principles

• Get the Owners and Users Involved

• Establish Phases and Activities

• Establish Standards for Development and Documentation

• Justify systems as Capital Investments

• Don’t be afraid to Cancel or Revise Scope

• Divide and Conquer

• Design for Growth and Change

Software development - The Process3 Generic Phases• Definition (What)

– Customer contact• role of system, scope

– Project Planning• risk analysis, resources, cost estimation, schedules

– Requirement Analysis

• Development (How)– Design– Coding– Testing

• Maintenance– Correction of errors– Adaptation– Enhancements

• Preliminary Investigation Phase – establishes the project context, scope, budget, staffing, and schedule.

• Problem Analysis Phase – identifies and analyzes both the business and technical problem

domains for specific problems, causes, and effects• Requirements Analysis Phase

– identifies and analyzes business requirements that should apply to any possible technical solution to the problems.

• Decision Analysis Phase – identifies and analyzes candidate technical solutions that might solve

the problem and fulfill the business requirements. The result is a feasible, target solution.

Alternatively…

Alternatively (2)…• Purchasing Phase (optional)

– identifies and analyzes hardware and software products that will be purchased as part of the target solution.

• Design Phase – specifies the technical requirements for the target solution.

Today, the design phase typically has significant overlap with the construction phase.

• Construction Phase – builds and tests the actual solution (or interim prototypes of the

solution).

• Implementation Phase – puts the solution into daily production.

• Operation and Support Phase

– continues until the system is obsolete.

• Preliminary Investigation– “Is this project worth looking at?”– Define the scope of the project, the perceived problems,

opportunities, and directives that triggered the project. – Establish the project team and participants, the project budget,

and the project schedule.

• Problem Analysis– Gain an appropriate understanding of the business

problem domain– Determine if the system is worth developing– Learning the system terminology, history, culture, and

nuances of the organization (or department). – Address the causes and effects of the problems,

opportunities, and directives.

• Requirements Analysis– Identify the data, process, interface, and geographic

requirements for the users of a new system. – Specify these requirements without expressing

computer alternatives and technology details; at this point, keep analysis at the business level.

– Prioritize - requirements can be classified as ‘mandatory’, ‘desirable’, or ‘optional’.

• Decision Analysis– Define the candidate solutions– Evaluate each candidate for feasibility (next slide).– Recommend a feasible candidate as the target

system. – Feasibility analysis

• Purchasing– research the technology and marketplace– organize the business, technology, and relationship

requirements, and establishes the mechanisms that will be used to evaluate the technical alternatives.

– write the RFP. – receive proposals from vendors.– evaluate proposals.– make a recommendation to the system owners (and

usually the information system managers as well).– execute the final orders, contracts, licenses, and

service agreements.

• Design– transform the business requirements from the definition

phase into a set of technical design blueprints for construction.

– addresses how specific technologies will be used in the new system.

– design specs can include written documentation or prototypes

– existing systems must be integrated in the design.

• Construction– build and test a functional system that fulfills business and

design requirements

– implement the interfaces between the new system and existing systems

– system testing – unit and system testing

• Implementation– Install, deploy, and place the new system into

operation or production. – User training, manuals, loading files and databases

• Operations and System Support– ongoing maintenance of a system after it has been placed

into operation. This includes program maintenance and system improvements.

Systems Analysis– Organizational context and requirements (Enterprise Modeling)– Functional area context and requirements (Workflow diagrams)

– Analyze existing System• Physical analysis• Logical analysis

– New System requirement• Logical model of new system (Requirement specification)( Functional requirements - DFDs)

– Documentation • Requirement specification Document

•

SystemEnvironment

System design– General design

• Logical design of alternatives (broad sketches)

• Evaluate and choose a solution approach

– Detailed design (Physical design)• Process design - program specification

(Program structure charts)

• Data design - logical structure of data and files (E/R Models)

• User interface design - Dialog and document flows

– Design Document

System Implementation

– Coding– Testing– Installation– Manuals, User training

Cross Life Cycle Activities

• Project Management– Schedules and cost, milestones

• Software Quality Assurance– creation of Standards– ensure conformation to those standards

• formal technical views

• documentation of errors

• testing strategy

Cross Life Cycle Activities

• Measurement– Time, Effort, Costs, Productivity, Quality

(Software Metrics)– enhanced estimates of new projects– baseline for process improvement– test effectiveness of new methods

Cross Life Cycle Activities• Software Configuration Management

– Controlled change• customers change requirements• developers change technical approach• management modifies project approach

– Software configuration• Programs• Documents• Data structures

• Documentation• Fact Finding

• Effort Distribution

Development : Maintenance

40:60, 30:70

• Development Costs (Typical)Requirement : 10%

Design : 20%

Coding : 20%

Testing : 50% (often under-estimated. Can be reduced through better design and coding)

[Note: easy to test easy to maintain]

Software Engg. Paradigms ( Process models)

• Waterfall model (Classical life Cycle)Planning

Reqt.Analysis

Design

Code

TestInstall

Maintenance

Feasibility Report

Requirements Specification Report

Design Document

Programs

Test Report

Installation Report

Waterfall Model• old way of doing things• All projects go through these phases

But…• Sequential progress unrealistic, iterations expensive• Frozen requirements

• difficult to state all requirements at the beginning• requirements drift

• gap between users and designers, little communication with users

• working system unavailable till late in the project– also disastrous for errors at this stage

Reqt.Generationand refinement

Quick Design

Customer Evaluation of prototype

Refine Prototype Engineer Product

BuildPrototype

Software Engineering paradigms• Prototyping - a modeling paradigm

• Discard prototype

• Engineer prototype to production system

Prototyping: Problems• Customer impatient when prototype is rebuilt to production

system– Inefficient system often becomes the production system system

• (NOTE: Ideally prototyping is the mechanism for identifying requirements)– high risk innovation applications– promote send user participation– good candidates for prototyping:– user unable to specify requirements.– Do not know what they want/what they want is not what they

need– “I do not know what I want , but I will when I see it”

Software Engineering paradigms

• The RAD model (Rapid Application Development)

– linear sequential development,emphasizes very short development cycle

– component based construction– well-understood requirement, constrained scope– use of fourth generation techniques (4GLs)

Rapid Application Development

Business Modeling

Data Modeling

Process Modeling

ApplicationGeneration

Testing andTurnover

60 -100 days

Team 1 Team 2 Team 3

RAD• 4GLs :

– Enable developers to specify s/w characteristics at higher level of abstraction. Tool automatically generates source code.

• Tools:– non-procedural languages for DB query,report

generation,data manipulation ,screen interaction, graphics,etc

– reduces development time for smaller applications– user and developer commitment to rapid-fire activities– inefficient code? Use where high performance is required?– Use of reusable program components

OOD

Customerprototype

OOA

Browse libraryof reusablecomponents

CustomerEvaluation

Design/Implementation

Component Library

ComponentSpecification

ComponentDesign

Libraryentry

Coding

Testing

Software Engineering paradigms

• O-O Systems Development: reuse paradigm

O-O development

– Focus on reuse • Object Class library

– Focus on interoperability– Faster development,easier

maintenance,platform independence

Risk analysis based on initial requirements

PlanningPlanning Risk analysisRisk analysis

Customer evaluationCustomer evaluation EngineeringEngineering

Risk analysis based on customer reaction

Go, no-go decision

Toward a completedsystem

Initial software prototype

Next prototype level

Engineered system

Customerevaluation

Planning basedon customercomments

Initial requirementsgathering and projectplanning

Spiral Model