James Nowotarski 8 May 2008 IS 425 Enterprise Information Spring 2008

James Nowotarski

8 May 2008

IS 425Enterprise Information

Spring 2008

2

Topic Duration

Recap of 5/1 45 minutes

Security and risk 30 minutes

*** Break 15 minutes

Security and risk (cont.) 30 minutes

eCommerce 60 minutes

Wrap-up 10 minutes

Today’s Agenda

3

Systems development life cycle (SDLC)

Planning Modeling Construction Deployment

Example

Core Concepts

4

The waterfall model is the granddaddy of life cycle models

Core Concepts

Planning

Modeling

Construction

Deployment

5

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Source: Royce, W. (1970, August). Managing the development of large software systems. IEEE Proceedings, WESCON, 1-9.

Waterfall model

6

Protracted integration and late breakage

Conventional application of the waterfall model typically results in late integration and performance showstoppers

Dev

elop

men

t p

rogr

ess

(% c

oded

)

100%Late designbreakage

Original target date

Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).

Integrationbegins

What’s wrong with waterfall?

7

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

8

Incremental life cycle models advocate delivering the end product piecemeal

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

9Copyright © 1997 by Rational Software Corporation

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

Risk Profile: Iterative vs. Waterfall

Iterative

10

Rational Unified Process (RUP)

11

Each Iteration is a mini-waterfall

R

A&D

C

T

R

A&D

C

T

R

A&D

C

T

13

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

14

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

15

Agile/Light/Lean Methods

“We have come to value: Individuals and interactions over processes and tools Working software over comprehensive

documentation Customer collaboration over contract negotiation Responding to change over following a plan”

16

Agile methods wind the RUP model more tightly

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Each day on an Agile project

FunctioningCode

17

Approach References

XP www.extremeprogramming.org

www.xprogramming.com

M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002.

Crystal A. Cockburn, Agile Software Development, Addison-Wesley, 2001

SCRUM K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.

Adaptive Software Development

J. Highsmith, Adaptive Software Development, Dorset House, 2000.

FDD S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002.

Agile - General http://www.agilealliance.org/home

http://www.agilemodeling.com

Agile/Light/Lean Methods

18

Key Practices – Agile Methods

Customer on-site as integral part of team Short iterations, small releases

2 month releases, 2 week iterations Refactoring and evolutionary design Test all the time Pair programming (XP) 40-hour week (XP)

19

Iterative/Agile Guiding Principles

QualityCustomerValue

Attack riskAccommodatechange

Work togetherExecutablesoftware

Architecturebaseline

Component-baseddevelopment

Objectives

Strategies

Tactics

IterativeDevelopment

20







Objectives

Strategies

Tactics


21

Why focus on change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

22

Change curve – Agile methods

Time

Co

st

of

ch

an

ge

Agile methods purport to change the curve so that the cost to find and repair software problems does not rise dramatically over time

23








Objectives

Strategies

Tactics


24

Why emphasis on executable software?

“Without this first pass, the project manager is at the mercy of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic”

Source: Royce, W. (1970, August). Managing the development of large software systems. IEEE Proceedings, WESCON, 1-9.

25

Who is Fritz Bauer?

• Chairman of 1968 NATO Software Engineering Conference

• Credited with coining the term “software engineering”

26

Software Engineering

• The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines (Fritz Bauer, 1969)

Core Concepts

27

RUP Guiding Principles







Objectives

Strategies

Tactics


28

Architecture

arch·i·tec·ture n. The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Source: IEEE

29

Software architecture is a level of design that “involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns.”

What is software architecture?

Shaw, M., Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. Upper Saddle River, NJ: Prentice-Hall.

30

Software architecture

Applications and Data

Middleware

Hardware/Network

System Software

• Presentation layer• Application logic• Data management

31

Key principles of architectural design

Abstraction Modularity Reuse

32

Abstraction

There is a limit to the number of ideas you can comprehend at any one time 7 +/- 2

Raise the level of detail by creating relationshipsExample: Grouping

Think in logical instead of physical terms

33

Grouping: What’s easier to understand and retain?

Grapes Oranges

Milk Butter

