IDSc 3202 Business Systems Analysis and Design

Avoidable Rework

work that is not value added work and work that wasn't done right the first time.

Value added work

work that has been done right the first time and adds value to the project or process.

Business Analyst

focuses on business issues surrounding the system. Identify the business value that the system will create, develop ideas for improving the business processes and helps design new business process and policies.

Business Requirements

what information systems will do or what functionality it will contain. They need to be explained at a high level so that the approval committee and ultimately the project team understand what the business expects from the final product. Business requirements are what feature and capabilities the information system will have to include.

Change Agent

the person leading the change effort. The change agent charged with actually planning and implementing the change. usually someone outside of the business unit adopting the system and there has no direct management authority over the potential adopters.

Data modeling

a formal way of representing the data that are used and created by a business system. It illustrates people, places, or things about which information is captured and how they are related to each other.

International Institute of Business Analysts

produces a vendor-independent certification program and has published an exhaustive body of knowledge similar to the provided by PMI for project managers.

Liar's Poker

over promising what their project will do, how much it will cost, and when it will be completed.

Process

all of the tasks required for the enterprise to respond to a condition or event.

Requirements analysis

tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

System Development Life Cycle

The SDLC starts with a planning phase in which the project team identifies the business value of the system conducts, a feasibility analysis, and plans the project. The second phase is the analysis phase in which the team develops an analysis strategy, gather information, and builds a set of analysis models. The design phase, interface design, database and file specifications and program design. Implementation the system is built installed and maintained.

SDLC Phases Waterfall

analysts and users proceed sequentially from one phase to the next. The key deliverable for each phase are typically voluminous and are presented to the approval committee and project sponsor for approval as the project moves from phase to phase.

Technology enablement

Equipment and/or methodology that, alone or in combination with associated technologies, provides the means to generate giant leaps in performance and capabilities of the user. For example, the coming together of telecommunication technologies, internet, and groupware has leveled the field so that even smaller firms are able to compete in areas where they otherwise could not.

As-Is Process

the current way a process is being accomplished

Economic Feasibility

addresses whether the system should be built. It includes a cost-benefit analysis of development costs, operational costs, tangible benefits and intangible costs and benefits.

Feasibility analysis

examines key aspects of the proposed project:

■ The technical feasibility (Can we build it?)

■ The economic feasibility (Will it provide business value?)

■ The organizational feasibility (If we build it, will it be used?)

Feasibility Study

techniques to assess three areas: technical feasibility, economic feasibility, and organizational feasibility. The results of these techniques are combined into a feasibility study deliverable that is given to the approval committee at the end of project initiation.

Handoff

when process steps move between swimlanes. It comes in pairs with a "send" process from the source and a "receive" process at the destination.

Intangible benefits

Intangible costs and benefits are more difficult to incorporate into the economic feasibility analysis because they are based on intuition and belief rather than on “hard numbers.”

Organizational feasibility

how well the system ultimately will be accepted by its users and incorporated into the ongoing operations of the organization.

Project management

the project manager creates a work plan, staffs the project, and puts techniques in place to help the project team control and direct the project through the entire SDLC. The deliverable for project management is a project plan that describes how the project team will go about developing the system.

Project manager

The project manager is often a highly experienced systems analyst. This individual

ensures that the project is completed on time and within budget and that the

system delivers the expected value to the organization.

Project selection

Investments in information systems projects today are evaluated in the context of an

entire portfolio of projects. Decision makers look beyond project cost and consider

a project’s anticipated risks and returns in relation to other projects. Companies prioritize

their business strategies and then assemble and assess project portfolios on

the basis of how they meet those strategic needs.

Project sponsor

The person who initiates the project and who serves as the primary point of contact for the project on the business side

Stakeholder

stakeholder is a person, group, or organization that can affect (or can

be affected by) a new system. In general, the most important stakeholders in the

introduction of a new system are the project champion, system users, and organizational

management

Stakeholder analysis

an alternative method of conducting organizational analysis.

Swimlane Diagram

is the documenting of process steps that encompass all activities performed in the conduct of a single business process and to a level of detail that allows analysis of the process for its improvement.

System proposal

The system proposal is the initial deliverable that describes what business

requirements the new system should meet. Because it is really the first step in the

design of the new system, some experts argue that it is inappropriate to use the term

analysis as the name for this phase; some argue a better name would be analysis

and initial design.

System Request

