Chat with us, powered by LiveChat MIS485 1 | Economics Write
+1(978)310-4246 credencewriters@gmail.com
  

Use APA style.
Check the 3 chapters. 
Draw using www.draw.io

2020 – 2021

Spring 2021

Capstone Project in MIS (MIS485)

Individual Assignment 1 (IA 1) – 15%

Start Date: 22 March 2021 – 17:00

Due Date: 27 March 2021 – 23:59

(Please upload your answer on Moodle using IA1 Turnitin submission link)

Student Names and IDs:

Section: O1

Faculty Name:

Total Earned Points: /100

MIS485 – Individual Assignment 1 Spring 2021 2

Read the following Personal Trainer, Inc. case carefully, before answering any of the below questions

CASE: PERSONAL TRAINER, INC.

Personal Trainer, Inc., owns and operates fitness centers in a dozen Midwestern cities. The centers have done well, and the company is planning an international expansion by opening a new “supercenter” in the Toronto area. Personal Trainer’s president, Cassia Umi, hired an IT consultant, Susan Park, to help develop an information system for the new facility. During the project, Susan will work closely with Gray Lewis, who will manage the new operation.

Background

During requirements modeling for the new system, Susan Park met with fitness center managers at several Personal Trainer locations. She conducted a series of interviews, reviewed company records, observed business operations, analyzed the BumbleBee accounting software, and studied a sample of sales and billing transactions. Susan’s objective was to develop a list of system requirements for the proposed system.

Fact-Finding Summary

· A typical center has 300-500 members, with two membership levels: full and limited. Full members have access to all activities. Limited members are restricted to activities they have selected, but they can participate in other activities by paying a usage fee. All members have charge privileges. Charges for merchandise and services are recorded on a charge slip, which is signed by the member. At the end of each day, cash sales and charges are entered into the BumbleBee accounting software, which runs on a computer workstation at each location. Daily cash receipts are deposited in a local bank and credited to the corporate Personal Trainer account. The BumbleBee program produces a daily activity report with a listing of all sales transactions. At the end of the month, the local manager uses BumbleBee to transmit an accounts receivable summary to the Personal Trainer headquarters in Chicago, where member statements are prepared and mailed. Members mail their payments to the Personal Trainer headquarters, where the payment is applied to the member account.

· The BumbleBee program stores basic member information, but does not include information about member preferences, activities, and history.

· Currently, the BumbleBee program produces one local report (the daily activity report) and three reports that are prepared at the headquarters location: a monthly member sales report, an exception report for inactive members and late payers, and a quarterly profit-and-loss report that shows a breakdown of revenue and costs for each separate activity.

During the interviews, Susan received a number of “wish list” comments from local managers and staff members. For example, many managers wanted more analytical features so they could spot trends and experiment with what-if scenarios for special promotions and discounts. The most frequent complaint was that managers wanted more frequent information about the profitability of the business activities at their centers.

To enhance their business, managers wanted to offer a computerized activity and wellness log, a personal coach service, and e-mail communication with members. Managers also wanted better ways to manage information about part-time instructors and staff. Several staff members suggested a redesign for the charge slips or scannable ID cards.

Based on the Personal Trainer, Inc. case, please answer the following questions

1. Explain the reasons why the company wants to develop a new information System? (15 points)

2. Identify the fact-finding techniques used by Susan. (15 points)

3. Determine the system requirements, providing examples for each category and type. Review the information that Susan gathered, and as a system analyst, assume that you will add your own ideas to achieve more effective inputs, processes, outputs, performance, security, and controls. (30 points)

4. Draw data flow diagrams (i.e., context diagram and Level-0 diagram) that represent the main process, input and output requirements described in the fact statement or recommended by you, in question number 3, whenever applicable. (40 points)

MIS485 – Individual Assignment 1 Spring 2021 1

MIS485: Capstone Project
in MIS

2MGT 400 – Project Management

Textbook: Farrell, P. J., (2017). IT Capstone

Project (3rd Edition), Kendall Hunt

Publishing.

Fact Finding Techniques and
Determining System

Requirements

Introduction:

Copyright © 2016 Pearson Education, Ltd. 4

Three main steps:

1. Identifying potential development projects

2. Classifying and ranking IS development projects

3. Selecting IS development projects

At the end of the systems planning and selection
phase of the SDLC:

• Management Can grant permission to pursue
development of a new System.

• A project is initiated and planned.
• System analyst begin determining what the

new system Should do….

Systems development life cycle with

analysis phase highlighted

Performing Requirements Determination

Copyright © 2016 Pearson Education, Ltd. 5

In the analysis phase, we need to:

1. Get a good idea of

what the

requirements of the

system are.

2. Characterize them in

a structure that leads

amenably into a

system design

Phase Description

• Systems analysis is the second phase in the SDLC.

• Will use fact-finding techniques which include interviewing,
documentation review, observation, surveys and questionnaires, and
sampling to study and understand the current system and then
determine the requirements for the new proposed system.

• Will use requirements modeling, data and process modeling, and
object modeling techniques to represent the new system

• Will consider various development strategies for the new system, and
plan for the transition to systems design tasks