Potatoes Apples

Eggs Sour cream

Carrots

Milk

Dairy Fruit Vegetable

ButterEggs

Sour cream

Logical vs. Physical

34

Businessproblem

IT-enabledsolution

AnalysisLogicalDesign

PhysicalDesign

BuildTest Deploy

Magic!!!

35

Entity relationship diagram (ERD)

36

Think in logical instead of physical terms

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

Big idea: As a prelude to creating a design, represent the basic computational requirement for the system to be designed in more abstract terms, i.e., in terms of data flow

37

SafeHome Security: State Transition Diagram

Resetting

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Starting system”Entry/set displayMsg2 “Please wait”Entry/set displayStatus showBlinkingDo: run diagnostics

Idle

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Ready”Entry/set displayMsg2 “”Entry/set displayStatus steadykeyHit/handleKey

ActingOnAlarm

Entry/set systemStatus “monitorAndAlarm”Entry/set displayMsg1 “ALARM”Entry/set displayMsg2 triggeringSensor Entry/set displayStatus fastBlinkingDo: soundAlarmDo: notifyAlarmResponderskeyHit/handleKey

MonitoringSystemStatus

Entry/set systemStatus “monitoring”Entry/set displayMsg1 “Armed”Entry/set displayMsg2 “”Entry/set displayStatus steadyDo: monitorAndControlSystemKeyHit/handleKey

Start/ stop switch power “on”

failureDetected / set displayMsg2 “contact Vendor”

SystemOK

Reset

Activate

deactivatePassword

falseAlarm

timeOut

sensorTriggered/startTimer

sensorTriggered/restartTimer

deactivate Password

off/powerOff

38

Students at a university

Inquiry Lead Applicant

Admitted

Rejected

Withdrawn

Enrolled Matriculated Graduated

Drop Out

39

Modular design Reduces complexity Facilitates change Results in easier implementation by supporting parallel

development of different parts of the system.

Information hiding

Functional independence

Objectives: High cohesion, low coupling

Modularity

40

Call and return

PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax)

GET_DATA

employee_data

CALC_SALARY

employee_ data

salary

CALC_TAX

salary

tax

PRINT_CHECK

employee_data

salary

tax

41

CohesionA measure of the relative functional strength of a module

Cohesion and coupling

Func A-1

Func A-2

Func A-3

Func B-1

Func B-2

Func B-3

High Cohesion (good)

CouplingA measure of the relative interdependence among modules

High coupling (bad)

42

Topic Duration






Wrap-up 10 minutes

Today’s Agenda

43

Security is a pervasive thread throughout the SDLC

Planning

se

cu

rity

Analysis Design Implementation

Security terminology

Backup Controls Decryption/Encryption Exposure Fault tolerance Integrity (of data) Threats (or hazards) Risk Vulnerability

44

Types of threats

ThreatsUnintentionalIntentional

• Attack• Data tampering• Programming fraud

45

Controls address threats

Prevention and deterrence Detection Limitation Recovery Correction

46

Types of controls

General controlsPhysicalAccessData securityCommunication networkAdministrative

47

48

“The basic problem of software development is risk”

Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley

Risk management

49

Risk management process

Identify Analyze Plan

Cost of protection Cost of exposure

$$ $$

Control

Chief Information Security Officer

Audits &Controls

Management

RoleManagement,

Security Access Design

SecurityGovernance,

Risk Managementand

BusinessContinuity

InformationSecurity

Research

Threat andVulnerability

Services

SecurityManagers byGeography

EMEA

Asia Pacific

Americas

Security & Controls

Information Systems IS 425

DePaul University

51

Information Security - Today

The Facts– Vulnerability – Increasing points and modes

of attack – Threat – Increasing attackers and

incidents– Risk – Increasing value available for

compromise

The Result– Time stolen by security measures is increasing– Money invested in security measures is increasing– Effectiveness and life-cycle of security measures are

decreasing


DePaul University

52

Contents

What is information risk (i-risk) Why is i-risk management important How do you assess

i-risk How do you manage

i-risk What this means to you


DePaul University

53

Information risk is the chance or possibility of harm

being caused to a business as a result of a loss of the

