1 Systems Development

7/30/2019 1 Systems Development

1/16

10/26/2009

Jnkping International Business School 1

Richard Carlsson

1Richard Carlsson, JnkpingInternational Business School

AssignmentAssignment

1st meeting

WOLFRAM

B4043

2nd meeting

Richard

B4050

Richard Carlsson, JnkpingInternational Business School 2

Learning ObjectivesLearning Objectives

How to define an Information System(IS)

The problems in IS development andthe underlying causes of theseproblems

The stages in the waterfall life cycle Prototyping and incremental life

cycles

Richard Carlsson, JnkpingInternational Business School 3? Richard Carlsson, JnkpingInternational Business School 4

Elements of an ISElements of an IS

Every IS has:

A human activity that needs information

Some stored data

An input method for entering data

Some process that turns the data into information

An output method for representing information

Information Systems developmentInformation Systems development


DATA INFORMATION KNOWLEDGE

Anna

32

20081001

Name:

Age:

Reg Date:

TacitExplicit

Explicit and TacitExplicit and Tacit knowlegdeknowlegde



2/16

10/26/2009


2-7

Systems ThinkingSystems Thinking

The Systems Approach is a process which allowsprojects to be viewed in the context of the entireenvironment including both inside and outside

of the organization. It is a process that can bringorder and discipline to a large, chaotic,unorganized situation

Richard Carlsson, JnkpingInternational Business School

Pearson Education

2-8

Systems Boundary and EnvironmentSystems Boundary and Environment


Pearson Education

EnvironmentEnvironment


PoliticalEnvironment

EconomicEnvironment

SocialEnvironment

Organisation

2-10

Systems TerminologySystems Terminology

Objectives human-made systems are

designed to do something

Constraints - every system has limitations

forced on them from internal forces or externalforces and sometimes the limits are self

controlled (Scope, Time, Cost) Requirement a partial need to satisfy the

objective


Pearson Education

2-11

Systems TerminologySystems Terminology Integration for a system to reach its

objectives, all the subsystems and elementsmust work together effectively

Open and Closed Systems

Closed self contained, focus on internal workings(machine). Ignore the environments influence

Open just the opposite, they interact with theenvironment and adapt. (humans, organizations)


Pearson Education

2-12

Systems ThinkingSystems Thinking

Allows projects to be viewed in the context of theentire environment including both inside andoutside of the organization

Individuals look at the whole organism ratherthan just the parts

Harold Kerzner wrote: the ability to analyze thetotal project, rather than the individual parts is thefirst prerequisite for successful projectmanagement

The ability to examine a problem or issue by firstunderstanding the environment it exists within,before reducing the problem or issue into smallercomponents and finally managing the resolution ofthe problem or issue


Pearson Education


3/16

10/26/2009


2-13

Definition of SystemDefinition of System

An organized or complex whole; an assemblageof things or parts interacting in a coordinatedway

Characteristics The whole is greater than the sum of its parts (body)

They are dynamic and exhibit some kind of behavior

Scope is in the eye of the beholder (or stakeholder)


Pearson Education

SystemsSystems


Richard Carlsson, JnkpingInternational Business School 15 2-16


Elements smallest part of a system beingstudied (activity)

Subsystems a system is made up ofsubsystems, smaller systems that are part of alarger system such as the human heart is asubsystem of the human body or the accounts

receivable subsystem is a part of the financialsoftware system of the organization Attributes quantitative and qualitative

characteristics of systems (Project; Cost andProgress )


Pearson Education

2-17


Environment anything that lies beyond thedecision makers control yet influences thebehavior or outcome of the system

Boundary what separates the system from theenvironment (skin).

Most of what a Project Manager does exists onthe boundary!


Pearson Education


System TransformationSystem Transformation

All useful systems transform their inputs into

useful outputs

For IS, both inputs and outputs are typically

information

This transformation is the whole reason forbuilding and operating the system


4/16

10/26/2009



Transformation ExampleTransformation Example

A Delivery Scheduling System may have inputs:

Information about orders, available stock, customeraddresses, vehicle capacities

And may have outputs:

Which orders to load on each vehicle, what route thevehicle should follow

How does this benefit the organization?


Are Systems Real?Are Systems Real?

Maybe, maybe not!

Systems thinking is useful because it helps toanalyse and understand problems

What matters is the understanding you achieve

You can choose to see anything as a system,whether or not it really is one

Richard Carlsson, JnkpingInternational Business School 21 Richard Carlsson, JnkpingInternational Business School 22