6

Systems Analysis Phase Overview

– The overall objective of the systems analysis phase is to
 Understand the proposed project,

 Ensure that it will support business requirements

 Build a solid foundation for system development

– You use models and other documentation tools to visualize and
describe the proposed system

7

Part I:
Understanding System Requirements

Copyright © 2016 Pearson Education, Ltd. 8

 What is System Requirement?
 Type of system Requirements.
 Categories of System Requirements.

System Requirement:

Copyright © 2016 Pearson Education, Ltd. 9

Systems Requirements

– They are the characteristic or feature that must be

included in an information system to satisfy business

requirements, and system improvement objectives and

be acceptable to users.

– System requirements serve as benchmarks to measure

the overall acceptability of the finished system

System Requirement:

Copyright © 2016 Pearson Education, Ltd. 10

 Systems Requirements Types:

1. Functional Requirements:
– are the descriptions of the system functions and services,
– How the system should react to particular inputs
– and how the system should behave in particular situations.

 Examples of functional requirements:
• Searching a record: The user shall be able to search either all of the initial

set of databases or select a subset from it.
• Deletion of a record: The user shall be able to delete the existing record of

any patient.
• Updating a record: The user shall be able to update the information of any

patient
• Create new record: ….etc.

System Requirement: (Cont.)

Copyright © 2016 Pearson Education, Ltd. 11

 Systems Requirements Types:
2. Non-Functional Requirements:

– are constraints on the services, or functions offered by the system
– such as timing constraints, constraints on the development

process, standards, etc.

• Often described as the
 Usability : the system is user friendly (or easy to use)
 Reliability: the system is error free and maintains up to date

databases.
 Performance: easy searching and updating of records
 Security: Only authorized users can access the system with user name

and password (or ID).

Other: scalability, availability, flexibility, configurability, portability

System Requirements Categories
examples:

• Outputs
• The Web site must report online volume statistics every four hours, and

hourly during peak periods.

• The inventory system must produce a daily report showing the part
number, description, quantity on hand, quantity allocated, quantity
available, and unit cost of all sorted by part number.

• Inputs
• Manufacturing employees must swipe their ID cards into online data

collection terminals that record labor costs and calculate production
efficiency

• The department head must enter overtime hours on a separate screen

12

System Requirements Categories
examples:

• Processes
• The student records system must calculate the GPA at the end of each

semester.
• As the final step in year-end processing, the payroll system must update

employee salaries, bonuses, and benefits and produce tax data required by
the top management.

• Performance
• The system must support 25 users online simultaneously
• Response time must not exceed four seconds.

• Security and Controls
• The system must provide logon security at the operating system level and

at the application level.
• An employee record must be added, changed, or deleted only by a member

of the human resources department.

13

Part II:
Performing Requirements Determination

Copyright © 2016 Pearson Education, Ltd. 14

Performing Requirements Determination

• During the requirements determination, system analysts gather
information on what system should do from many sources: such as
• Users of the current system
• Reports
• Forms
• Procedures

• All of the system requirements are carefully documented and prepared for
structuring.

Structuring means taking the system requirements you find during
requirements determination and ordering them into tables, diagrams, and

other formats that make them easier to translate into technical system
specifications.

Copyright © 2016 Pearson Education, Ltd.

15

Performing Requirements Determination (Cont.)

• Characteristics of analysts while gathering requirements
• Impertinence

• Question everything

• Impartiality
• Find the best organizational solution

• Relaxation of constraints
• Assume anything is possible and eliminate the infeasible

• Attention to detail
• Every fact must fit with every other fact

• Reframing
• View the organization in new ways

Copyright © 2016 Pearson Education, Ltd.

16

Deliverables for Requirements
Determination

Copyright © 2016 Pearson Education, Ltd.

• From interviews and observations
• interview transcripts, observation notes, meeting minutes.

• From existing written documents
• mission and strategy statements, business forms, procedure manuals, job

descriptions, training manuals, system documentation, flowcharts.

• From computerized sources
• Joint Application Design session results, CASE repositories, reports from

existing systems, displays and reports from system prototype

17

Copyright © 2016 Pearson Education, Ltd. 18

Traditional Methods for Determining
Requirements: Traditional Fact-Gathering Finding
techniques

Copyright © 2016 Pearson Education, Ltd.

• Fact-Finding Overview

– First, you must identify the information you need

– Develop a fact-finding plan

• Who, What, Where, When, How, and Why?

– Difference between asking what is being done and what could or
should be done

19

Copyright © 2016 Pearson Education, Ltd.

 Interviewing individuals and groups

 Observing workers

 Studying business documents

20

Traditional Methods for Determining
Requirements: Traditional Fact-Gathering Finding
techniques

Traditional Methods for Determining
Requirements (Cont.)

Copyright © 2016 Pearson Education, Ltd.

21

Traditional Methods for Determining
Requirements (Cont.)

 Interviewing

o One of the primary ways analysts gather information
about an information systems project.

• Gather facts, opinions, and speculations.

o Analysts need to

• Observe body language and emotions.

• Prepare an interview guide: is a document for

