isys 200week #101 systems analysis i review isys 200 glenn booker

ISYS 200 Week #10 1

Systems Analysis IReview

ISYS 200

Glenn Booker

ISYS 200 Week #10 2

The Life Cycle

We use one or more life cycle models to help structure the tasks needed to create a system

Key activities we’ll examine include Determine if system is feasible Gather information to determine requirements Model processes with a Data Flow Diagram; and

model data with an Entity Relationship Diagram Design outputs, inputs, and the user interface Implement the system

ISYS 200 Week #10 3

The Systems Analyst

The role of the systems analyst is part detective, part translator Detective to seek out the requirements from the

various stakeholders and reconcile them What’s a stakeholder? Why might you need to reconcile requirements?

Translator to translate those requirements into a design which will fulfill them, and be intelligible to the people who implement the system (programmers, etc.)

ISYS 200 Week #10 4

The SDLC

A Software Development Life Cycle (SDLC) is used to systematically get from a need to an implemented system

How do you solve a big problem? Break it into little problems and solve them That’s what the SDLC does, by breaking

development into life cycle phases There are many types of life cycles; we’re

focusing on a basic ‘waterfall’ model

ISYS 200 Week #10 5

Typical SDLC Phases

Creating any kind of software system typically involves these phases Identify problems and opportunities Determine information requirements Analyze system needs Design the system Develop the system Test the system Implement the system

ISYS 200 Week #10 6

Maintenance

After the development life cycle, maintenance of the system begins Maintenance can cost 50% to 200% of

the cost of developing a system Tasks are

Fix bugs in the existing system Make minor improvements Update commercial components (OS patches,

apply service packs, product upgrades, etc.)

ISYS 200 Week #10 7

Context Diagram

The context diagram is the highest level of data flow diagram

The system is reduced to a single box, representing all its processes at once

Data flows to all the types of users and external systems are shown

ISYS 200 Week #10 8

Information Gathering

There are two types of methods for gathering information about a system Interactive methods, which interact with

the users of the existing system Unobtrusive (passive) methods, which

observe aspects of the existing system Our goal is to understand the good and bad

aspects of the existing system, to help determine requirements for our new system

ISYS 200 Week #10 9

Interactive Methods

There are three common methods for gathering information interactively Interviews

Open-ended versus closed questions Pyramid, funnel, and diamond structures for questions

Joint Application Design (JAD) Questionnaires

Choosing good scales for answers to questions

ISYS 200 Week #10 10

Unobtrusive Methods

Unobtrusive methods for gathering information include Sampling

Systematic, simple random, stratified, or clustered Set margin for error and confidence interval

Investigation- qualitative and quantitative Observation

These should be used in conjunction with one or more interactive methods


Prototyping

There are four major types of prototype Patched-up prototype – proof of concept Nonoperational prototype – interface images only First-of-a-series prototype – nearly finished

complete system Selected features prototype – a few functions are

fully functional


Rapid Application Development (RAD)

RAD is another method for speeding development time, this time using specialized development tools

Often used when time to market is critical RAD uses three phases

Requirements Planning Phase RAD Design Workshop Implementation


Extreme Programming (XP)

Extreme Programming is one of a family of “agile” development methods which includes Scrum DSDM Evo And others

Please note that the linked file has copyright by the Software Productivity Consortium.


Four XP Core Practices

XP is best known for its core practices Short releases – some features now, others later Forty-hour workweek – don’t burn out

your developers! Onsite customer – to make all that

communication possible Pair programming – develop code in pairs, so

everyone can quickly have peer reviews Change pairs frequently to keep objectivity intact


Data Flow Diagrams (DFDs)

DFDs show the flow of data through the processes your system can perform Processes are connected to the entities which

start them, and/or receive outputs from them Processes are connected to the data stores

used to capture important information created by or used by them

Important to make sure processes and data stores aren’t miracles (no input) or black holes (no output)


CRUD Matrix

A CRUD matrix maps data and processes to verify that all data is used correctly throughout the system

