INFO 503 Glenn Booker

INFO 503 Lecture #2 1

Introduction to InformationSystems Analysis

Information Systems DevelopmentFact Finding Techniques

INFO 503

Glenn Booker


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


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


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


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?


Ten Principles of System Development

1. Get the system users involved2. Use a problem-solving approach3. Establish phases and activities4. Document throughout Development5. Establish standards6. Manage the Process and Projects7. Justify systems as capital investments8. Don’t be afraid to cancel or revise scope9. Divide and conquer10. Design systems for growth and change


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


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!


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

p. 89 (75)


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!


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


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…


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)


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


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


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


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


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


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)


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.


FAST Phases

1. Scope Definition [in 4th Ed.: Survey Phase] (system owner)

2. Problem Analysis [Study Phase] (analyst)3. Requirements Analysis [Definition

Phase] (analyst)4. Logical Design [not separate in 4th Ed.]

5. Decision Analysis [Configuration Phase] (designer)

p. 96 (83)key overview


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)


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


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


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…


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)


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


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…


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


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)…


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.


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…


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.


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


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


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)


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



• 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



• 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



• 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)



• 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


Methodology Options

• 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)

p. 108 (n/a)


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


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


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


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


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


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 :)



• 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?


Requirements

• 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

See also INFO627


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

tps = transactions per second

http://www.nwfusion.com/reviews/2000/1120rvhow.html


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.)



• Techniques are:– Sampling– Research and Site Visits– Observation of the Work Environment– Questionnaires– Interviews– Prototyping

p. 243 (623)


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


Sampling

• And study existing system documents– Inputs– Outputs– Program documentation– Data dictionaries– User and maintenance manuals


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


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


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


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


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)


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


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


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

http://www.aitp.org/organization/about/ethics/ethics.jsp

http://www.standardsasia.net/portal/index.jsp?pageID=corp_level1&path=about/whatis&file=code.xml&xsl=generic.xsl

http://www.cpsr.org/program/ethics/cei.html

http://www.acm.org/serving/ethics.html

INFO 503 Glenn Booker

Documents

Transcript of INFO 503 Glenn Booker