planning, developing, and conducting an interview.

Copyright © 2016 Pearson Education, Ltd.

22

Traditional Methods for Determining
Requirements (Cont.)

 Interviewing
o Step 1: Determine the People to Interview

• Informal structures

o Step 2: Establish Objectives for the Interview

• Determine the general areas to be discussed

• List the facts you want to gather

Copyright © 2016 Pearson Education, Ltd.

23

Traditional Methods for Determining
Requirements (Cont.)

 Interviewing (Continued)
o Step 3: Choosing/ developing Interview Questions

Each question in an interview guide can include both verbal and
non-verbal information.
 Open-Ended Questions.

 No pre-specified answers
 Used to probe for unanticipated answers

 Close-Ended Questions.
 Respondent is asked to choose from a set of specified

responses
 Work well when the popular answers to questions are known
 Do not require a long period of time, and can cover a greater

number of topics

Copyright © 2016 Pearson Education, Ltd.

24

Traditional Methods for Determining
Requirements (Cont.)

 Interviewing
o Step 4: Prepare for the Interview

• Careful preparation

• Limit the interview time

o Step 5: Conduct the Interview
• Develop a specific plan for the meeting

• Begin by introducing yourself, describing the project, and explaining your
interview objectives

• Engaged listening

• Allow the person enough time to think about the question

• After an interview, you should summarize the session and seek a
confirmation

Copyright © 2016 Pearson Education, Ltd.

25

Traditional Methods for Determining
Requirements (Cont.)

 Interviewing
o Step 6: Document the Interview

• Note taking should be kept to a minimum

• After conducting the interview, you must record the information quickly

• After the interview, send memo to the interviewee expressing your
appreciation

• Note date, time, location, purpose of the interview, and the main points you
discussed so the interviewee has a written summary and can offer additions
or corrections.

o Step 7: Evaluate the Interview

Copyright © 2016 Pearson Education, Ltd.

26

Copyright © 2016 Pearson Education, Ltd. 27

Copyright © 2016 Pearson Education, Ltd.

28

Copyright © 2016 Pearson Education, Ltd. 29

Traditional Methods for Determining
Requirements (continued)

 Directly Observing Users

• Serves as a good method to supplement interviews

• Direct Observation

• Watching users do their jobs

• Used to obtain more firsthand and objective measures of
employee interaction with information systems

• Often difficult to obtain unbiased data

• People often work differently when being observed

• Time-consuming and limited time to observe

Copyright © 2016 Pearson Education, Ltd.

30

 Analyzing Procedures and Other Documents
• Document Analysis

• Review of existing business documents

• Can give a historical and “formal” view of system requirements

• Types of Information to Be Discovered:

• Problems with existing system

• Opportunity to meet new need

• Organizational direction

• Title and names of key individuals

• Values of organization

• Special information processing circumstances

• Rules for processing data

Copyright © 2016 Pearson Education, Ltd.

31

Traditional Methods for Determining
Requirements (continued)

 Analyzing Procedures and Other Documents (Cont.)

Useful document to be analyzed:

1. Written work procedure

2. Business form

3. Reports

4. Description of current information system

Copyright © 2016 Pearson Education, Ltd. 32

Traditional Methods for Determining
Requirements (continued)

 Analyzing Procedures and Other Documents (Cont.)

1. Useful document: Written work procedure

• For an individual or work group

• Describes how a particular job or task is performed

• Includes data and information used and created in the process

Copyright © 2016 Pearson Education, Ltd. 33

Traditional Methods for Determining
Requirements (continued)

Analyzing Procedures (Cont.)

Example of a procedure

Copyright © 2016 Pearson Education, Ltd. 34

Analyzing Procedures (Cont.)

FIGURE 6-3 Example of a procedure (cont.)

Copyright © 2016 Pearson Education, Ltd. 35

 Analyzing Procedures and Other Documents (Cont.)

• Potential Problems with Procedure Documents:

• May involve duplication of effort

• May have missing procedures

• May be out of date

• May contradict information obtained through interviews

• All of the above problems illustrate the difference between
formal systems and informal systems.

Copyright © 2016 Pearson Education, Ltd. 36

Traditional Methods for Determining
Requirements (continued)

 Analyzing Procedures and Other Documents (Cont.)

• Formal Systems: the official way a system works as
described in organizational documentation (i.e. work
procedure)

• Informal Systems: the way a system actually works
(i.e. interviews, observations)

Copyright © 2016 Pearson Education, Ltd. 37

Traditional Methods for Determining
Requirements (continued)

Copyright © 2016 Pearson Education, Ltd. 38

 Analyzing Procedures and Other Documents (Cont.)
2. Useful document: Business form

• Used for all types of business functions

• Explicitly indicates what data flow in and out of a system and data
necessary for the system to function

• Gives crucial information about the nature of the organization

Traditional Methods for Determining
Requirements (continued)

Analyzing Procedures
and Other Documents
(Cont.)

Figure 5-4 An invoice form from

Microsoft Excel

(Source: Microsoft Corporation.)

Copyright © 2016 Pearson Education, Ltd. 39

