INFO 503

Introduction to Information Systems Analysis Information Systems Development Fact Finding Techniques

INFO 503 Glenn Booker Lecture #2 1

System Development Life Cycle

• A System Development Life Cycle is the process used for developing a system • A life cycle is a management tool for planning, conducting, and controlling an activity • Software and System life cycles are similar, differing in the details of each activity INFO 503 Lecture #2 2

Methodology

• A methodology, such as FAST, implements a life cycle by defining activities • Each activity has roles and responsibilities, creates work products, and uses tools and techniques – Major recurring theme in the text • Methodology should cover entire life cycle INFO 503 Lecture #2 3

Capability Maturity Model

• Level 1 =

Initial

chaos – no consistent processes • Level 2 =

Repeatable

processes for a project • Level 3 =

Defined

processes across an organization • Level 4 = Quantitatively

Managed

projects • Level 5 = Processes

Optimized

continuously INFO 503 Lecture #2 4

Groundwork

• Any system development should first define its general scope – What kind of product will be created?

– What order of magnitude for time frame and number of resources are available for this effort? (e.g. week, month, year, or $10k, $1M) – What is the current state of similar products?

– What will make this product special?

INFO 503 Lecture #2 5

Ten Principles of System Development

1.

2.

3.

4.

5.

6.

Get the system users involved Use a problem-solving approach Establish phases and activities Document throughout Development Establish standards Manage the Process and Projects 7.

8.

Justify systems as capital investments Don’t be afraid to cancel or revise scope 9.

Divide and conquer 10. Design systems for growth and change INFO 503 Lecture #2 6

1. Get the System Users Involved

• Encourage owners, users, and developers to work cooperatively and collaborate • Get everyone involved in defining requirements and discussing changes • Document decisions well • Education of owners and users can help overcome biases and fears INFO 503 Lecture #2 7

2. Use a Problem-Solving Approach

• The methodology (life cycle) is an approach – Study the problem and its context – Define the requirements of a solution – Identify possible solutions and pick one – Design and implement the solution – Observe the solution’s impact, and refine it • Don’t skip steps!

INFO 503 Lecture #2 8

p. 89 (75)

3. Establish Phases and Activities

• Major FAST phases are: – Scope Definition (led by system owners) – Problem and Requirements Analysis (users) – Logical Design and Decision Analysis (designers) – Physical Design and Integration (builders) – Construction and Testing – Installation and Delivery INFO 503 Lecture #2 9

3. Establish Phases and Activities

• Higher levels are business-driven; lower are technology-driven • Each phase is broken down into activities and tasks to make them manageable • Development is often iterative, with frequent back-tracking to refine requirements and the design • Be sure not to get stuck in iteration!

INFO 503 Lecture #2 10

4. Document throughout Development

• In order for large projects to succeed, programs need to be documented and agreed upon

before

they’re developed • Necessary for coordination across stakeholders, and to leave a comprehensible legacy for maintenance INFO 503 Lecture #2 11

5. Establish Standards

• Standards should be used for both creation of the information system itself, and for the processes used to create the system • Records assumptions and measure progress • May include document style standards, file and variable naming conventions, and file organization conventions… INFO 503 Lecture #2 12

5. Establish Standards

• System development standards may describe, for every phase of the life cycle: – Activities (what happened?) – Responsibilities (who did it and why?) – Documentation requirements (tailor from corporate standard templates) – Quality checks (peer review, defect prevention) INFO 503 Lecture #2 13

6. Manage the Process and Projects

• Deliberate process and project management ensures that your organization 1) has defined processes, and 2) they are actually used, and 3) you can determine how to improve them • Benefits not only this program, but others in the future too INFO 503 Lecture #2 14

7. Justify Systems as Capital Investments

• Information systems often outlive many projects, hence are capital investments • Make sure alternatives are well investigated (do you buy the first house you see?) • Analyze the cost-effectiveness of all major alternatives, including both development and operational costs • Manage risks during development INFO 503 Lecture #2 15

8. Don’t be afraid to Cancel or Revise Scope

• The iterative nature of development makes it tempting to implement a not-good system • Feature and schedule creep can sneak up quietly, one good decision after another • Avoid getting stuck by choosing

