bmgt403 exam I

the PIECES framework

a framework to classify problems, opportunities, and directives

PIECES — “P”:

the need to improve performance

PIECES — “I”:

the need to improve info and data

PIECES — “E”:

the need to improve economics, control costs, or increase profits

PIECES — “C”:

the need to improve control or security

PIECES — “E”:

the need to improve efficiency of people and processes

PIECES — “S”:

the need to improve service to customers, suppliers, partners, employees, etc.

the 4 phases of the sys dev life cycle (SDLC)

planning, analysis, design, implementation

SDLC planning phase deliverable:

feasibility study

SDLC analysis phase deliverable:

functional requirements

SDLC design phase deliverable

systems specifications

SDLC implementation phase deliverable

operational system

problem

a situation, either existing or anticipated, that requires corrective action

opportunity

a situation that needs improvement despite the absence of complaints

directives

requirements imposed by the gov/a major customer or supplier

categories of a feasibility study

technical, economic, non-economic, legal & ethic, operational, schedule

project charter (aka. SOW or LOI)

formally recognizes the existence of a project by identifying the scope of work & project objectives

• is issued by a senior-level manager/committee

• provides the project manager with the authority to apply org resources to project activities

• is crucial to the project’s success

the project scope

defines the boundary of the project as precisely as possible

• made up of the scope statement & management

scope statement

documents project objectives & deliverables

scope management

controls what is or is not included in project

scope creep

a subtle or significant increase in the requirements/expectations of a project often without regard to the impact on budget and schedule

work breakdown structure (WBS)

a grouping of the work involved in a project that defines the total scope of the project

• manages project schedules, costs, resources, and changes

• allows more effective control over the project

the 3 approaches to developing a WBS

analogy, top-down, bottom-up

approaches to dev a WBS — analogy:

reviewing WBS’ of similar projects and tailoring your project

approaches to dev a WBS — top-down:

start with the largest item of the project and break them down

• the decomposition process

the decomposition process

breaking down project deliverables into smaller, manageable components

approaches to dev a WBS — bottom-up:

start with the specific simplest tasks and roll them up

the 6 fact finding techniques

research, sampling of existing documents, interviews, observation, site visits, questionnaires

structured interviews

the interviewer has a specific set of questions to ask of the interviewee

the 3 types of interview questions

open-ended, close-ended, & probing questions

unstructured interviews

conducted with a general goal/subject in mind and a few, if any, specific questions

logical models

shows what a system is/does

• depicts the system independent of any technical implementation

• reduces bias

• avoids unnecessary technical details

• makes comms w/ end users easier

physical models

shows what the system is/does and how the system is technically implemented

• implementation-dependent because they reflect tech choices/limitations of those choices

the 4 elements of a data flow diagram (DFD)

process, data flow, data store, external entity

DFD elements — process:

an activity/function performed for some specific business reason

DFD elements — data flow:

a single piece of data, or logical collection of several pieces of info in motion

DFD elements — data store:

a collection of data that is stored in some way

• there should be 1 data store for each entity

DFD elements — external entity:

a person, org, org unit, or system that is external to the system but interactions

• it is permissible to duplicate external entities on DFDs

• general rule: should be located on the perimeters of the page

the 3 common errors with process modeling

black hole, miracle, gray hole

errors with process modeling — black hole:

when a process has inputs but no outputs

• ie. data enters the process and then disappears

errors with process modeling — miracle:

when a process has outputs but not inputs

errors with process modeling — gray hole:

when the inputs of a process are insufficient to produce the output

• **most common!

process decomposition

the act of breaking a system into sub-components; each lower level reveals more details

• ex: context level (process zero)→ lvl 0 (functions level) → lvl 1 (transaction/activity level)→ lvl 2 (detailed transaction level)→ … → lvl n (primitive process)

the 4 levels of process decomposition

context level, business functions, business transactions (activity), elementary (primitive) process

levels of process decomp — context level:

a mile-high view of the system

levels of process decomp — business functions:

a set of related and on-going activities of the business

levels of process decomp — business transactions (activity):

triggered by a discrete input and is completed when the process has responded with appropriate outputs

• ex: receiving a customer order and fulfilling it

levels of process decomp — elementary (primitive) processes:

the most detailed level depicted in a process model

context level diagrams

• the first DFD in every business process

• establishes the project scope in context of its business environment

• no data stores appear on the context level

level 0 diagrams

• shows how to partition the entire system into major logical high-level subsystems and how they’re interrelated

• key concept: balancing

balancing

ensuring that all info presented at one level is accurately represented in the next level to come

level one diagrams

• each level 0 process should be decomposed into a more explicit DFD

• details the business transaction of the parent level digram