confidentiality, integrity or availability of information

Definition: Information Risk

Likelihood of suffering harmNature and level of harm

The 3 key properties of information to be protected

Exists in varying forms: held in people’s heads communicated face-to-

face recorded in deeds and

other securities entered into, stored,

processed, transmitted and presented via IT


DePaul University

54

I-Risk Impacts Other Business Risk

Borrowings and investment positions

Projected rates of interest Projected cash flows External developments

Sales forecasts Forecast

expenditure Actual sales and

expenditure Key variances

Information risk status reports

Identity of key assets (equipment, facilities and employees)

Status of continuity arrangements

Market riskMarket risk (factors beyond the control

of management such as interest and currency rates)

Financial riskFinancial risk (uncertainties about projected earnings or

expenditure)

Operational riskOperational risk (information riskinformation risk, theft, fraud, loss of facilities or

key employees)

Information risk Information risk is an increasingly important

component of operational risk

Information risk

intensifies all other

business risks

Sound information is needed to manage each category of risk. Thus, managing information risk well is essential.


DePaul University

55

The Chance of Incidents Is High

100%

0%

25%

75%

50%

400

0

100

300

200

Business applications

(260)

Communications networks

(159)

Computer installations

(247)

Systems development

activities (115)

Overall average

(781)

52%

147

56%

276

58%

334

55%

88

55%220

Average no. of incidents suffered over a year per information resource

Percentage of information resources that suffered a MAJOR incident

Collectively known as

information resources

Information incidents are a feature of day-to-day business life, and there’s a high chance of suffering a MAJOR incident


DePaul University

56

Why is I-Risk Important?

Information risk is– One of the most important and fastest growing components of business risk – Required for good corporate governance

Because information risk is not well understood or managed – A business-critical information resource has a 50% chance of experiencing a

MAJOR incident over the course of a year– Minor incidents are accepted as a part of day-to-day business life

Incidents sap an organization’s energy, compromise service targets, erode profitability, and can seriously harm an organization’s reputation


DePaul University

57

Definition: Risk Management

Risk management is a process to identify, measure, control, and minimize or eliminate the likelihood of an incident

Risk management must strike a balance between the impact of risks and the cost of protective measures

Identify Evaluate Act

Identify different types of risk that affect

Evaluate their relative significance

Initiate action to keep risks within acceptable levels


DePaul University

58

Definition: Risk Assessment

A risk assessment identifies different types of risk to Organization information resources and evaluates their relative significance

Info Resource’s Importance

Control Weaknesses

Information Resource(Application, Computer, Network)

Criticality

Vulnerabilities

Threats

Business Impact

History of Past Incidents

Magnitude of Incident’s Harm


DePaul University

59

Driving Down Risk

Based on a risk assessment, to drive down risk

– Strengthen existing controlsor implement new controls

– Increase user education– Add layers of physical and

information security– Implement or revise business

processes– Implement or revise policies

and standards– Add resources– Make contingency arrangements

Paring SOX Down to Size: The Impact of Sarbanes-Oxley on IT Governance


DePaul University

61

• What does it require, why and who cares?• State of the market

• Investments and Organization• Building a Defensible Compliance Strategy• Recommendations

“We did not formally build a compliance architecture. It just sort of happened.”

What is SOX


DePaul University

62

The Sarbanes-Oxley Act of 2002

• Increasing responsibilities and liabilities for:

• CEOs, CFOs, Ind. Auditors, Boards/Committees

• Internal Controls

• Adequacy

• Changes

• Auditors and management

• Must report & attest to accuracy of financial statements and disclosures


DePaul University

63

The Sarbanes-Oxley Act of 2002

• Applies to US public companies, private companies with public debt and accounting firms

• Does not exempt foreign private firms or non-U.S. public accounting firms

• Driven by the Enron, Tyco and WorldCom fiascos • SOX has sections covering

– Reporting – improves disclosure requirements

– Roles – strengthens corporate governance

– Conduct – expands on accountability

– Enforcement – improves oversight

– Penalties – broadens sanctions

– Relationships – forces auditor independence


DePaul University

64

Why is it a Big Deal for IT?

