MIS 330 GMU Mid-Term

Systems Analyst

The systems analyst plays a key role in IS development projects.

The systems analyst works closely with all project team members so that the team develops the right system in an effective way.

Systems analysts must understand how to apply technology in order to solve problems.

Systems analysts may serve as change agents who identify organizational improvement needed, design systems to implement those changes, and train and motivate others to use the systems.

Systems Analyst Skills

Technical

Business

Analytical

Interpersonal

Management

Ethical

Systems Analyst Roles

Business analyst

Systems analyst

Infrastructure analyst

Change management analyst

Project manager

Phases of the SDLC

Planning

Analysis

Design

Implementation

Planning Phase

This phase is the fundamental process of understanding why an information system should be built, and determining how the project team will go about building it.

Steps:

1. project initiation 2. project management

Analysis Phase

The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used.

During this phase the project team investigates any current system(s), identifies improvement opportunities, and develops a concept for the new system.

Steps:

1. Analysis strategy 2. Requirements gathering

3. System proposal

Design Phase

The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed.

Steps:

1. Design Strategy 2. Architecture Design

3. Database and File Specifications 4. Program Design

Implementation

During the implementation phase, the system is either developed or purchased (in the case of packaged software) and installed.

This phase is usually the longest and most expensive part of the process.

Steps:

1. System Construction 2. Installation 3. Support Plan

Project Identification and Initiation

A project is identified when someone in the organization identifies a business need to build a system.

A need may surface when an organization identifies unique and competitive ways of using IT.

To leverage the capabilities of emerging technologies such as cloud computing, RFID, Web 2.0

Business Project Management (BPM)

Nowadays many new IS projects grow out of BPM.

BPM is a methodology used by organizations to continuously improve end-to-end business processes.

types of feasibility

As with the system request, each organization has its own process and format for the feasibility analysis, but most include techniques to assess three areas:

Technical feasibility

Economic feasibility

Organizational feasibility

The results of evaluating these three feasibility factors are combined into a feasibility study deliverable that is submitted to the approval committee at the end of project initiation.

Return on Investment (ROI)

ROI=(Total Benefits - Total Costs)/Total Costs

tangible benefits

value can be quantified and measured easily (reduction in operating costs).

Intangible Benefits

value results from an intuitive belief that the system provides important, but hard-to-measure benefits to the organization.

Project Selection

Systems projects today are evaluated in the context of an entire portfolio of projects.

Determination of a project's contribution to an entire portfolio of a project reinforces the need for a feasibility study.

Portfolio management takes into consideration the different of projects that exist in an organization.

An approval committee must be selective about where to allocate resources as most organizations have limited funds.

If there are several potentially high-payoff projects, and they all have the same risk, then maybe only one of the projects will be selected.

factors for selecting the project

Project management phases consist of

- initiation

- planning

- execution

- control, and

- enclosure.

Project Methodologies

- Waterfall Development

- Parallel Development

- V-model (variation of the Waterfall Development)

- Rapid Application Development (RAD)

- Iterative Development

- System prototyping

- Agile Development

Waterfall

-planning

-Analysis

-Design

-Implementation

-System

Agile development

A group of programming-centric methodologies that focus on streamlining the SDLC.

Includes face-to-face communication

Extreme programming - emphasizes customer satisfaction and teamwork.

Method with unclear requirements

-system prototyping

-throwaway prototyping

-Agile Development

Which methods are better if the requirements are not clear?

-waterfall

-parrallel

-V-Model

Which methods are better for a short time schedule?

-Iterative

-System Prototyping

-Agile Development

Which methods are NOT better for a short time schedule?

-Waterfall

-V-Model

PERT Analysis

E = (O + 4M + P)/6,

Optimistic

Most likely

Pessimistic

Analysis Phase

refers to breaking a whole into its parts with the intent of understanding the parts' nature, functions, and interrelationships.

The planning phase deliverables are the key inputs into the analysis phase.

three steps of analysis

Understand the existing situation (the as-is system)

Identify improvements

Define the requirement for the new system (the to-be system).

Requirements

is a statement of what the system must do or what characteristics it needs to have.

REQUIREMENTS DETERMINATION

Requirements determination is performed to transform the system request's high-level statement of business requirements into a more detailed, precise list of what the new system must do to provide the needed value to the business