Types of ISTypes of IS

Information Systems are used to support

peoples activities

Store and retrieve information

Carry out calculations

Aid communication

Control and schedule work Other support ?


Types ofTypes of ISIS Operational Systems assist or control business

operations An Accounting System replaces costly and error-prone

human clerks

Management Support Systems help managers todecide or to communicate A Delivery Scheduling System helps decide how to load

and route the delivery trucks

Real-time Control Systems typically operatephysical equipment, often in safety-critical settings Some cars have an Engine Management System to

control fuel supply and ignition


How Do ISHow Do IS Relate to the Human ActivityRelate to the Human ActivitySystem?System? We can view an organization as a system,

perhaps with many subsystems

Ideally, each subsystem helps the overall system

fulfil its purpose

IS are also subsystems and should help to meetgoals of people in the organization


5/16

10/26/2009



Strategy and Planning for ISStrategy and Planning for IS

Business Strategy

Information Systems Strategy

Information Technology Strategy

Drives and sets goals

System requirements

What must be doneWhere IS can help

Informs and enables

Hardware capabilities

Information Technology StrategyInformation Technology Strategy

Richard Carlsson, [email protected] 26

Data StandardsData Standards

Identifier

Naming

Definition

Customer?

Integrity rules

Valid values

Usage Rights

All data all users?


(Service Oriented )Architecture(Service Oriented )Architecture



The Main PlayersThe Main Players

Three main types of player are involved in an ISdevelopment project: Those who will benefit from the systems outputs,

directly or indirectly (end-users)

Those who commission the project, pay for it or havethe power to halt it (owners or sponsors)

Those who will produce the software (developers)


Stakeholder AnalysisStakeholder Analysis

This approach tries to identify everyone affected

by a proposed IS

Who are the stakeholders?

How does the system affect each group?

What are their legitimate concerns?

Are there any legal implications?


6/16

10/26/2009


StakeholdersStakeholders

Richard Carlsson, [email protected] 31 Richard Carlsson, JnkpingInternational Business School 32

What Do We Mean by Problem?What Do We Mean by Problem?

An IS project may fail before delivery

An IS may fail after delivery

An IS may be continue to be used, despitecausing problems to its users, its owners or itsdevelopers


EndEnd--user Viewuser View

End-users may directly operate the software, or

may be more remote, e.g. a manager whoreceives printed reports

Typical concerns include:

A system that is promised but not delivered

A system that is difficult to use

A system that doesnt meet its users needs

Richard Carlsson, [email protected] 34


Owner ViewOwner View

Owners care about meeting business needs andabout value for money

Typical concerns include: Projects that overspend their budget (may no longer

have a net benefit) Systems that are delivered too late Badly managed projects

Systems that are rendered irrelevant by events


Developer ViewDeveloper View

IS developers sometimes have a difficult time

Budget and time constraints often conflict with doingthe job properly

Users and owners may not know how to ask for whatthey really want

Technologies, development approaches and businessneeds all constantly change


7/16

10/26/2009



Why Things Go WrongWhy Things Go Wrong

Whether a system is delivered or not, manythings can go wrong

Flynn (1998) categorizes the main causes as:

Quality problems

Productivity problems

MethodologyMethodology

A collection of procedures, techniques, tools, anddocumentation aids which will help the systemsdevelopers in their efforts to implement a new

information system. A methodology will consist ofphases, themselves consisting of sub-phases, whichwill guide the systems developers in their choice ofthe techniques that might be appropriate at each

stage of the project and also help them plan,manage, control and evaluate information systems

projects.Richard Carlsson, JnkpingInternational Business School 38

TTechniqueechnique

A way of doing a particular activity in

the information systems development

process and any particular

methodology may recommendtechniques to carry out many of these

activities.


ToolsTools

Each technique may involve the use of

one or more tools that represent some

of the artefacts used in informationsystems development

tools are usually automated, that is,they are computer tools, normally

software to help the development of an

information system


Scope ofScope of methodologiesmethodologies

Richard Carlsson, JnkpingInternational Business School 41 Richard Carlsson, JnkpingInternational Business School 42

Project Life CyclesProject Life Cycles

A distinction should be made between

Systems development

which incorporates human,

software and

hardware elements

Software development,

which is primarily concerned with software systems


8/16

10/26/2009



Waterfall Life CycleWaterfall Life Cycle

The traditional life cycle (TLC or SDLC) forinformation systems development is also known asthe waterfall life cycle model.

So called because of the difficulty of returning to an

earlier phase.