creeping commitment

points during development • At each, consider cancellation, projected system cost, schedule, and feature scope INFO 503 Lecture #2 16

9. Divide and Conquer

• Every system is part of a larger system (supersystem) and most contain smaller systems (subsystems) • Interaction with supersystem can change requirements during system development • Defining subsystems can help make project design more manageable INFO 503 Lecture #2 17

10. Design Systems for Growth and Change

• Business needs change over time • During system maintenance (support), maintenance cost grows as the system requirements evolve and hardware wears out; system becomes obsolete • Hence need to design systems so that they can be replaced some day INFO 503 Lecture #2 18

FAST Methodology

• An information system project starts when: –

Problems

keep your organization from reaching its business goals or objectives –

Opportunities

arise when a new capability is identified (e.g. new features) –

Directives

from outside your organization mandate new features or requirements (e.g. laws, regulations) INFO 503 Lecture #2 19

PIECES Review Criteria

Assess new projects for their: • Performance improvement potential • Information or data improvement • Economic or cost improvement • Control or security improvement • Efficiency improvement (people or process) • Service to customer, supplier, staff, etc.

INFO 503 Lecture #2 20

FAST Phases

p. 96 (83) key overview 1. Scope Definition [in 4 th (system owner) Ed.: Survey Phase] 2. Problem Analysis [Study Phase] (analyst) 3. Requirements Analysis [Definition Phase] (analyst) 4. Logical Design [not separate in 4 th Ed.] 5. Decision Analysis [Configuration Phase] (designer) INFO 503 Lecture #2 21

FAST Phases

Procurement Phase [Version 4 separate only; or blend into other phases] (designer) 6. Physical Design & Integration [Design Phase] (designer) 7. Construction & Testing [Construction Phase] (builder) 8. Installation & Delivery [Delivery Phase] (builder) INFO 503 Lecture #2 22

1. Scope Definition

• This is a sanity check to see if the project is worth looking at • If so, define the project team, budget, and schedule (very rough) • Involves sponsors and managers, plus user involvement • Deliver a feasibility study and project plan INFO 503 Lecture #2 23

2. Problem Analysis

• Study existing system (automated or not) for problems and opportunities • Is the new & improved system worth having?

• Run by system analyst, with user and owner involvement • Define system objectives, and success criteria for new system INFO 503 Lecture #2 24

3. Requirements Analysis

• Now define and prioritize detailed system and business requirements • Consider also what it does NOT do • Do NOT describe HOW it does anything • System analyst and many users do this • Create models of data, process, interface, and geography perspectives… INFO 503 Lecture #2 25

3. Requirements Analysis

• Might use prototyping to verify requirements • Present requirements and models in a requirements statement • “Time boxing” is placing requirements into staged deliveries for implementation (hence start to think of priorities) INFO 503 Lecture #2 26

4. Logical Design

• The logical design phase is when various models are developed to describe the logical functions of the system • This typically includes data, process, and/or object models – Beware of getting stuck in

analysis paralysis

INFO 503 Lecture #2 27

5. Decision Analysis

• Identify candidate solutions, analyze them, and recommend the best one • Done by system analyst, with support from all others, and maybe consultants • May start before requirements are done • May include make-or-buy decisions, and define an application architecture… INFO 503 Lecture #2 28

5. Decision Analysis

• Evaluate each solution for technical, operational, economic, and schedule feasibility • Produce a system proposal for owners’ approval • Often includes procurement phase for off-the-shelf applications INFO 503 Lecture #2 29

Procurement Phase

• Major system components are often acquired, not built from scratch • See COTS tool reports (Commercial-Off The-Shelf software) by the SEI, STSC • Vendors “help” system analyst and users • Study existing market & future trends, then generate a RFP or RFI (see References)… INFO 503 Lecture #2 30

Procurement Phase

• Evaluate vendors’ proposals; pick the one that meets requirements and is most cost effective • Negotiate contractual and licensing needs to obtain products, installation, training, etc.

INFO 503 Lecture #2 31

6. Physical Design & Integration