Copyright © 2016 Pearson Education, Ltd. 40

 Analyzing Procedures and Other Documents (Cont.)
3. Useful document: Reports

• Primary output of current system

• Enables you to work backwards from the report to the data needed to
generate it

Traditional Methods for Determining
Requirements (continued)

Analyzing
Procedures
and Other
Documents
(Cont.)

Copyright © 2016 Pearson Education, Ltd.

41

Figure 5-5 An example of a report-

An accounting balance sheet

Copyright © 2016 Pearson Education, Ltd. 42

 Analyzing Procedures and Other Documents (Cont.)
4. Useful document: Description of current information system

• It is applied, If the current system is computer-based.

• Include the documents that describe how the system was
designed and how it was work.

• A lot of different types of documents fit this description;
everything from flowcharts to data dictionaries and CASE
tool reports to user manuals.

Traditional Methods for Determining
Requirements (continued)

Copyright © 2016 Pearson Education, Ltd. 43

Modern Methods and Techniques for
Determining Requirements

 Joint Application Design (JAD)
• Brings together key users, managers, and systems analysts

• Purpose: collect system requirements simultaneously
from key people

• Conducted off-site

 Prototyping
• Repetitive process

• Rudimentary version of system is built

• Replaces or augments SDLC

• Goal: to develop concrete specifications for ultimate
system

Copyright © 2016 Pearson Education, Ltd.

44

Joint Application Design (JAD)

• Participants
• Session leader

• Users

• Managers

• Sponsor

• Systems analysts

• Scribe

• IS staff

Copyright © 2016 Pearson Education, Ltd.

45

Copyright © 2016 Pearson Education, Ltd. 46

Joint Application Design (JAD) (continued)

• End Result
• Documentation detailing

• Existing system

• Features of a replacement system

Copyright © 2016 Pearson Education, Ltd.

47

Prototyping

• User quickly converts requirements to working
version of system

• Once the user sees requirements converted to
system, will ask for modifications or will generate
additional requests

Copyright © 2016 Pearson Education, Ltd.

48

Prototyping (continued)

• Most useful when:
• User requests are not clear

• Few users are involved in the system

• Designs are complex and require concrete form to
evaluate fully

• History of communication problems between analysts and
users

• Tools are readily available to build prototype

Copyright © 2016 Pearson Education, Ltd.

49

Prototyping (continued)

• Drawbacks
• Tendency to avoid formal documentation

• Difficult to adapt to more general user audience

• Sharing data with other systems is often not considered

• Systems Development Life Cycle (SDLC) checks are often
bypassed

Copyright © 2016 Pearson Education, Ltd.

50

Summary

• Interviews
• Open-ended and close-ended questions

• Preparation is key

• Other means of gathering requirements are:
• Observing workers

• Analyzing business documents

Copyright © 2016 Pearson Education, Ltd.

51

Summary (continued)

• Joint Application Design (JAD)

• Prototyping

• Business Process Reengineering (BPR)
• Disruptive technologies

Copyright © 2016 Pearson Education, Ltd.

52

MIS485: Capstone Project
in MIS

2MGT 400 – Project Management

Textbook: Farrell, P. J., (2017). IT Capstone

Project (3rd Edition), Kendall Hunt

Publishing.

Structuring System
Requirements: Process modeling-

Data Flow Diagrams.

Process Modeling for Structured Analysis

Copyright © 2016 Pearson Education, Ltd. 4

Process Modeling

• Graphically represents the processes that capture,
manipulate, store, and distribute data between a system
and its environment and among system components.

• Data-flow Diagrams (DFD)
• Graphically illustrate movement of data between external

entities and the processes and data stores within a system

Copyright © 2016 Pearson Education, Ltd.

5

Process Modeling (continued)

• Modeling a System’s Process
• Utilize information gathered during requirements

determination

• Structure of the data is also modeled in addition to the
processes

• Deliverables and Outcomes
• Set of coherent, interrelated data-flow diagrams

Copyright © 2016 Pearson Education, Ltd.

6

Process Modeling (continued)

• Deliverables and Outcomes (continued)
• Context data-flow diagram (DFD)

• Scope of system

• DFDs of current system
• Enable analysts to understand current system

• DFDs of new logical system
• Technology independent

• Show data flows, structure and functional requirements of new
system

Copyright © 2016 Pearson Education, Ltd.

7

Process Modeling (continued)

• Data-flow Diagramming Mechanics
• Represent both physical and logical information systems,

manual or computer based.

• Four symbols are used
• See Figure 6-3

• Developed by Gane and Sarson

Copyright © 2016 Pearson Education, Ltd.

8

Definitions and Symbols

Comparison of DeMarco

and Yourdon

and Gane and Sarson

DFD symbol sets

Copyright © 2016 Pearson Education, Ltd. 9

Definitions and Symbols (Cont.)

• Process: works or actions performed on data
(inside the system)

• Data store: data at rest (inside the system)

• Source/sink: external entity that is the origin
or destination of data (outside the system)

• Data flow: arrows depicting movement of
data

Copyright © 2016 Pearson Education, Ltd. 10

Data-Flow Diagramming Mechanics

 Data Flow