is a document that describes the business reasons for building a system and the value that the system is expected to provide. The project sponsor usually completes this form as part of a formal system project selection process within the organization. Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues.

Tangible benefits (hard & soft)

include revenue that the system enables the organization to collect, such as increased sales. In addition, the system may enable the organization to avoid certain costs, leading to another type of tangible benefit: cost savings.

Technical feasibility

“Can we build it?”

Familiarity with the application

Familiarity with the technology

Project size

Compatibility of the new system with the technology that already exists in the organization

To-be process

proposed ways to design a new system (called the to-be system).

Verification

Proving that each requirement has been satisfied

- Building system right: system complies with system requirements and conforms to design

Validation

Ensuring that requirements set is correct, complete, and consistent, model can be created

that satisfies requirements, and real-world solution can be built and tested to prove that it

satisfies requirements

- Building right system: system does what it’s supposed to do in intended environment

Specialized Actor

Inherits capabilities (relationships) from generalized actor

Actor

Stakeholders that have interactions with the system being diagrammed and are external to the system, can be people or another system

Association

Relationship between an actor and a use case

Boundary

Scope of system in use case diagram, actors are shown outside boundary

Document Analysis

Analyze documentation of as-is system

- Con: most systems are not well documented

- Pro: documents represent formal system so the differences between this and as-is system

can be analyzed to determine what is needed

<<Extends>>

a use case that is an optional extension of the base case

<<Includes>>

a use case that always executed by the base case

Functional Goal

Should be the use case name, functional goal produces something of value

Joint Application Development (JAD)

Information gathering technique that allows project team, users, and management to work

together to identify requirements for the system

- Reduces scope creep by preventing requirements that are too vague or specific

Happy Path

does not include exceptions goes through the typical steps of the use case.

Observation

Act of watching processes being performed

Allows accurate information gathering of as-is system and allows for validation of

information gathered through other techniques

- Should keep low profile and not influence those being observed

- Used to supplement interview information

-

(Use Case) Step

Steps needed to process inputs and produce outputs for a given use case

Trigger (temporal & external)

temporal trigger is when an actor or system does not trigger this, the trigger is a timer

external is when an actor has to trigger the use case

Use Case

o A use case depicts a set of activities performed to produce some output result. Each use case describes how an external user triggers an event to which the system must respond. (145)

Role Play

when our use case is written the writers act out the roles to make sure it is correct and complete

(Use Case) Inputs and Outputs

the second major part of a use case is the set of major inputs and outputs. Each of the major inputs and outputs to the use case are described, along with their source or destination (147)

Role of iteration in developing

iteration or gradual refinement within any artifact that a BA is doing. The first time you write a use case might not be correct. Role play or walk through with users and really flush out the conditions and details of the use case.

COTS software

o Commercial off-the-shelf software

o COTS purchases are alternatives to in-house developments or one-off government-funded developments. COTS typically requires configuration that is tailored for specific uses. The use of COTS has been mandated across many government and business programs, as such products may offer significant savings in procurement, development, and maintenance.

o Software functionality acquired from an independent, third-party that is used on a “as is” basis

Prototyping

o System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback

Timeboxing

Time-oriented (as opposed to task-oriented) approach to scope management. This technique sets a fixed deadline for a project and delivers the system by that deadline no matter what, even if functionality needs to be reduced.

Trade offs (triple constraint)

scope, schedule and budget cost

Work breakdown structure (WBS)

Tasks (each focuses on one of the required design deliverables) can be organized in 2 ways: by SDLC phase or by product. Each task is listed with duration, dependency, and status (open/close).

Work plan

Work plan is a table that lists all of the tasks in the work breakdown structure, along with

important task information such as the people who are assigned to perform the tasks, the

actual hours that the tasks took, and the variances between estimated and actual completion times. At a minimum, the information should include the duration of the task, the current statuses of the tasks and the task dependencies.

Work package

is the subtasks of a summary task

Steps in Workplan

Identify deliverables

Create work breakdown structure

Estimate tasks

Create dependencies

Assign responsiblities

Role of Project Manager

Ensures that the project is completed on time, within budget, and delivers the expected values to the organization. (textbook, 10)

choosing a system development methodology,

estimating time frame

assigning resources

coordinating project team

monitoring the project

refining estimates on the project

Role of Business Analyst

Analyzing the key business aspects of the system

Identifying how the system will provide business value

Designing the new business processes and policies

Risk

send task >> "students wont get there email" WRONG