• Turn requirements into plans for the builders, iteratively, until plans are complete (Rapid Application Development) • Analyst and specialists involved • Database, program, human and system interfaces are all designed using iterative prototyping… INFO 503 Lecture #2 32

6. Physical Design & Integration

• Iterate: – Define base system – Define database, load with data, and review with users – Define inputs, and review with users – Define outputs, and review with users – Define interfaces, and review with users – Define other controls, and implement. Repeat.

INFO 503 Lecture #2 33

7. Construction & Testing

• Now build the real system and its interfaces • System builders lead the team • Design specifications are main input • Write code, then conduct unit test, and system test • May deliver system in stages INFO 503 Lecture #2 34

8. Installation & Delivery

• Install new system and place it into operation • May include data conversion and loading to initialize system, and training of end users • Users provide feedback (problem reports) to identify initial support issues INFO 503 Lecture #2 35

System Operation and Maintenance

• While system is in use: – Assist users (help desk) – Fix bugs – Recover system after failures – Adapt to new requirements (implement new features) INFO 503 Lecture #2 36

Cross Life Cycle Activities

• These may overlap many (or all) other phases of development • Fact-finding – Help collect information about systems, requirements, and user preferences; – Most important early in life cycle INFO 503 Lecture #2 37

Cross Life Cycle Activities

• Documentation is generated to record the work accomplished so far, and plan future activities • Presentations are a formal packaging, in writing or orally, of some documentation – “Dog and pony shows” are presentations made to upper management or sponsors INFO 503 Lecture #2 38

Cross Life Cycle Activities

• Estimation and measurement are performed throughout the life cycle (see INFO 630) – Estimation is to predict the amount of time, effort, cost, and benefits of some activity within system development – Measurement is to determine the actual amount of what was estimated – “Earned value” is one way of comparing them INFO 503 Lecture #2 39

Cross Life Cycle Activities

• Feasibility analysis is performed early in a project to determine its potential benefits – Recall mention of technical, operational, economic, and schedule feasibility • Project management is the deliberate planning and control of a project to achieve the desired goal (creation of a product) INFO 503 Lecture #2 40

Cross Life Cycle Activities

• Process management is the conscious definition and management of the processes used to conduct a project, using standards to define typical work products (deliverables) • Data and documents from all phases should be stored, such as in a repository INFO 503 Lecture #2 41

Methodology Options

p. 108 (n/a) • Systems can be build from scratch, purchased off-the-shelf, or some of both • Methodologies can be very rigid (prescriptive), or flexible (adaptive) • Methodologies can be model-driven (draw pictures first, e.g. FAST) or product-driven (build something and see if it works) INFO 503 Lecture #2 42

Model-Driven Development

• Most methods for analysis and design focus on using models to capture thoughts – Structured analysis focuses on processes, such as the data flow diagram – Information engineering focuses on data, such as the entity relationship diagram – Object oriented analysis and design blend data and process into objects INFO 503 Lecture #2 43

RAD and COTS

• Rapid Application Development (RAD) focuses on iterative development of prototypes with lots of user input – Often uses time boxing to limit the effort on each iteration • Commercial Off The Shelf (COTS) products can be used as the entire system, or significant portions of a developed one INFO 503 Lecture #2 44

CASE Tools

• Computer Assisted Software Engineering (or Systems Engineering) tools use an information system (customized database) which is devoted to managing a system development effort • CASE tools may include compilers, design and diagram tools, quality and document management tools, and generate code INFO 503 Lecture #2 45

CASE Tools

• Upper CASE Tools focus on early development activities – requirements and high level design phases; may also be able to reverse engineer code • Lower CASE Tools focus on (you guessed it!) later development activities – detailed design, construction (coding), implementation, and perhaps support INFO 503 Lecture #2 46

CASE and ADE Tools

• CASE Tools are noted for pretty graphical capabilities - diagrams, flow charts, etc.

– They store projects in repositories – Price is high in both $$$ and learning curve • Compilers have evolved into Application (or Integrated) Development Environments (ADE or IDE) – may include debuggers and interface tools, testing and version control INFO 503 Lecture #2 47

Fact Finding and Information Gathering