• Depicts data that are in motion and moving as a unit

from one place to another in the system

• Drawn as an arrow

• Select a meaningful name to represent the data

Copyright © 2016 Pearson Education, Ltd.

11

Data-Flow Diagramming Mechanics
(continued)

 Data Store
• Depicts data at rest

• May represent data in
• File folder

• Computer-based file

• Notebook

• Drawn as a rectangle with the right vertical line
missing

• Label includes name of the store as well as the
number

Copyright © 2016 Pearson Education, Ltd.

12

Data-Flow Diagramming Mechanics
(continued)

 Process
• Depicts work or actions performed on data so

that they are transformed, stored, or
distributed

• Drawn as a rectangle with rounded corners

• Number of process as well as names are
recorded

Copyright © 2016 Pearson Education, Ltd.

13

Data-Flow Diagramming Mechanics
(continued)

 Source/Sink
• Depicts the origin (Source) and/or destination (Sink)

of the data.

• Sometimes referred to as an external entity.

• Drawn as a square symbol.

• Name states what the external agent is.

• Because they are external, many characteristics are
not of interest to us.

Copyright © 2016 Pearson Education, Ltd.

14

Developing DFDs

 Context Diagram
• A data-flow diagram of the scope of an organizational

system that shows the system boundaries, external
entities that interact with the system and the major
information flows between the entities and the system.

Note: only one process symbol, and no data stores shown

Copyright © 2016 Pearson Education, Ltd.

15

Developing DFDs: An Example

• Hoosier Burger’s
Automated Food
Ordering System

Copyright © 2016 Pearson Education, Ltd.

Context Diagram
contains no data

stores

Context Diagram

16

Developing DFDs (continued)

 Level-O Diagram
• A data-flow diagram that represents a system’s major

processes, data flows, and data stores at a higher level
of detail.

• Processes are labeled 1.0, 2.0, etc. These will be
decomposed into more primitive (lower-level) DFDs.

Copyright © 2016 Pearson Education, Ltd. 17

Developing DFDs:
An Example (continued)

– Next step is to expand the context diagram to show
the breakdown of processes (Figure 6-6)

Copyright © 2016 Pearson Education, Ltd.

18

Copyright © 2016 Pearson Education, Ltd.

Level-O Diagram

19

Data-Flow Diagramming Rules

 Basic rules that apply to all DFDs:

• Inputs to a process are always different than
outputs.
– Processes purpose: is to transform inputs into

outputs.

• Objects always have a unique name
– Every process has a unique name.

• In order to keep the diagram uncluttered, you
can repeat data stores and data flows on a
diagram

Copyright © 2016 Pearson Education, Ltd.

20

Data-Flow Diagramming Rules (continued)

 Process
A. No process

can have
only
outputs (a
miracle)

B. No process
can have
only inputs
(black hole)

C. A process
has a verb
phrase
label

Copyright © 2016 Pearson Education, Ltd.

 Data Store
D. Data cannot be

moved from one
store to another

E. Data cannot move
from an outside
source to a data
store

F. Data cannot move
directly from a data
store to a data sink

G. Data store has a
noun phrase label

 Source/Sink
H. Data cannot move

directly from a
source to a sink

I. A source/sink has
a noun phrase
label

21

Data-Flow Diagramming Rules (continued)

 Data Flow
J. A data flow has only one direction of flow between symbols
K. A fork means that exactly the same data go from a common

location to two or more processes, data stores, or sources/sinks

L. A join means that exactly the same data come from any two or
more different processes, data stores or sources/sinks to a
common location

M. A data flow cannot go directly back to the same process it leaves
N. A data flow to a data store means update
O. A data flow from a data store means retrieve or use
P. A data flow has a noun phrase label

Copyright © 2016 Pearson Education, Ltd. 22

Data Flow Diagramming Rules (Cont.)

Incorrect and correct ways to draw DFDs

Copyright © 2016 Pearson Education, Ltd. 23

Decomposition of DFDs

 Functional decomposition
• An iterative process of breaking a system

description down into finer and finer detail.

• Creates a set of charts in which one process on
a given chart is explained in greater detail on
another chart.

• Continues until no subprocess can logically be
broken down any further.

Copyright © 2016 Pearson Education, Ltd.

24

Decomposition of DFDs (Cont.)

 Level-1 diagram results from decomposition of
Level-0 diagram.

 Level-n diagram is a DFD diagram that is the result
of n nested decompositions from a process on a
level-0 diagram.

 Primitive DFD is the lowest level of a DFD.

Copyright © 2016 Pearson Education, Ltd. 25

Level-1 DFD

Level-1 DFD shows

the sub-processes

of one of the

processes in the

Level-0 DFD.

This is a Level-1

DFD for Process

4.0.Processes are labeled 4.1, 4.2,
etc. These can be further

decomposed in more primitive

(lower-level) DFDs if necessary.

Level-1 diagram showing the

decomposition of Process 4.0

from the level-0 diagram for

Hoosier Burger’s food-ordering

system

Copyright © 2016 Pearson Education, Ltd. 26

Level-n DFD