The model shown here is one of several more or lessequivalent alternatives.

SDLC (SDLC (waterfallwaterfall modelmodel))

Also Traditional Life Cycle (TLC)

Feasibility study

System investigation

Systems analysis

Systems design

Implementation

Review and maintenance


WaterfallWaterfall


Feasibility study

System investigation

Systems analysis

Systems design

Implementation

Review andmaintenance

WaterfallWaterfall (2)(2)


Analysis

Design

Implementation

Verification

Maintenance

Feasibility studyFeasibility study Functional requirements of the existing system (?) and

whether these requirements are being achieved

Requirements of the new system as there may be newsituations or opportunities which suggest alteredrequirements

Any constraints imposed

Range of data types and volumes which have to beprocessed

Exception conditions

Problems of the present working methods


FeasibleFeasible

Observation

Interviewing

Questionnaires

Searching records and documentation

Sampling



9/16

10/26/2009


Systems AnalysisSystems Analysis

Why do the problems exist?

Why were certain methods of work adopted?

Are there alternative methods?

What are the likely growth rates of data?


Systems DesignSystems Design

Input data, how the data entered in the system Outputs

Processes

Structure of the computer and manual files whichmight be referenced in the system

Security and back-up provisions to be made

Systems testing and implementation plans


ImplementationImplementation

Code and test programs

Purchase hardware and software

Quality control

Training and education

Operations and user manuals Security procedures

Cutover and acceptance testing


Review andReview and MaintenanceMaintenance

Report

Organizational learning


RequirementsRequirements ((change/variationchange/variation))

Requirement change to document and/ordiagram

Design require re-checking of assumptions andimplications

Programming may have to re-visit and re-writtencode

Testing re-visit analysis and/or design and/or code

After production and release all of the abovemay have to be re-performed plus data may have tobe re-stored


Costs of requirements errorsCosts of requirements errors



10/16

10/26/2009


Weaknesses of the SDLCWeaknesses of the SDLC

1. Failure to meet the needs of management2. Instability

3. Inflexibility

4. User dissatisfaction

5. Problems with documentation Use the documentation

6. Lack of control

7. Incomplete systems Work around

8. Application backlog Dont care

9. Maintenance workload

10. Problems with the ideal approach Politics

11. Emphasis on hard thinking

12. Assumption of green-field development Old systems


1. Failure to meet all the needs of1. Failure to meet all the needs of

managementmanagement

DataWarehouse & DataMining


3. Design is3. Design is outputoutput--drivendriven


RecurringRecurring problems in ISDproblems in ISD

Meeting project deadlines

System maintenance

Staff recruitment and retention

General user dissatisfaction

Changing requirements



Problems withProblems with SDLC / TLCSDLC / TLC

Real projects rarely follow such a simple sequentiallife cycle

Lapsed time between systems engineering and thefinal installation is long

Iterations are almost inevitable in real projects butare expensive & problematic with the SDLC/TLC

Unresponsive to changes during project as iterationis difficult


Waterfall withWaterfall with IterationIterationSystem

EngineeringSystem

Engineering

DesignDesign

Code

Construction

Testing

MaintenanceMaintenance

RequirementsAnalysis

CodeInstallation

The cost of

this form of

iteration

increases as

the project

progresses

making it

impractical

and not

effective


11/16

10/26/2009



Strengths ofStrengths of SDLCSDLC

Tasks in phases may be assigned to specializedteams.

Project progress evaluated at the end of eachphase.

Can be used to manage projects with high levelsof risks.


Prototyping Life CyclePrototyping Life Cycle

Initialanalysis

Defineobjectives

Specify

ConstructEvaluatePrototypingcompleted

PrototypingPrototyping

A throwawy (or expendable) prototype

An evolutionary prototype


JustificationJustificationforfor prototypingprototyping

Requirements are unclear

Requirements are unstable

Innovativeness is high

System impact is high on the organization

System impact is high on users

Project size is relatively small Number of users is relatively small

Project duration is relatively short

Commitment of users to a project is required



PrototypingPrototyping Advantages:Advantages:

Early demonstrations of system functionality helpidentify any misunderstandings between developerand client

Client requirements that have been missed areidentified

Difficulties in the interface can be identified

The feasibility and usefulness of the system can betested, even though, by its very nature, theprototype is incomplete


PrototypingPrototyping Problems:Problems:

The client may perceive the prototype as part ofthe final system

The prototype may divert attention fromfunctional to solely interface issues

Prototyping requires significant userinvolvement

