A U Introduction Prof. J. Alberto Espinosa Business Analysis & Data Design ITEC-630 Fall 2008.

AUIntroduction

Prof. J. Alberto Espinosa

Business Analysis &Data Design

ITEC-630 Fall 2008

2

Textbooks

Required:

Advanced Use Case ModelingFrank Armour and Granville MillerAddison Wesley, ISBN 0201615924

Optional but highly recommended:

Modern Database Management, Hoffer, Prescott and McFadden, 8th edition, Prentice Hall, ISBN 0132212110

3

My Background• Started as New faculty at AU in Fall’02

• Previously at Carnegie Mellon University

• PhD and MS in IS from Carnegie Mellon

• Also, BS Mech Engineering & MBA

• Over 18 years of working experience

• Mostly implementing and managing systems

• And in management

• Specialty: systems implementation and database

• Mostly in international/global contexts

• Teach: MIS, Systems Analysis, Database

• Research focus: • IT support for global & geographically distributed collaboration

• Most recently: team coordination across time zones

4

Contact

• Office: KSB 33

• Office Hours: Mo 1:30 – 5 PM Th 1:30 – 4 PM

• Office Tel: 202-885-1958

• Fax: 202-885-1992

• E-mail: [email protected]

5

Class Web Site

• Current versions of syllabus, class schedule, lecture notes, and homework assignments will be posted on the Blackboard class web site.

• Course Syllabus also available at:http://auapps.american.edu/~alberto/itec630/syllabus.html

• Class Schedule also available at:http://auapps.american.edu/~alberto/itec630/schedule.html

• All homework assignments, lecture slides, and other class materials will be available via the Class Schedule link above, and also via Blackboard

• Class announcements and grades will be available via Blackboard only

6

Business Analysis

7

What is business analysis?

“The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.”

Source: International Institute of Business Analysis (iiBA)

8

About the BusinessAnalysis Profession

• Business analysts used to be called “systems analysts”

• Business analyst is the preferred title today in recognition of the fact that business strategies and system implementations need to be tightly aligned, so the analyst needs to thoroughly understand business goals, functions and processes, more than systems per se (CIO Magazine)

• A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems (iiBA)

• The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals (iiBA)

9

Business Analysis Skills

Ability to develop a thorough understanding of:

• the requirements to solve a business problem, often with a system implementation

• how the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate.

• how the proposed system or solution fits the existing enterprise architecture and business strategies

• the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.

10

Business Data Design

11

About Business Data Design

• Solutions to business problems often involve managing and processing business data into useful information

• Important business data design skills – ability to:o Discover data objects that need to be collected and their data elementso Design the most appropriate structure or schema for the datao Design the most appropriate relationships among data objectso Describe the data accurately with appropriate models for implementation

Design Goals -- data collected: is consistent with the business requirements and enterprise architecture; is correct and accurate; has integrity, both within each data object and in how it relates to other objects; and has no redundancy that could cause inconsistent information

o Discovering the queries necessary to support the creation, retrieval, and manipulation of data for the business application being implemented

• There more than one paradigm for data design: relational database model, object oriented databases, object-relational, etc.

12

The Context of Business Analysis and

Data Design:System Development

Methods

13

What is Information Technology (IT) for Business?

=

IT Infrastructure: the hardware, system software, telecommunications/networks and data storage

supporting all business applications

+

Business Applications: software used to manage particular business functions or processes (e.g.,

accounting, supply chain management)

14

What is an Information System (IS) for Business?

An arrangement of people, business functions, processes, and IT that interact to collect, store

and process, and store data to provide information to support business activities and

processes –

It is more than just IT!!

15

Information Systems

IT Infrastructure(HW, System SW, database, telecom)

IT for Business

BusinessApplications

(ERP, CRM, SCM, Financial Appl, etc.)

People,Processes& Business Functions

+ +

IS =

Business Value !!

16

Information Technology (IT) and Business

Business WorldTransactions

Transaction ProcessingB

usi

nes

sA

ppl

ica

tion

sIT

Infr

ast

ruct

ure

Database

Mainframes

InformationDecision SupportDistributed CollaborationEnterprise CollaborationFinancial Management

etc.

ERP, SCM, CRM, etc.

Microcomputers

(Local/Wide area) Networks

Client Appl

ServerAppl

Client/Server Computing

Distributed Computing

DB DB

Ubiquitous Computing

Security,Firewalls

Inter-Networking (Internet, Intranets)

Virtual Private Networks

Routers

ITEC630

17

Requirements for a Cool House:(first meeting with the client:

a very high level description of the house)

• 3 bedrooms, dinning room, living room, kitchen, laundry room, 2-1/2 bathrooms

• Back patio, access from the kitchen• 2-floors + basement• 2-car attached garage w/extra room on top & driveway• Landscaped front yard & small trees in the backyard• 2 windows, one on each side of front door• 2 windows on 2nd floor above with 1st floor windows• 2 small windows above garage on extra room

18

A Cool House: A Sketch (a visual representation to discuss w/client)

19

A Cool House: A Scale Drawing (a more detailed representation to discuss w/client)