Level-n DFD

shows the sub-

processes of

one of the
processes in the

Level n-1 DFD.

This is a Level-2

DFD for Process

4.3.
Processes are labeled 4.3.1, 4.3.2, etc. If this is the

lowest level of the hierarchy, it is called a primitive DFD.

Level-2 diagram showing the decomposition of

Process 4.3 from the level-1 diagram for Process

4.0 for Hoosier Burger’s food-ordering system

Copyright © 2016 Pearson Education, Ltd. 27

Balancing DFDs

 When decomposing a DFD, you must conserve inputs to and
outputs from a process at the next level of decomposition

• This is called balancing

 Example: Hoosier Burgers

• In the context diagram, notice that there is

• One input to the system:

• the customer order
• Three outputs:

• Customer receipt

• Food order

• Management reports
Copyright © 2016 Pearson Education, Ltd.

28

Balancing DFDs (continued)

• Example (Continued)

• Notice level-0 DFD.

• We have the same inputs and outputs

• No new inputs or outputs have been introduced

• We can say that the context diagram and level-0 DFD
are balanced

Copyright © 2016 Pearson Education, Ltd.

29

Balancing DFDs:
An Unbalanced Example

• In context diagram, we have
one input to the system, A
and one output, B

Copyright © 2016 Pearson Education, Ltd.

• Therefore. these DFDs are
not balanced

• Level-0 diagram has one
additional data flow, C

30

Balancing DFDs

• We can split a data flow into separate data flows on a
lower level diagram

Copyright © 2016 Pearson Education, Ltd.

31

Guidelines for Drawing DFDs

1. Completeness
• DFD must include all components necessary for the

system
• Each component must be fully described in the

project dictionary or CASE repository

2. Consistency
• The extent to which information contained on one

level of a set of nested DFDs is also included on
other levels

Copyright © 2016 Pearson Education, Ltd.

32

Guidelines for Drawing DFDs (continued)

3. Timing
• Time is not represented well on DFDs
• Best to draw DFDs as if the system has never started

and will never stop

4. Iterative Development
• Analyst should expect to redraw diagram several

times before reaching the closest approximation to
the system being modeled

5. Primitive DFDs
• Lowest logical level of decomposition
• Decision has to be made when to stop

decomposition

Copyright © 2016 Pearson Education, Ltd.

33

Guidelines for Drawing DFDs (continued)

 Rules for stopping decomposition:
• When each process has been reduced to a single

decision, calculation or database operation.
• When each data store represents data about a single

entity.
• When the system user does not care to see any more

detail.
• When every data flow does not need to be split further

to show that data are handled in various ways.
• When you believe that you have shown each business

form or transaction, online display and report as a single
data flow.

• When you believe that there is a separate process for
each choice on all lowest-level menu options.

Copyright © 2016 Pearson Education, Ltd.

34

Using DFDs as Analysis Tools

• Gap Analysis
• The process of discovering discrepancies between two or

more sets of data-flow diagrams or discrepancies within a
single DFD

• Inefficiencies in a system can often be identified
through DFDs

Copyright © 2016 Pearson Education, Ltd.

35

Process Modeling for
Electronic Commerce Application

• Process modeling for electronic commerce projects is
no different than other projects

• See Pine Valley Furniture example; next Table.

Copyright © 2016 Pearson Education, Ltd.

36

Copyright © 2016 Pearson Education, Ltd. 37

Summary

• Data-flow Diagrams (DFD)
• Symbols

• Rules for creating

• Decomposition

• Balancing

• DFDs for Analysis

• DFDs for Business Process Reengineering (BPR)

• Logic Modeling
• Decision Tables

• Process Modeling for the Internet

Copyright © 2016 Pearson Education, Ltd.

38

MIS485: Capstone Project
in MIS

2MGT 400 – Project Management

Textbook: Farrell, P. J., (2017). IT Capstone

Project (3rd Edition), Kendall Hunt

Publishing.

3MGT 400 – Project Management

4MGT 400 – Project Management

PROJECT MANAGEMENT
HANDOUT- I

Managing the Information Systems
Project:

Defining and Planning an information
system project

Introduction

• Project management (PM) may be the most important aspect of systems

development.

• Effective PM helps to ensure

• The meeting of customer expectations.

• The satisfying of budget and time constraints.

• The nature of projects has changed from custom development to

implementing packaged software such as ERP and data warehousing.

• PM needs to be able to work well with vendors and diverse user

community.

Pine Valley Application Project

Three computer applications at Pine Valley Furniture: order filling, invoicing,

and payroll
(Source: Hoffer, Ramesh, and Topi, Modern Database Management 11th ed. 2013)

Managing the Information Systems
Project

• Project
• A planned undertaking of related activities to reach an objective that has a

beginning and an end

• Project management
• A controlled process of initiating, planning, executing, and closing down a

project

Managing the Information Systems
Project (cont.)

• Project manager

• A systems analyst with a diverse set of skills—management, leadership,

technical, conflict management, and customer relationship—who is responsible

for initiating, planning, executing, and closing down a project

• Deliverable

• The end product of an SDLC phase