send task >> student don't read there email as a result they won't get there bill Use Case not implemented correctly

RISK AND IMPACT

Agile Project Management

focuses on streamlining the SDLC much of modeling and documentation overhead is eliminated and face to face communication is preferred. It emphasizes a simple application development process and cycles are kept short.

Conference room pilot

Analysis - non-operational or patched-up prototype

sit in a room with paperwork and mock-up what would happen

prototyping a package rather than prototyping for development

pg. 6 of Calder and Jorge

Contingency planning

Developing plans for to keep small technology glitches in the new system from turning into major business disasters

Approaches:

o Choosing parallel conversion – i.e operating the old and new systems together to ensure

that there’s a fallback system

o Identify & plan for worst-case scenario – i.e. in case there’s no existing (old) system at

all, go back to simple manual procedures.

Corrective action

Error message should inform the user that he/she has attempted to do something to which the system cannot respond, explain the reason,

Critical Path (CPM)

CPM identifies the critical path in the network, the longest path from project inception to

completion. The critical path shows all tasks that must be completed on schedule for the project as a whole to finish on time. CP also allows indetification of bottleneck(s).

Death march project

The schedule has been compressed to less than half the amount estimated by a rational estimating process. The staff has been reduced to less than half the number that would normally be assigned to a project of this size and scope. The budget and associated resources have been cut in half. The functionality, features, performance requirements, or other technical aspects of the project are twice what they would be under normal circumstances.

Extreme Programming

Agile development approach that emphasizes:

o Communication – between developers and users

o Simplicity – start with the simplest possible thing

o Feedback – from users

o Courage

On site customer

Expert in the business aspect of the systems. On-site customer writes user stories, communicates to team members, helps prioritize and balance long-term business needs, and makes decisions about which feature to be tackled first.

Pairs programming

bringing people on board junior and senior program, reducing mistakes

a trademark of agile development

Rapid Application Development (RAD)

RAD incorporates special techniques and computer tools to speed up the analysis, design, and implementation phases in order to get some portion of the system developed quickly and into the hands of the users for evaluation and feedback.

• CASE (computer-aided software engineering) tools

• JAD(joint application development) sessions

• fourth-generation/visual programming languages (e.g., Visual Basic.NET)

• code generators

- may all play a role in RAD.

Scope Creep

Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.” .Scope creep can be very expensive because changes made late in the SDLC can require much of the completed system design (and even programs already written) to be redone.

Short releases

Agile development practice: release the system with most important features first, and then improving it later

Supercharged Waterfall

Has evidence of CASE, JAD, or protoyping

Recommended Situations for Agile Methodology

High exploration project, unknown unknowns, high need for customer responsiveness and customers are responsive and organization with an innovative culture.

Agile Application Development Activities

1. Coding

2. Testing – agile modeling relies on automated tests, and large libraries of tests exist for most

programming languages

3. Listening – developers should listen to each other as well as customers

4. Designing – should allow flexibility

Which SDLC Phase

Does it have iteration no waterfall or supercharged

Does it have JAD, CASE or Protoyping then Supercharged.

Time frame of sprints or releases more frequent then Agile

Strong emphasis on values then Agile

Scope bank or prioritize feature list Agile

Steps for implementing timeboxing

Set the date for system delivery

Prioritize the functionality that needs to be included in the system

Build the core of the system (the most important functionalities)

Postpone functionality that cannot be provided within the time frame

Deliver the system with core functionality

Repeat steps 3 through 5, to add refinements and enhancements

4 Basic Activities of Agile Development:

o Coding

o Testing

o Listening – there is less reliance on formal&written communication in agile development

and more on informal verbal communication

o Designing – should allow flexibility

4 Resource control variables of agile Modeling

o Time – Agile approach insists to finish on time. Consider time to listen to customers,

design, code, and test

o Cost – Lesson: overstaffing & overtime won’t help. Consider wiser investment in aiding

programmers & analysts (i.e. Visio)

o Quality – internal (i.e. testing software for functionality) and external (how customers

perceive the system) can be sacrificed for on-time delivery.

o Scope – determined by listening to customers and getting them to write down customer

stories.

4 Core Agile Practices

o Short releases with later improvement

o 40-hour week

o Onsite customer – having an expert in business aspect of the system on site.

o Pair programming – developers work in pairs.

IDSc 3202 Business Systems Analysis and Design

About this deck

About StudyBlue

Sign up (free) to study this.

About this deck

About StudyBlue