Functional Requirements

what the software should do

-process oriented

-information-oriented

Non-Functional Requirements

characteristics the system should have

-operational

-performance

-security

-cultural and political

Requirement Elicitation Techniques

The analyst should recognize that important side effects of the process of determining requirements include building political support for the project and establishing trust between the project team and the users.

The analyst should carefully determine who is included in the process of determining requirements.

top-down approach

high-level to low-level employees

bottom up approach

low-level to high-level employees

JAD session

JAD is an information gathering technique that allows the project team, users, and management to work together to identify requirements for the system.

It can reduce scope creep by 50%,

JAD is a structure process in which 10 to 20 users meet under the direction of a facilitator skilled in JAD techniques.

Problem Analysis

Asking users to identify problems and solutions

Improvements from problem analysis tend to be small and incremental

This type of improvements often is very effective at improving a system's efficiency or ease of use; however, it provides minor improvements in business value.

Root Cause Analysis

focuses on problems first rather than solutions.

Use Case

are a means of expressing user requirements.

Use cases are used extensively in the analysis phase.

A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users and the system's responses.

The text-based use case is easy for the users to understand, and also flows easily into the creation of process models and the data model.

Use Case 2

contains all the information needed to build one part of a process model, expressed in an informal, simple way.

When writing a use case,

- identify the triggering event,

- develop a list of the major steps,

- identify the input(s) and output(s) for every step,

- have the users role-play the use case to verify.

elements of a use case

Each use case has a name and number, and brief description.

The priority may be assigned to indicate the relative significance.

The actor refers to a person, another system, or a hardware device that interacts with the system to achieve a useful goal.

The trigger for the use case - the event that causes the use case to begin.

How to build a use case

Preconditions

It is common practice to create smaller, more focused use cases breaking the whole process down into parts.

It is important to define clearly what needs to be accomplished before each use case begins.

The preconditions define the state the system must be in before the use case commences.

Normal Course

How does a use case relate to testing later

The next part of a use case is the description of the major steps that are performed to execute the response to the event, the inputs used for the steps, and the outputs produced by the steps.

The normal course lists the steps.

actor

refers to a person, another system, or a hardware device that interacts with the system to achieve a useful goal.

data flow diagram

is a technique that diagrams the business processes and the data that pass among them.

Process Model

can be used to further clarify the requirements definition and use cases.

is a graphical way of representing how a business system should operate.

can be used to document the as-is system or the to-be system, whether computerized or not.

elements of a DFD

Process

Data Flow

External Entity

Data store

Process

A process is an activity or a function performed for some specific business reason.

Data Flow

A data flow is a single piece of data, or a logical collection of several pieces of information.

External Entity

An external entity is a person, organization, organization unit, or system that is external to the system, but interacts with it.

Data store

A data store is a collection of data that is stored in some way.

rules of a DFD

Every Process has:

A number, A name (verb), A description, One or more output, Data Flows, Usually one or more input data flows

Every Data Flow has:

A name(noun), A description, One or more connections to a process.

every data store has

A number, A name(noun), A description, One or more input and output data flows.

Every External Entity has:

A name(noun), A description

levels of a DFD

Context Diagram

0-Level DFD

1 Level DFD

Balancing

Context Diagram

The first DFD in every business process is the context diagram.

It shows the entire system in context with its environment.

The context diagram shows the overall business process as just one process and shows the data flows to and from external entities.

0-Level DFD

The level 0 diagram (or level 0 DFD) shows all the major high-level processes of the system and how they are interrelated.

The Level 0 diagram shows all the processes at the first level the numbering, the data stores, external entities, and data flows among them.

A key concept: Balancing

- Ensuring that all information presented in a DFD at one level is accurately represented in the next-level DFD.

A process model has one and only one level 0 DFD.

1 Level DFD

Each process on the level 0 DFD can be decomposed into a more explicit DFD called level 1 diagram (or level 1 DFD).

The set of children and the parent are identical; they are simply different ways of looking at the same thing.

It is important to ensure that level 0 and level 1 DFDs are balanced.

All process models have as many level 1 diagrams as there are processes on the level 0 diagram.

The parent process and the children processes are numbered consistently.

How does a use relate to testing later