Deciding on Systems Projects

• System Service Request (SSR)
• A standard form for requesting or proposing systems development work within

an organization

• Feasibility study
• A study that determines whether a requested system makes economic and

operational sense for an organization

Project Management Activities

A project manager

juggles numerous

activities

Phases of Project Management
Process

•Phase 1: Initiation

•Phase 2: Planning

•Phase 3: Execution

•Phase 4: Closedown

PM Phase 1: Project Initiation

• Assess size, scope and complexity, and establish
procedures.

• Establish:
• Initiation team
• Relationship with customer
• Project initiation plan
• Management procedures
• Project management environment and workbook
• Project charter

FIGURE 3-6
The project workbook for

the Purchasing

Fulfillment System

project contains nine key

elements

Project workbook
An online or hard-copy repository for all

project correspondence, inputs, outputs,

deliverables, procedures, and

standards. Used for performing project

audits, orienting new team members,

communicating with management and

customers, identifying future projects,

and performing post-project reviews.

Project Charter

• A short document prepared for the customer describing
project deliverables and outlining the work required to
complete the project

• Elements:
• Title and authorization date
• Project manager name and contact information
• Customer name and contact information
• Project start and completion dates
• Key stakeholders, roles, responsibilities
• Project objectives and description
• Key assumptions
• Signatures of stakeholders

PM Phase 2: Project Planning

1. Describing Project Scope,
Alternatives, and Feasibility

2. Dividing the Project into
Manageable Tasks

3. Estimating Resources and
Creating a Resource Plan

4. Developing a Preliminary
Schedule

5. Developing a Communication
Plan

6. Determining Project
Standards and Procedures

7. Identifying and Assessing Risk

8. Creating a Preliminary Budget

9. Developing a Project Scope
Statement

10. Setting a Baseline Project
Plan

Define clear, discrete activities and the work
needed to complete each activity. Tasks include:

Planning Detail

FIGURE 3-8

Level of project

planning detail should

be high in the short

term, with less detail

as time goes on

Project Scope, Alternatives, and
Feasibility

• What problem or opportunity does the project address?

• What are the quantifiable results to be achieved?

• What needs to be done?

• How will success be measured?

• How will we know when we are finished?

Project Scope, Alternatives, and
Feasibility

• 50% of the planning problems are reported to be as
result of unclear definition of scope and goals.

• Who defines the Project Scope?
• The Project Manager, Customer, and important

stakeholders.
• Requires approval of owner of the project.

• Purpose of the Scope Statement
• To clearly define the deliverable(s) for the end user.
• To focus the project on successful completion

of its goals.
• To be used by the project owner and participants

as a planning tool and for measuring project success.

Project Scope Checklist

1. Project objective (to meet customer’s need)

2. Deliverables (expected output over the life of the project)

3. Milestones(significant event in a project occurs @ time)

4. Technical requirements (to ensure proper performance)

5. Limits and exclusions (should be defined)

6. Reviews with customer (internal or external)

• You should study these in details from the book.

21

• Keep it brief: No more than two pages.
• Some contract companies create: Statement of work

(SOW) which is similar.
• Some companies use term “Project Charter”, which allows

project manager more Flexibility to budget and use
resources as they need fit.
• This is specially useful when these resources cannot be predicted.

• Project Creep happens when scope of project gets
expanded (usually by project owner) .
• Expanding the scope almost always address cost and delays to the

project.

22

Few more points about project scope:

23MGT 400 – Project Management

Determine Project Priorities

• Determining priorities of a project helps to measure the success of a
project!

• Did we achieve everything? (total success)

• Did we just achieve the important outcomes? (Some success).

• Did we fail to achieve all the important outcomes? (Failure)

• Did we fail to achieve any of the important outcomes? (Disaster!!)

24MGT 400 – Project Management

Determine Project Priorities

• Priority Matrix is a tool used to help agree the priorities in a project
for: Time, Performance, and Cost.

• It is allocated one of three categories:
• Constrain (Fixed)

• Enhance (try to improve)

• and Accept (If it has to run behind, never mind).

25MGT 400 – Project Management

Determine Project Priorities

26

Priority Matrix

MGT 400 – Project Management

Dividing Project into Manageable Tasks

• Work Breakdown Structure (WBS)
• Division of project into manageable and logically ordered tasks and subtasks.

• Scheduling Diagrams
• Gantt chart: horizontal bars represent task durations

• Network diagram: boxes and links represent task dependencies. (not
required)

Creating the Work Breakdown Structure.

• What is a Work Breakdown Structure (WBS)?

•“…it is an outline of the project with different
levels of detail.” (p.108)

•It is breaks the project into:

 Product (Level 1)

• major deliverables (level 2)

• Sub deliverables (level 3)
Lowest deliverables (level 4)

Cost accounts (level 5)
Work package (Final level)

28MGT 400 – Project Management

Creating Work Breakdowns Structure (WBS)

29MGT 400 – Project Management

Creating the Work Breakdown Structure.

• Work Packages
• A work package is the lowest level of the WBS.
• Each work output would:

1. Defines work (what).

2. Identifies time to complete a work package (how long).