The CRUD matrix shows process names in each row, and data stores in each column (p. 203) For each process and data store, enter C, R, U,

and/or D to indicate allowable data activities Show the process and data store numbers from

the DFD


Data Modeling

Data need to be stored for later reference and analysis

Entities are the name given to what later become data tables

Lots of kinds of files Master files, Transaction files, Document files,

Archival files, Table look-up files, Audit files Need to define what files are needed, and

how they are related to each other


Data Modeling

ERD model captures The entities needed for permanent data

The attributes and the data types of each attribute (text, number, Boolean, etc.)

The primary and, as needed, foreign keys Relationships between entities describe

Cardinality (0, 1, and/or many) A verb phrase to describe the relationship


Data Modeling

Can use associative entities to show when a given entity only exists in connection with records from two other entities

Can use attributive entity to show when an entity is dependent upon a parent entity


Summary of Key Traits

The bottom line for keys is: Each entity must have at least one PK

More than one PK implies a concatenated key Alternate keys are completely optional Each entity may have from zero to many FK’s Each FK is a PK in another, related entity Only one PK-FK relationship is needed to relate

two entities Some keys are not inherently meaningful data


Normalization of Entities

Entities are normalized to third normal form (3NF) when Every attribute appears only once for each record Each non-primary-key attribute is uniquely

determined by the entire primary key Every attribute depends only on the primary key

We don’t worry about fourth and fifth level normalization


Output Design

We design outputs by Determine if they are internal or external outputs Choose the best output technology Deliberately avoiding bias in the design Follow typical design conventions

Group related information Separate constant from variable information Use a consistent design approach and layout

Control distribution and security of outputs


Input Design

Develop inputs needed to fulfill the outputs Consider the seven typical input form sections Use appropriate captions Validate data inputs and use input controls to help

avoid data entry errors Use navigation and controls for screen inputs Plan feedback options and easy user movement Provide instructions, and use a logical sequence

of data entry


Interface Selection

Choose appropriate interface type for the user needs and sophistication Natural language, Question and answer, Menus,

Form-fill, Command language, GUI, Pointing devices (stylus, tablet PC, touch screen) and Voice recognition systems

Minimize user actions, especially typing! Keep look and feel of the interface consistent

Provide help for various levels of users Provide feedback to the user


Problems & Opportunities

We can look for problems and opportunities in many parts of our organization, and the existing systems which are supported Define what’s wrong with the existing system, so

you can fix it with the new system Identify new features to provide functionality not

previously possible Then establish system objectives to predict

how much better the new system will be


Feasibility Analysis

Feasibility consists of several types we want to assess for each candidate project Technical feasibility

Is system technically achievable? Economic feasibility

Determine present value of system benefits and costs Assess break even point, lifetime and annual ROI,

and/or cash flow Operational feasibility

How does new system affect users?


Project Planning

Look at a project in terms of a set of tasks to be accomplished, and managing the resources (people, tools) needed to perform those tasks

Use a life cycle model to identify the major sets of activities, called life cycle phases Each phase is broken down into more and more

specific activities, until the time needed for each activity can be reliably estimated


Gantt Chart

Determine the time and sequence in which tasks need to be done, and put them in a Gantt chart A timeline represents when the project occurs Tasks are bars under the timeline Summary tasks group related tasks together Decisions appear as milestones


PERT Diagrams

PERT diagrams, or PERT charts, are primarily used to help identify the critical path for a project The critical path is the sequence of tasks which,

if any tasks were changed, would also change the completion date of the project

Tasks on the critical path tend to get preferential treatment for getting resources


System Proposal

A system proposal describes the proposed approach for creating a system Is strengthened by analysis of several candidate

solutions, including feasibility study of each They differ in terms of architecture, technology,

degree of automation, choice of commercial components, or selection of custom vs commercial components

The proposal is a sales tool to convince your audience you’ve found the best solution

isys 200week #101 systems analysis i review isys 200 glenn booker

Documents