• Lack of comprehensive documentation of existing internal controls at most firms

• No comprehensive evaluation of internal controls by the majority of firms

• SOX often has to be fit into on-going development activities

• Limited resources available

• 1 in 10 companies have made financial restatements in the past five years (U.S. GAO study)


DePaul University

65

What the Fortune 50 are Saying

• “Our controller’s department has direct responsibility for Sarbanes-Oxley implementation. We have a program team with finance devoted to this today.”

• “We are still trying to put together a plan of what should be the overall governance of all IT systems. We want to use the structure we have put in place for Sarbanes-Oxley to be used for other compliance initiatives.”

• “Our success in working through activities the first time has depended on buy in from the CEO and CFO.”

• “The IT compliance manager and internal audit are joined at the hip and coordinate all activities together.”


DePaul University

66

Big IT Impact Anticipated


DePaul University

67

People, Processes and Systems will be Impacted


DePaul University

68

Which Provisions Apply to IT?

• 302 – Corporate responsibility for financial reporting

• Is our financial data accurate?

• Do we have transaction level detail if required?

• Do we understand all the processes involved?

• 404 – Annual mgmt assessment of internal controls

• How does our control structure operate?

• Who is accountable?

• Is it monitored?

• Is it documented?

• 409 – Real-time disclosure of material changes

• 802 – Retention of relevant records for audits/reviews


DePaul University

69

Emerging IT Requirements/Impact

• Definitely influence, perhaps certify…

– Anti-fraud techniques – development & operations – Change management process– Data integrity– Disaster recovery practices– Electronic records retention policy

– “properly recorded and reported” transactions– “reasonable assurance” test

– Integrity of communications– Patch management – Process/work flows – internal & partners– Security policies and practices

– SOX compliance built into overall security architecture


DePaul University

70

30% 30%

20% 20%

1 2 3 4

What is SOX’s impact on IT?

1. Minimal

2. Some impact

3. Big impact

4. Impacts most of development and operations


DePaul University

71

Key Organizational Issues

• The Sarbanes-Oxley Act of 2002 has brought companies to focus on a more centralized way to address governance and compliance.

• Centralized authority usually resides in finance or an audit group for assuring overall regulatory compliance. IT compliance is treated as an operational consideration and is usually handled by an IT compliance officer or an IT compliance committee.

• Companies normally have a compliance committee that consists of members from IT, finance and lines of business (LOBs). The committee facilitates constant and clear communications among the member participant departments.


DePaul University

72

1. Companies not focusing on technology fixes - instead auditing, procedures and reporting. Most not buying new technology to solve, but may upgrade or partially replace to address. Most drive to 90%+.

2. Split on whether finance understands technology issues involved in SOX compliance, and whether IT understands the business issues

3. IT will be affected by SOX, more so than all other departments except finance. Most viewed SOX compliance more resource intensive than other regulatory compliance projects.

4. Confident that 404 requirements will be met.

5. Almost 1 in 10 think their job is at risk if the firm is non-compliant and 1 in 4 must certify results personally.

6. Successful companies have strong support by CxO management in driving compliance activities across the organization. It was not just the role of the CIO.

Key Findings of Recent Research

73

Topic Duration






Wrap-up 10 minutes

Today’s Agenda

74

eCommerce

eBusiness

75

What is eCommerce?

eCommerce

Marketing, buying, and selling . . .

. . . of goods and services . . .

. . . over the Internet

76

What is eBusiness?

eBusiness

Conducting of business . . .

. . . over the Internet

77

eBusiness Models

Business to Business (B2B) Business to Consumer (B2C) Consumer to Business (C2B) Consumer to Consumer (C2C) Business to Employee (B2E) Etc.

Our focus

eBusiness “value chain”

Attract Interact Act React

• •

• •

• •

• •

79

How can IT enable?

Attract Interact Act React

B2C

B2B

Information commerce

1 2

3 4

5 6

80

eBusiness Processes

81

Readings on architecture DL: Discussion on Business intelligence

(due May 22)

For May 15

82

Extra slides

Documents

James Nowotarski 8 May 2008 IS 425 Enterprise Information Spring 2008