3. Identifies a time-phased budget to complete a work package (cost).

4. Identifies resources needed to complete a work package (how much).

5. Identifies a person responsible for units of work (who).

6. Identifies monitoring points (milestones) for measuring success.

(p. 111)

30MGT 400 – Project Management

• Organization Breakdown Structure (OBS) depicts how the firm has
organized to distribute work responsibilities.

• OBS also indicates:
• Who (person or department) is responsible for what.

• Cost control accounts.

• Business tend to like to integrate OBS with WBS.

31

Integrating the WBS with the Organization

MGT 400 – Project Management

32

Coding the WBS for the Information System

MGT 400 – Project Management

33

Coding the WBS for the Information System

MGT 400 – Project Management

 WBS is product oriented but some projects do not have tangible product
outcome.

 Process Breakdown Structure (PBS):

• For process-oriented projects in which phases are linked and phases have a specific sequence.

• Example: Creating website:

• Planning, Analysis, Design, Building, testing, implementing, delivery…etc.

• All have to be done in specific sequence.

• Lets look at the book’s example on page 117.

34

Coding the WBS for the Information System

MGT 400 – Project Management

 Process Breakdown Structure (PBS):

35

Coding the WBS for the Information System

MGT 400 – Project Management

36

Responsibility Matrices

MGT 400 – Project Management

37

Responsibility Matrices

1 = Responsible 3 = Consult 5 = Approval
2 = Support/assists 4 = Notification

MGT 400 – Project Management

Developing a Preliminary Schedule

Gantt chart showing project tasks, duration times for those tasks, and predecessors
(Source: Microsoft Corporation.)

WBS Gantt Chart

What is Gantt Chart?

39

– A Gantt chart is a type of bar chart that illustrates a project schedule.

– The bar in each row identifies the corresponding task

– The horizontal position of the bar identifies start and end times of the task

– Bar length represents the duration of the task

– Good for allocating resources and re-scheduling

– Task durations can be compared easily.

Estimating Resources, Creating a Resource
Plan

• Constructive Cost Model (COCOMO) – an automated software
estimation model that uses historical project data and current/future
project characteristics to estimate project costs

• People are the most important and expensive resource
• Important to have a good balance between specialization and task variety

Developing a Communication Plan

• Who are stakeholders?

• What information does each stakeholder need?

• When should information be produced?

• What are sources of information?

• Who will collect, store and validate info?

• Who will organize and document info?

• Who is the contact person for each stakeholder?

• What is the appropriate/best format for info?

• What communication medium should be used?

Communication Plan

The project communication matrix
provides a high-level summary of the
communication plan

Determining Project Standards and
Procedures

• Type of SDLC methodology

• Documentation styles

• Status updates

• Terminology

MANAGING RISK

Identifying and Assessing Risk

• Sources of risk

• Consequences of risk

• Possible sources: new technology, user resistance, critical resource
availability, competitive reactions, regulatory changes, team member
experience

Definitions

• What is Risk?
• Uncertain or chance events that planning can not overcome or

control.

• What is Risk Management?
• A proactive attempt to recognize and manage internal events and

external threats that affect the likelihood of a project’s success.

• What can go wrong (risk event).

• How to minimize the risk event’s impact (consequences).

• What can be done before an event occurs (anticipation).

• What to do when an event occurs (contingency plans).

7–46

The Risk Event Graph

7–47

The Risk
Management
Process

7–48

FIGURE 7.2

The Risk Breakdown Structure (RBS)

7–49

FIGURE 7.3

Partial Risk Profile for Product Development Project

7–50FIGURE 7.4

Defined Conditions for Impact Scales of a Risk on Major Project
Objectives (Examples for negative impacts only)

7–51

FIGURE 7.5

Risk Assessment Form

7–52

FIGURE 7.6

Failure Mode and Effects Analysis (FMEA)
Impact × Probability × Detection = Risk Value

Risk Severity Matrix

7–53

Failure Mode and Effects Analysis (FMEA)
Impact × Probability × Detection = Risk Value

PM Phase 3: Project Execution

• Plans created in prior phases are put into action.

• Actions
• Execute baseline project plan.

• Monitor progress against baseline plan.

• Manage changes in baseline plan.

• Maintain project workbook.

• Communicate project status.

Monitoring Progress with a Gantt Chart

Red bars indicate critical path; lines through bars indicate

percent complete.

FIGURE 3-16

Gantt chart with tasks 3 and 7 completed and task 8 partially completed
(Source: Microsoft Corporation.)

Communication Methods

PM Phase 4: Project Closedown

• Bring the project to an end.

• Actions
• Close down the project.

• Conduct post-project reviews.

• Close the customer contract.

Representing and Scheduling Project
Plans

•Gantt Charts

•Network Diagrams

•PERT Calculations

•Critical Path Scheduling

•Project Management Software

Gantt Charts vs. Network Diagrams

• Gantt charts
• Show task durations.
• Show time overlap.
• Show slack time in duration.

• Network diagrams
• Show task dependencies.
• Do not show time overlap, but show parallelism.
• Show slack time in boxes.

error: Content is protected !!