20

A Cool House: The Blueprints(very specific dimensions to discuss w/client and

then give to builders for construction: i.e., communicating client requirements)

21

SYSTEM DEVELOPMENT

All the activities that go into producing and IS solution:

0. Vision1. Analysis2. Design3. Implementation4. Testing5. Conversion6. Production & Maintenance

Degree of ceremony or formality?Depends on size, risk,

ITEC630

22

1. Analysis

A communication exercise between system users and system developers

An analysis of the “problems” to be solved by an information system

Developing an understanding of “the work” that the system needs to perform

Developing an understanding of “what” the system needs to do

23

Analysis Involves:

Feasibility Analysis: • System concept, project blastoff• Technical, economical & operational feasibility

Risk Analysis:• Identifying (technical, project & business) threats to the viability of

the system and the probability that they materialize• Affected by system size, business impact, customer characteristics,

software process maturity, development environment, technological complexities, development staff experience, etc.

Requirements Analysis:

Understanding the work that the system needs to do and, the qualities the system must have

ITEC630

24

Requirements Analysis

• Functional (Behavioral) Requirements – what the system needs to do: “The work”

• Non-functional Requirements – the qualities of the system (e.g., speed, reliability, capacity)

• Project requirements – costs, deliverables, deadlines

• Described in the

“System Requirements Specification”

25

Why is requirements analysis so important?

The cost of fixing and error in requirements is:

Times larger If discovered during

5 Design

10 Implementation

20 Testing

100 Operations

Bohem, Barry R. 1981. Software engineering economics. Englewood Cliffs, N.J.: Prentice-Hall.

Errors Propagate and Grow

correctrequirements

wrongrequirements

correctdesign

design based onwrong requirements

wrongdesign

problem

code based onwrong designs

correctcode

wrongcode

code based onwrong requirements

27

2. Design

An analysis of the “solutions” to the problems identified during systems analysis

Developing and understanding of “how” the system needs to do what was identified during systems analysis, per the “requirements specification”

ITEC 630: Business Data Design and Basic Introduction to Interface Design

ITEC630

28

3. Implementation

Selection, acquisition, production and assembly/integration of the necessary components of the system

For systems that require software development, translating the conceptual design into specific software instructions to accomplish the work.

29

4. Testing

Ensuring that the system performs as required

Test types:

• UNIT TESTING: Ensure that each part of the system work well individually

• SYSTEM TESTING: Ensure that all the parts work well together

• REGRESSION TESTING: Ensure that new software work well with the existing software

• ACCEPTANCE TESTING: By users and/or clients

Methods:

• BLACK BOX TESTING: Testing if the system does what is supposed to, per requirements specifications, without inspecting the internals of the system

• CLEAR BOX TESTING: Inspecting and testing the internals of the system (opening the black box)

ITEC630

(Test Cases)

30

5. Conversion (i.e., Installation)

Important Issues:• CONVERSION PLAN: Schedule for conversion• DOCUMENTATION: Description of how system works• USER TRAINING

Conversion Methods:• PARALLEL: Old & new run same problems. Give same

results?• DIRECT CUTOVER: Risky conversion to new system• PILOT: Introduce into one area. Does it work? Yes:

introduce into other area• PHASED: Implement the system in stages

31

6. Production & Maintenance

• PRODUCTION: Review by users & operatorsUser support

• MAINTENANCE: Upgrades

Bug fixes

32

Brooks, 1994 (IBM O/S 360)

33%

17%17%

33%

EFFORT DISTRIBUTION

Systems Analysis & Design

Maintenance

Testing & Integration Implementation

33

Systems Development Models

• Linear Sequential ModelsSystem development progresses in a straight line fashion

• Evolutionary ModelsSystem development is done in iterations

34

System Development Life Cycle (SDLC)or the “Waterfall” Model (Linear Sequential)

Systems Analysis

Design

Implementation

Testing and Conversion

Production & Maintenance

35

SDLC (“Waterfall”) Model Pros & Cons

Pros:• Oldest and most widely used model• Life cycle concept is very useful• OK when requirements are certain and stable

Cons:• Early errors detected late are very costly• Not very useful when requirements are uncertain• Many real projects rarely follow a sequential flow• Often difficult to know all requirements early on• Programmers have to wait until the whole design is finished

36

The Incremental Model(Linear Sequential)

Analysis

Design

Programming

Testing,etc.

Core Product

Analysis

Design

Programming

Testing,etc.

Analysis

Design

Programming

Testing,etc.

Increment 1

Increment 2

Etc.

Integration +Regression Testing

37

Incremental Model Pros & Cons

Pros:• Core functionality can be provided quickly• Increments can be planned to manage technical risks

(e.g., increment, evaluate, increment, evaluate, etc.)

Cons:• Takes a long time to finish entire system• Later increments may never get done

38

The Prototyping Model (Evolutionary)

Identify Requirements

Develop Prototype

Install and Use

User satisfied ?

No

Feedback

Refine Requirements

Develop Full System

Yes

39

Prototyping Model Pros & Cons