Managing the prototyping life cycle requirescareful decision making


12/16

10/26/2009



Spiral Model & Incremental DevelopmentSpiral Model & Incremental Development

Progress towards

final system

Develop first

increment

Develop next

increment

Risk analysis

based on initial

requirements

Planning Risk analysis

User evaluation Software development

Risk analysis

based on user

reaction to plan

Go, no-go decisionRisk assessment

User

evaluation

of

increments

Further planning

based on user

comments

Initial

requirements

gathering and

project planning



Unified Software Development ProcessUnified Software Development Process

Captures many elements of best practice

The phases are: Inception is concerned with determining the scope and

purpose of the project;

Elaboration focuses requirements capture anddetermining the structure of the system;

Construction's main aimis to build the software system;

Transition deals with product installation and rollout.


Size of square

relative to time

spent onworkflows

InceptionInceptionInceptionInception ElaborationElaborationElaborationElaboration ConstructionConstructionConstructionConstruction TransitionTransitionTransitionTransition

Project

Phases

1 2 3 4 5 6 7 8

Iterations within

each phaseRequirementsRequirementsRequirementsRequirements

AnalysisAnalysisAnalysisAnalysis

DesignDesignDesignDesign

ImplementationImplementationImplementationImplementation

TestTestTestTest

Workflows

RUP Process StructureRUP Process Structure EvolutionaryEvolutionarydevelopmentdevelopment



13/16

10/26/2009


ScrumScrumandand AgileAgile methodsmethodsare HOTare HOT

1. Handle changing requirements more efficently

2. Improve communication between customerand project team

3. A new leadership culture, transfering

responsibility from managers to project team

4. Follow footsteps of IBM, Xerox, Motorola,Microsoft


SCRUMSCRUM

ROLES PROCESS

Scrum Team

Product Owner

Scrum Master

Creating a backlog

The sprint phase

Daily scrum

Demonstration andevalution


SCRUMSCRUM -- anan introductionintroduction


0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Day

1Day

2Day

3Day

4Day

5Day

6Day

7Day

8Day

9Day

10Day

11Day

12Day

13Day

14Day

15Day

16Day

17Day

18Day

19Day

20

BudgetEstimated

BurnBurn--down Chartdown Chart

Used to mark day-by-day how much remains of the scheduled work


Planning pokerPlanning poker

I have absolutleyno idea at all

Im to tired to think,lets take a short

brake

Already done orjust a fewminutes


Estimation without planning pokerEstimation without planning poker

14ZZZZz

24

3

How log will thisstory take?



14/16

10/26/2009



?!ZZZZz

?!

3! ?!



3!

4

4

53


Estimation with planning pokerEstimation with planning poker

1418

24

3

Howlog will this storytake?

20





83Richard Carlsson, Jnkping International Business School Richard Carlsson, Jnkping International Business School 84

User InvolvementUser Involvement

Users can be involved at various levels

As part of the development team

Via a consultative approach


15/16

10/26/2009


BPR Business process reBPR Business process re--engineeringengineering

The fundamental rethinking andradical

redesign of business processes to achieve

dramatic improvements in critical,contemporary measures of performance,

such as cost, quality, service, and speed

(Hammer & Champy, 1993)


Reasons toReasons to rere--engineerengineer

They face severe commercial pressures andhave no choice

Competitive forces present problems unless theorganisation takes radical steps to re-alignbusiness processes with strategic positioning

Management in the organisation regard re-engineering as an opportunity to take a leadover the competition

Publicity about BPR has prompted organisationsto follow the lead established by others


OutcomesOutcomes of BPR programmesof BPR programmes

Flatter organisational structures

Greater focus on customers

Improved teamwork, leading to a morewidespread understanding of the roles of others


BPRBPR SSMSSM

BPR = Business Process Re-engineering

Focus on business processes

From the top

Hard facts

SSM = Soft Systems Methodology Focus on soft systems

From the users

Requirements not known by the user


TThreehreelevels oflevels of participationparticipation Consultative participation

Representative participation

Consensus participation


RealRealworld problemsworld problems

Requirements capture

Production of specification

The sign-off

Development

Testing



16/16

10/26/2009

MoSCoWMoSCoWRulesRules

M = Must Haves

S = Should Haves

C = Could Haves

W = Won't Haves


Learning ObjectivesLearning Objectives

How to define an Information System(IS)

The problems in IS development andthe underlying causes of theseproblems

The stages in the waterfall life cycle

Prototyping and incremental lifecycles


?

Documents

1 Systems Development