• Fact finding is the formal process of using various techniques to collect information about system requirements and user preferences • Facts are the basis for modeling • Conclusions about the system are also drawn from these facts • So facts are, like, really important :) INFO 503 Lecture #2 48

Fact Finding and Information Gathering

• Fact finding is most important during the planning and analysis phases, but still useful during the rest of the life cycle • Seven techniques to choose from; often use several on any given project • Fact finding may also discover business rules – how does the system need to respond under different conditions?

INFO 503 Lecture #2 49

Requirements

See also INFO627

• Fact finding may give info at various levels of detail, depending on the audience –

Requirements

capture what and/or how the system needs to be able to support its users – A requirement is more precise than a user

need

, but more vague than a

specification

• Defining requirements is a key output from fact finding and information gathering INFO 503 Lecture #2 50

Requirements

• A Need defines the basis for requirements, such as “the system must support 20 simultaneous users” • A Requirement defines what capability the system must fulfill to meet the need, “the system must handle 1000 tps from 20 simultaneous users” • A Specification defines how to measure the requirement, such as the protocol or test conditions to be used INFO 503 tps = transactions per second Lecture #2 51

Requirements

• Many requirements are functional – they describe

what

the system can do • Non-functional requirements describe

how

the system performs the functional req’ts – Performance, cost, control (security), efficiency (resource usage), and the “ilities” (reliability, availability, maintainability, usability, etc.) INFO 503 Lecture #2 52

Fact Finding and Information Gathering

p. 243 (623) • Techniques are: – Sampling – Research and Site Visits – Observation of the Work Environment – Questionnaires – Interviews – Prototyping INFO 503 Lecture #2 53

Sampling

• Works well for study of an existing system • Comes before interviews; may include: – Look for organization chart – Investigate project history – Look for high level mission or policies – Charters for each organization affected – Processes and procedures in use INFO 503 Lecture #2 54

Sampling

• And study existing system documents – Inputs – Outputs – Program documentation – Data dictionaries – User and maintenance manuals INFO 503 Lecture #2 55

Sampling

• If you know a lot about the consistency of data, can use statistical sampling techniques • A

random sample

should be truly random, not just convenient • A

stratified sample

may be used to avoid important special cases

See also INFO 630

Lecture #2 INFO 503 56

Research and Site Visits

• Research may use various sources, such as: – The Internet (e.g. for vendors) – Trade and professional journals (AITP, AIS, IEEE, ACM, etc.) – Company-specific intranets – Government agencies (SEI, STSC, etc.) • Site visits are to see the existing system INFO 503 Lecture #2 57

Observation of the Work Environment

• Participate in, or watch the existing system being used • Should determine what kind of data to collect, when, and how (what forms) • Should already understand the process being observed somewhat • Can use sampling for large numbers of observations INFO 503 Lecture #2 58

Observation of the Work Environment

• Determine who, what, where, why, and how • Obtain permission from supervisor • Inform subject of reason for visit • Keep a low profile; don’t interrupt • Take copious notes, and review them • Focus on important activities • Don’t make assumptions INFO 503 Lecture #2 59

Questionnaires

• Can be efficient for large audiences • But hard to guarantee responses, or fairness • Can use free format, but hard to analyze • Fixed format may include: – Multiple choice (Y/N or A/B/C/..) – Rating (5-point from strongly agree to strongly disagree) – Ranking (importance, or % or time) INFO 503 Lecture #2 60

Interviews

• Provide more personal information about body language, inflection, tone, etc.

• Take a lot more time, but are often liked • Can be structured or unstructured (rare) • Structured tend to use open-ended questions rather than closed-ended ones (yes/no) • Need to be well prepared, take good notes INFO 503 Lecture #2 61

Prototyping

• Prototyping, or discovery prototyping, tends to use very specialized tools, and may define and refine prototypes with direct user involvement – Can be part of a RAD development approach – Highly iterative; helps clarify requirements – Easy to omit quality and performance req’ts INFO 503 Lecture #2 62

Ethics

• Many professional organizations, such as the AITP , IEEE , the Computer Ethics Institute , and ACM have defined standards of professional conduct • Such standards should be used for guidance when dealing with information which may be sensitive, such as pricing structure, profit data, or employee personal data INFO 503 Lecture #2 63