Pros:• Good when input/output requirements and user interface

not clear initially• Good for development of “visible” parts of the system• Fosters communication with customers and users• Helps identify and refine requirements

Cons:• False expectations: customer sees what appears to be a

working product• Not good for “invisible” aspects of system• Early unfinished prototypes may perpetuate themselves

40

The Spiral Model (Bohem)(Evolutionary)

Planning

Engineering (Analysis &

Design)

Construction (Implementation)

Testing & Release

(Conversion)

Customer Communication

& Evaluation(Business

Requirements)

RiskAnalysis

41

The Spiral Model

Pros:• Each loop allows the team to assess risks and

adjust the plan• More realistic approach for large projects• Conceptually sound idea

Cons:• Not many – the basic concept is widely adopted• Is the foundation for the Unified Process (UP)

42

Object-Oriented (OO) Analysis

• Most prevalent software system development paradigm today

• In which a system is conceptualized by discovering physical objects that the system needs to represent – e.g., customers, locations, students, classrooms, invoices, etc.)

• And discovering their attributes (i.e., data elements – e.g., name, SSN, etc.) and behaviors (i.e., programs – e.g., place an order)

• More on OO later in the course

43

Standards

Standards are necessary when many people are involved in a system development effort.

There are many types of standards, but two very important ones are standards about: (1) notation and (2) process

• A notation (i.e., a language) is necessary to describe the system. Standard notations describe the symbols to use in models and other analysis artifacts. We will use the UML (Unified Modeling Language)

• A process is necessary to define the sequence of activities that will be undertaken to gather requirements and then design and implement the system: We will use the UP (Unified Process)

44

Unified Modeling Language (UML)

• UML a standard for notations and methods to express OOA/D• UML is the most widely adopted standard diagramming notation to describe

systems today• Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to unify

their individual (most widely used) notationsSee Object Mgt Group site: http://www.omg.org/

• Main purpose of the UML: communication!!• It is intended for OO Analysis and Design (OOA/D)• You can do OOA/D without UML using other notations• Similarly, you can use aspects of UML for non OOA/D• UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2

For more info on UML and versions, see: http://www.kobryn.com/

45

Important UML Models

• Use Cases – a set of scenarios of system uses, each tied together by a common user goal

• Activity Diagrams – diagrams that explain use case workflows (sometimes useful, but use case text is often preferred)

• Class Diagrams – describes the types of objects in a system and the static relationships among them

• Domain Model – like a class diagram (and/or other models), but it only shows noteworthy objects and elements, used to provide a conceptual skeleton view of the system

• Interaction Diagrams – models that describe how groups of objects collaborate

• Class-Responsibility-Collaboration (CRC) Cards – text version of interaction diagrams, not part of UML but often used with UML

• State Diagrams – models that describe possible states of objects and how the object’s state changes with events (e.g., order status)

46

The Unified [System Development] Process (UP)

• A system development process defines the activities undertaken to building, deploy, and maintain systems

• UP: a popular SW development process used with OO methods

• UP was also developed by the “Three Amigos”• UML and UP are independent – you can use UML without

UP, or UP without UML, but they were both conceptualize to work together

• Rational UP (RUP): a refinement of the UP formulated by the “Rational Corporation” now owned by IBM, widely adopted today.See: http://www.rational.com/

47

Key Aspects of the UP

• Iterations: “timeboxed” – i.e., of fixed time length of 2-6 weeks – date slippage is discouraged – removing tasks or requirements from the iteration is preferred

• Workshops: each iteration begins with at 1-2 day workshop to discuss the scope of the iteration and plan accordingly.

• 4 Phases: inception, elaboration, construction and transition – this course deals with the inception and elaboration phases

• Disciplines (originally called “workflows” until 2001): a set of related system development activities (e.g., analysis, design, etc. – note: these are considered “phases” in the Waterfall model)

• Artifacts: working products such as code, database schemas, text documents, diagrams, models, etc.

• Development Case: articulates upfront which artifacts (not all artifacts need to be employed) will be used in the particular development project

48

Iterations, Disciplines & Workflows in the UP

Incep Elab 1 Elab 2 etc.

Source: Larman book ch.2, p.21

49

Development CaseFor this Course

Discipline UP ArtifactIncept

I1Elab

E1..EnConstrC1..Cn

TransT1..Tn

Business Modeling Domain Model S

Analysis

Vision S R

Use Case Model S R

Supplementary Spec S R

Glossary S R

Design

Design Model S R

SW Architecture Doc S

Data Model S R

ImplementationImplementation Model S R R

SW Development Plan S R R R

Testing Test Model S R

Dev Environment Development Case S R

S – Start; R – Refine

50

Important Things to Keep in Mind

• Ceremony or Formality: o High ceremony: lots of formal deliverables, meetings, etc.o How much? it depends

• The right process? it varies for each company• Requirements and Design = communication exercises• No need to use all diagrams or artifacts• No need to note everything, only what is noteworthy• Avoid overdoing requirements (i.e., analysis paralysis):

keep it simple, but accurate

Let’s look at the Class Schedule once again

Let’s look at the Final Project