MIS Bus system analysis exam

50 question over 3 chapters chapter 4, 6, 7: 30 question multible choises and the rest true or false, exam time is 60 min. but the exam will be on Monday28th 2;00 pm EST. I have attached the study guide and the power point for the chapters included in the exam.

STUDY GUIDE FOR EXAM 2 – MIS 300 / MIS 301

CAVEATS (Latin for ‘warnings’):

DO NOT ASSUME THAT YOU CAN READ THIS AND BE READY FOR THE EXAM

· ASSUME THAT ANYTHING IN THE CHAPTERS MAY BE COVERED IF THEY ARE NOT SPECIVICALLY INCLUDED HERE

· THERE WILL BE SOME ACTUAL DIAGRAMMING USING DFD SYMBOLS ON THE EXAM

CHAPTER 4 – INFORMATION GATHERING / INTERVIEWING

· There are four interactive methods for obtaining information requirements:

· Interviewing

· Stories

· Joint application design

· Using questionnaires to survey

· Interviewing is an important method for collecting data on information system requirements, as well as a tool for exploring the human-computer interaction concerns.

· Interviewing reveals goals, feelings, opinions, and informal procedures.

· Five steps in planning the interview are:

· Reading background material

· Establishing interview objectives

· Deciding whom to interview

· Preparing the interviewee

· Deciding on question types and structure

· There are two basic types of interview questions: openended or closed.

· Probes are used to obtain additional information.

· There are three basic ways of structuring interviews: pyramid, funnel, or diamond.

· Stories originate in the workplace, are shared with and repeated by, coworkers and are used to relay some kind of information.

· Isolated stories are welcome when you are looking for facts, and the more important enduring stories capture all aspects of the organization.

· JAD may be used when:

· Users are restless and want something new.

· The organizational culture supports joint problem-solving behaviors.

· Analysts forecast an increase in the number of ideas using JAD.

· Personnel may be absent from their jobs for the length of time required.

· JAD involves analysts, users, executives, observers, a scribe, and a session leader.

· Questionnaires are useful in gathering information about attitudes, beliefs, behaviors, and characteristics from key organization members.

· Questionnaires are valuable if organization members are widely dispersed, if many members are involved with the project, if exploratory work is needed, or if problem solving prior to interviews is necessary.

· Questionnaire language should be simple, specific, free of bias, not patronizing, technically accurate, and addressed to those who are knowledgeable. Use software to check whether the reading level is appropriate for the respondents.

· Questionnaires must be valid and reliable.

· There are three problems associated with poorly constructed scales:

· Leniency

· Central tendency

· Halo effect

· Good response rates can be achieved with consistent control of questionnaire format and style, and with meaningful ordering and clustering of questions.

· Administrating a questionnaire electronically has many benefits, such as reduced costs, and

collecting and storing the results electronically.

CHAPTER 6 – AGILE METHODS AND PROTOTYPING

· Prototyping is an information-gathering technique useful for supplementing the traditional systems development life cycle.

· Prototypes are useful in seeking user reactions.

· NOTE: I won’t ask about the four types of Prototypes (“Patched-up” etc.)

· Prototyping may be used as an alternative to the systems development life cycle.

· Guidelines for developing a prototype are:

· Work in manageable modules

· Build the prototype rapidly

· Modify the prototype in successive iterations

· Stress the user interface

· One disadvantage of prototyping is that managing the prototyping process is difficult because of its rapid, iterative nature. A second disadvantage is that incomplete prototypes may be regarded as complete systems. Clear communication of the prototype timetable with users is essential.

· One advantage of prototyping is the potential for changing the system early in its development. A second advantage is the opportunity to stop development on an unworkable system. A third advantage is the possibility of developing a system that closely addresses users’ needs and expectations.

· Sometimes COTS software may be the quickest way to create a prototype.

· Systems analysts must work systematically to elicit and evaluate users’ reactions to the prototype. There are three ways the user is involved:

· Experimenting with the prototype

· Giving open reactions to the prototype

· Suggesting additions to and/or deletions from the prototype

· Agile modeling is used to plan quickly, develop and release software quickly, and revise software quickly.

· There are four values that are important to agile modeling:

· Communication

· Simplicity

· Feedback

· Courage

· The activities of agile modeling are:

· Coding

· Testing

· Listening

· Designing

· The four resource control variables in agile modeling are:

· Time

· Cost

· Quality

· Scope

· The four core practices in agile modeling are:

· A short release time

· Working a 40-hour week

· Having an onsite customer

· Pair programming

· An agile modeling process has the following steps:

· Listen for user stories from the customer.

· Draw a logical workflow model for the user story.

· Create new user stories based on the logical model.

· Develop some display prototypes.

· Use feedback from the prototypes and logical workflow diagrams to develop the system until a physical model is created.

· User stories are written that consist of a dialogue between developers and users.

· An agile modeling approach called Scrum is based on team development within a strict time frame.

CHAPTER 7 – USING DATA FLOW DIAGRAMS

· Data flow diagrams (DFDs) are one of the main methods available for analyzing data-oriented systems.

· Through the use of DFDs, which emphasize the logic underlying the system, the systems analysts can put together a graphical representation of data movement through the organization.

· The data flow approach has four main advantages over the narrative explanation of the data movement. They are:

· Freedom from committing to the technical implementation of the system too early

· Further understanding of the interrelationships of systems and subsystems

· Communicating current system knowledge to users through data flow diagrams

· Analysis of the proposed system to determine if all the data and processes have been defined

· Four basic symbols are used to chart data movement on data flow diagrams. They are:

· A double square for an external entity—a source or destination of data

· An arrow for movement of data from one point to another

· A rectangle with rounded corners for the occurrence of transforming process

· An open-ended rectangle for a data store

· Correct naming of data flow objects is necessary for good communication. Guidelines are:

· External entities should be named with a noun.

· Processes should be named:

· A system name

· A subsystem name

· With a verb-adjective-noun format

· Processes should have a unique reference number.

· Data stores should be named with a noun.

· Use the following guidelines to develop a data flow diagram:

· Make a list of business activities.

· Create the context level diagram, including all external entities and the major data flow to or from them.

· Create Diagram 0 by analyzing the major activities within the context process. Include the external entities and major data stores.

· Create a child diagram for each complex process on Diagram 0. Include local data stores and detailed processes.

· Processes that do not create a child diagram are called primitive processes. Logic is written for these processes.

· The following conditions are errors that occur when drawing a data flow diagram:

· A process that has only input data flow to it or only output data flow from it.

· When data stores or external entities are connected directly to each other, in any combination.

· Incorrectly labeling data flow or objects. Examples are:

· Labels omitted from data flow or objects

· Data flow labeled with a verb

· Processes labeled with a noun

· Too many processes on a data flow diagram. Nine is the suggested maximum.

· Omitting data flow from the diagram.

· Unbalanced decomposition between a parent process and a child diagram. The data flow in and out of a parent process must be present on the child diagram.

· Logical data flow diagrams show how the business operates and include processes that would exist regardless of the type of system implemented.

· The progression of creating data flow diagrams is:

· Create a logical data flow diagram of the current system.

· Next, add all the data and processes not currently in the system which must be present in the new system, giving a logical data flow diagram for the new system.

· Finally, derive the physical data flow diagram for the new system.

· Advantages of logical data flow diagrams are:

· Better communication with users. They are familiar with how the business operates.

· More stable systems, because the design is based on a business framework.

· Increased understanding of the business by analysts.

· The system will have increased flexibility and be easier to maintain.

· Elimination of redundancy.

· Physical data flow diagrams show how the system operates or how the new system will be implemented.

· Physical data flow diagrams include processes for adding, reading, changing, and deleting records. CRUD is an acronym for Create, Read, Update, Delete.

· A CRUD matrix shows which programs or processes add, read, update, or delete master file records.

· Master or transaction files are used to link all processes that operate at different times.

· An input flow from an external entity is sometimes called a trigger, because it starts activities.

· Elements (or fields) are categorized as either:

· Base elements that are keyed into the system

· Derived elements, which are the result of some operation, such as arithmetic or logic

· Creating a use case is another approach used to develop a data flow diagram. A use case shows the steps performed to accomplish a task.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6
Kendall & Kendall
Systems Analysis and Design, 9e
Agile Modeling and Prototyping

*
*

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Learning Objectives
Understand the roots of agile modeling in prototyping and the four main types of prototyping.
Be able to use prototyping for human information requirements gathering.
Understand agile modeling and the core practices that differentiate it from other development methodologies.
Learn the importance of values critical to agile modeling.
Understand how to improve efficiency for users who are knowledge workers using either structured methods or agile modeling.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Agile Modeling, but First Prototyping
Agile modeling is a collection of innovative, user-centered approaches to system development
Prototyping is an information-gathering technique useful in seeking
User reactions
Suggestions
Innovations
Revision plans

*
Prototyping and RAD (rapid application development) can also be used as an alternative method to SDLC.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Major Topics
Prototyping
Agile modeling

Rules of 4 (Prototyping)
4 Kinds of Prototypes
4 Guidelines for Developing Prototypes

Note: Added by Joe
Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Prototyping
Patched-up
Nonoperational
First-of-a-series
Selected features

*
Information gathered in the prototyping phase allows the analyst to set priorities and redirect plans inexpensively, with a minimum of disruption.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Patched-Up Prototype
A system that works but is patched up or patched together
A working model that has all the features but is inefficient
Users can interact with the system
Retrieval and storage of information may be inefficient

*
In engineering this approach is referred to as breadboarding.
Users can interact with the system—getting accustomed to the interface and types of output available.
Retrieval and storage of information may be inefficient—programs were written rapidly with the objective of being workable rather than efficient.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Nonoperational Scale Models
A nonworking scale mode that is set up to test certain aspects of the design
A nonworking scale model of an information system might be produced when the coding required by the application is too expensive to prototype but when a useful idea of the system can be gained through prototyping of the input and output only.

*
A nonworking scale model of an information system:
processing because of undue cost and time, would not be prototyped.
users can make decisions based on their use of prototyped input and output.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
First-of-a-Series Prototype
Creating a pilot
Prototype is completely operational
Useful when many installations of the same information system are planned
A full-scale prototype is installed in one or two locations first, and if successful, duplicates are installed at all locations based on customer usage patterns and other key factors

*
Pilot —a first full-scale model of a system.
Creation of a working model is one of the types of prototyping done with RAD.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Selected Features Prototype
Building an operational model that includes some, but not all, of the features that the final system will have
Some, but not all, essential features are included
Built in modules
Part of the actual system

*
Some, but not all, essential features are included—a menu on a screen that lists six features may only have three available.
Built in modules—if the features that are prototyped are evaluated by users as successful, they can be incorporated into the larger, final system without undertaking immense work in interfacing.
Part of the actual system—not just a mock-up.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Four Kinds of Prototypes
Clockwise, Starting from the Upper Left
(Figure 6.1)

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Prototyping as an Alternative to the Systems Life Cycle
Two main problems with the SDLC
Extended time required to go through the development life cycle
User requirements change over time
Rather than using prototyping to replace the SDLC use prototyping as a part of the SDLC

*
SDLC—a logical, systematic approach to follow in the development of information systems.
Rather than using prototyping to replace the SDLC use prototyping as a part of the SDLC.
Advantages:
effectively shortens the time between ascertainment of human information requirements and delivery of a workable system.
overcomes some of the problems of accurately identifying user information requirements.

Disadvantages:
prematurely shaping a system before the problem or opportunity being addressed is thoroughly understood.
may result in producing a system that is accepted by specific groups of users but that is inadequate for overall system needs.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Drawbacks to Supplanting the SDLC With Prototyping
Drawbacks include prematurely shaping a system before the problem or opportunity is thoroughly understood
Using prototyping as an alternative may result in producing a system that is accepted by specific groups of users but is inadequate for overall system needs

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Guidelines for Developing a Prototype
Work in manageable modules
Build the prototype rapidly
Modify the prototype in successive iterations
Stress the user interface

*
Prototyping is a superb way to elicit feedback about the proposed system and about how readily it is fulfilling the information needs of its users.
The first step of prototyping is to estimate the costs involved in building a module of the system.
Work in manageable modules—a manageable module is one that allows users to interact with its key features but can be built separately from other system modules.
Build the prototype rapidly—putting together an operational prototype both rapidly and early in the SDLC allows the analyst to gain valuable insight into how the remainder of the project should go.
Modify the prototype—creating it in modules that are not highly interdependent.
Stress the user interface—for many users the interface is the system.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Work in Manageable Modules
It is imperative that an analyst work in manageable modules
One distinct advantage of prototyping is that it is not necessary or desirable to build an entire working system for prototype purposes
A manageable module allows users to interact with its key features but can be built separately from other system modules
Module features that are deemed less important are purposely left out of the initial prototype

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Build the Prototype Rapidly
Speed is essential for successful prototyping
Analysts can use prototyping to shorten this gap by using traditional information-gathering techniques to find information requirements
Make decisions that bring forth a working model
Putting together an operational prototype rapidly and early in the SDLC allows an analyst to gain insight about the remainder of the project
Showing users early in the process how parts of the system actually perform guards against overcommitting resources to a project that may eventually become unworkable

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Modify the Prototype in successive iterations
Making a prototype modifiable means creating it in modules that are not highly interdependent
The prototype is usually modified several times
Changes should move the system closer to what users say is important
Each modification is followed by an evaluation by users

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Stress the User Interface
Use the prototype is to get users to further articulate their information requirements
They should be able to see how the prototype will enable them to accomplish their tasks
The user interface must be well developed enough to enable users to pick up the system quickly
Online, interactive systems using GUI interfaces are ideally suited to prototypes

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Disadvantages of Prototyping
It can be difficult to manage prototyping as a project in the larger systems effort
Users and analysts may adopt a prototype as a completed system

*
Users and analysts may adopt a prototype as a completed system—when it is in fact inadequate and was never intended to serve as a finished system.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Advantages of Prototyping
Potential for changing the system early in its development
Opportunity to stop development on a system that is not working
Possibility of developing a system that more closely addresses users’ needs and expectations

*
Successful prototyping depends on early and frequent user feedback, which analysts can use to modify the system and make it more responsive to actual needs.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Prototyping Using COTS Software
Sometimes the quickest way to prototype is through the modular installation of COTS software
Some COTS software is elaborate and expensive, but highly useful

*
Example: Catholic University’s use of the ERP COTS software package called PeopleSoft, which is handling many of its web-based functions.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Users’ Role in Prototyping
Honest involvement
Experimenting with the prototype
Giving open reactions to the prototype
Suggesting additions to or deletions from the prototype

*
Without user involvement there is little reason to prototype.
To facilitate the prototyping process, the analyst must clearly communicate the purposes of prototyping to users, along with the idea that prototyping is valuable only when users are meaningfully involved.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Prototype Evaluation Form
(Figure 6.3)

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Agile Modeling
Agile methods are a collection of innovative, user-centered approaches to systems development

Rules of 4 (Agile Modeling)jh
Four Values of Agile Modeling
Internalized
Four Activities of Agile Development
Typical things you do
Four Resource Variables of Agile Dev.
What is available to you
Core Agile Practices
‘Critical Success Factors’
Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Values and Principles of Agile Modeling (Internalize)
Communication
Simplicity
Feedback
Courage

*
Agile modelers possess the self-confidence to allow their customers to question, critique, and sometimes complain about the system under development. Analysts learn from their customers, who have been in business a long time.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Values Are Crucial to the Agile Approach (Figure 6.4)

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
The Basic Principles of Agile Modeling (note: mostly re-stating what has already been said)
Satisfy the customer through delivery of working software
Embrace change, even if introduced late in development
Continue to deliver functioning software incrementally and frequently
Encourage customers and analysts to work together daily
Trust motivated individuals to get the job done

*
Providing rapid feedback—in order for humans or the system to make a connection between a stimulus and reaction, the feedback must occur at a reasonable interval.
Assuming simplicity—over 90 percent of problems can be solved with utter simplicity.
Changing incrementally—you are constantly making the smallest change possible that still results in a difference in the development effort.
Embracing change—we want to keep all of our options open, but we want to be able to simultaneously solve whatever presents the biggest obstacle.
Encouraging quality work—all participants want to do quality work.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
The Basic Principles of Agile Modeling (continued)
Promote face-to-face conversation
Concentrate on getting software to work
Encourage continuous, regular, and sustainable development
Adopt agility with attention to mindful design
Support self-organizing teams

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
The Basic Principles of Agile Modeling (continued)
Provide rapid feedback
Encourage quality
Review and adjust behavior occasionally
Adopt simplicity

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Four Basic Activities of Agile Modeling (what you do daily)
Coding (can’t do without)
Testing (more is better)
Listening (ditto)
Designing (until you get it right)

*
The agile analyst needs to identify the amount of effort that will go into each activity and balance that with the resources needed to complete the project.
Coding—the most valuable thing that we receive from code is “learning.”
Testing—the agile approach views automated tests as critical.
Listening—in the agile approach, listening is done in the extreme.
Designing—a way of creating a structure to organize all of the logic in the system.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Coding
Coding is the one activity that it is not possible to do without
The most valuable thing that we receive from code is “learning”
Code can also be used to communicate ideas that would otherwise remain fuzzy or unshaped

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Testing
Automated testing is critical
Write tests to check coding, functionality, performance, and conformance
Use automated tests
Large libraries of tests exist for most programming languages
These are updated as necessary during the project
Testing in the short term gives extreme confidence in what you are building
Testing in the long term keeps a system alive and allows for changes longer than would be possible if no tests were written or run

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Listening
Listening is done in the extreme
Developers use active listening to hear their programming partner
Because there is less reliance on formal, written communication, listening becomes a paramount skill
A developer also uses active listening with the customer
Developers assume that they know nothing about the business so they must listen carefully to businesspeople

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Designing
Designing is a way of creating a structure to organize all the logic in the system
Designing is evolutionary, and so systems are conceptualized as evolving, always being designed
Good design is often simple
Design should allow flexibility
Effective design locates logic near the data on which it will be operating
Design should be useful to all those who will need it as the development effort proceeds

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Four Resource Control Variables of Agile Modeling
Time (robbing from one activity will cost you someplace else)
Cost (budget – vary if you must)
Quality (at the source)
Scope (strive not to vary)

*
When these four control variables are properly included in the planning, there is a state of balance between the resources and the activities needed to complete the project.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Four Core Agile Practices
(Success Factors or ‘Accelerators’)
Short releases
40-hour work week
Onsite customer – or you go to their site
Pair programming – two is more than three

*
Short releases—the development team compresses the time between releases of their product.
40-hour work week—agile development teams purposely endorse a cultural core practice in which the team works intensely together during a typical 40-hour work week.
Onsite customer—a user who is an expert in the business aspect of the systems development work is onsite during the development process.
Pair programming—you work with another programmer of your own choosing.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Working with the 4’s (Figure 6.5)

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
The Agile Development Process
Listen for user stories
Draw a logical workflow model
Create new user stories based on the logical model
Develop some display prototypes
Create a physical data model using feedback from the prototypes and logical workflow diagrams

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Writing User Stories
Spoken interaction between developers and users
Seeking first and foremost to identify valuable business user requirements
The goal is prevention of misunderstandings or misinterpretations of user requirements

*
User stories serve as reminders to the developers that they must hold conversations devoted to those requirements.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
User Stories Can Be Recorded on Cards (Figure 6.6)

*
In this example from the online merchant, the analyst indicates that the designing activity will take above-average effort, and the time and quality resources are required to rise above average.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Scrum
Begin the project with a high-level plan that can be changed on the fly
Success of the project is most important
Individual success is secondary
Project leader has some (not much) influence on the detail
Systems team works within a strict time frame

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Scrum
Product backlog
Sprint backlog
Sprint
Daily scrum
Demo

*
Scrum is a high-intensity methodology. It is just one of the approaches that adopts the philosophy of agile modeling.
Product backlog—in which a list is derived from product specifications.
Sprint backlog—a dynamically changing list of tasks to be completed in the next sprint.
Sprint—a 30-day period in which the development team transforms the backlog into software that can be demonstrated.
Daily scrum—a brief meeting in which communication is the number-one rule.
Demo—working software that can be demonstrated to the customer.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Lessons Learned from Agile Modeling
Short releases allow the system to evolve
Pair programming enhances the overall quality
Onsite customers are mutually beneficial to the business and the agile development team

*
Short releases allow the system to evolve—through the use of short releases, the development team compresses the time between releases of their product, improving the product later as the dynamic situation demands.
Pair programming enhances overall quality—fosters good communication, identifying with the customer, focusing on the most valuable aspects of the project first, testing all code as it is developed, and integrating the new code after it successfully passes its tests.
Onsite customers are mutually beneficial to the business and the agile development team—customers serve as a ready reference and reality check, and the focus of the system design will always be maintained via their presence.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Lessons Learned from Agile Modeling (continued)
The 40-hour work week improves worker effectiveness
Balanced resources and activities support project goals
Agile values are crucial to success

*
The 40-hour work week improves worker effectiveness—even the hardest-hitting developers are susceptible to errors and burnout if they work too hard for too long a period.
Balanced resources and activities support project goals—the resource control variables of time, cost, quality, and scope need to be properly balanced with the activities of coding, designing, testing, and listening.
Agile values are crucial to success—it is essential to the overall success of the project that analysts wholeheartedly embrace the values of communication, simplicity, feedback, and courage in all of the work that they do.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
There Are Six Vital Lessons That Can Be Drawn from the Agile Approach to Systems (Figure 6.7)

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Comparing Agile Modeling and Structured Methods
Improving the efficiency of systems development
Risks inherent in organizational innovation

*
Efficiency—seven strategies that can improve the efficiency of knowledge work.
Risks—when is the appropriate time to upgrade human skills, adopt new organizational processes, and institute internal change.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Strategies for Improving Efficiency Can Be Implemented Using Two Different Development Approaches (Figure 6.8)

*
In consultation with users, analysts must consider the risks that organizations face when adopting new methodologies.
Shows many of the variables that need to be considered when assessing the risk of adopting organizational innovation.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Risks When Adopting New Information Systems
Fit of development team culture
Best time to innovate
Training cost for analysts and programmers
Client’s reaction to new methodology
Impact of agile methodologies
Programmers/analysts individual rights

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Summary
Prototyping
Patched-up system
Nonoperational
First-of-a-series
Selected-features
Prototype development guidelines
Prototype disadvantages

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Summary (continued)
Prototype advantages
Users’ role in prototyping
Agile modeling
Five values of the agile approach
Principles of agile development
Agile activities
Agile resources

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
6-*
Summary (continued)
Core practices of the agile approach
Stages in the agile development process
User stories
Agile lessons
Scrum methodology
Dangers to adopting innovative approaches

*
*

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Learning Objectives
Comprehend the importance of using logical and physical data flow diagrams (DFDs) to graphically depict movement for humans and systems in an organization.
Create, use, and explode logical DFDs to capture and analyze the current system through parent and child levels.
Develop and explode logical DFDs that illustrate the proposed system.
Produce physical DFDs based on logical DFDs you have developed.
Understand and apply the concept of partitioning of physical DFDs.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Flow Diagrams
Graphically characterize data processes and flows in a business system
Depict:
System inputs
Processes
Outputs

*
A series of layered data flow diagrams may be used to represent and analyze detailed procedures in the larger system.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Major Topics
Data flow diagram symbols
Data flow diagram levels
Creating data flow diagrams
Physical and logical data flow diagrams
Partitioning
Communicating using data flow diagrams

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Advantages of the Data Flow Approach
Freedom from committing to the technical implementation too early
Understanding of the interrelatedness of systems and subsystems
Communicating current system knowledge to users
Analysis of the proposed system

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Basic Symbols
A double square for an external entity
An arrow for movement of data from one point to another
A rectangle with rounded corners for the occurrence of a transforming process
An open-ended rectangle for a data store

*
An entire system and numerous subsystems can be depicted graphically with these four symbols in combination.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
External Entities
Represent another department, a business, a person, or a machine
A source or destination of data, outside the boundaries of the system
Should be named with a noun

*
An external entity (outside the boundaries of the system) sends data to (source) or receives data from (destination) the system.
Each entity is labeled with a name, generally a noun.
The same entity may be used more than once on a given data flow diagram.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Flow
Shows movement of data from one point to another
Described with a noun
Arrowhead indicates the flow direction
Represents data about a person, place, or thing

*
Data flows occurring simultaneously can be depicted doing just that through the use of parallel arrows.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Process
Denotes a change in or transformation of data
Represents work being performed in the system
Naming convention:
Assign the name of the whole system when naming a high-level process
To name a major subsystem attach the word subsystem to the name
Use the form verb-adjective-noun for detailed processes

*
The data flow leaving a process is always labeled differently then the data flow entering the process.
A process must also be given a unique identifying number indicating its level in the diagram.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Store
A depository for data that allows examination, addition, and retrieval of data
Named with a noun, describing the data
Data stores are usually given a unique reference number, such as D1, D2, D3
Represents a:
Database
Computerized file
Filing cabinet

*
Data stores represent a person, place, or thing which is why they are named with a noun.
Temporary data stores, such as scratch paper or a temporary computer file are not included on the data flow diagram.

(Figure 7.2)

*
Data flow diagrams can and should be drawn systematically.
To begin a data flow diagram, collapse the organization’s system narrative into a list with four categories of external entity, data flow, process, and data store. This list helps determine the boundaries of the system. Next begin drawing the context diagram.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Creating the Context Diagram
The highest level in a data flow diagram
Contains only one process, representing the entire system
The process is given the number 0
All external entities, as well as major data flows are shown

*
Basically the context diagram consists of:
one process—depicting the entire system
external entities
data flows from the external entities to the process

The diagram does not contain any data stores.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Basic Rules
The data flow diagram must have one process
Must not be any freestanding objects
A process must have both an input and output data flow
A data store must be connected to at least one process
External entities should not be connected to one another

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Drawing Diagram 0
The explosion of the context diagram
May include up to nine processes
Each process is numbered
Major data stores and all external entities are included

*
Including more than nine processes will result in a cluttered diagram that is difficult to understand.
Each process is numbered with an integer, starting form the upper left-hand corner and working toward the lower right-hand corner.
Because a data flow diagram is two-dimensional, you can start at any point and work forward or backward through the diagram.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Drawing Diagram 0 (continued)
Start with the data flow from an entity on the input side
Work backward from an output data flow
Examine the data flow to or from a data store
Analyze a well-defined process
Take note of any fuzzy areas

*
Because a data flow diagram is two-dimensional, you can start at any point and work forward or backward through the diagram.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Flow Diagram Levels
Data flow diagrams are built in layers
The top level is the context level
Each process may explode to a lower level
The lower level diagram number is the same as the parent process number
Processes that do not create a child diagram are called primitive

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Creating Child Diagrams
Each process on diagram 0 may be exploded to create a child diagram
A child diagram cannot produce output or receive input that the parent process does not also produce or receive
The child process is given the same number as the parent process
Process 3 would explode to Diagram 3

*
The process on Diagram 0 that is exploded is called the parent process, and the diagram that results is called the child diagram.
On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3, and so on. This allows the analyst to trace a series of processes through many levels of explosion.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Creating Child Diagrams (continued)
Entities are usually not shown on the child diagrams below Diagram 0
If the parent process has data flow connecting to a data store, the child diagram may include the data store as well
When a process is not exploded, it is called a primitive process

*
In addition, the lower-level diagram may contain data stores not shown on the parent process.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Flow Diagrams Error Summary
Forgetting to include a data flow or pointing an arrow in the wrong direction
Connecting data stores and external entities directly to each other
Incorrectly labeling processes or data flow

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Data Flow Diagrams Error Summary (continued)
Including more than nine processes on a data flow diagram
Omitting data flow
Creating unbalanced decomposition (or explosion) in child diagrams

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Checking the Diagrams for Errors (Figure 7.5)
Forgetting to include a data flow or pointing an arrow in the wrong direction

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Checking the Diagrams for Errors (continued Figure 7.5)
Connecting data stores and external entities directly to each other

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Logical and Physical Data Flow Diagrams
Logical
Focuses on the business and how the business operates
Not concerned with how the system will be constructed
Describes the business events that take place and the data required and produced by each event

*
The progression of creating data flow diagrams is:
Analyze the current system (current logical DFD).
Add features the new system should include (the proposed logical DFD).
Finally the best methods for implementing the new system should be developed (the physical DFD).

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Developing Logical Data Flow Diagrams
Better communication with users
More stable systems
Better understanding of the business by analysts
Flexibility and maintenance
Elimination of redundancy and easier creation of the physical model

*
Better communication with users—centered on business activities.
More stable systems—based on business events and not on a particular technology or method of implementation.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Developing Physical Data Flow Diagrams
Clarifying which processes are performed by humans and which are automated
Describing processes in more detail
Sequencing processes that have to be done in a particular order
Identifying temporary data stores
Specifying actual names of files and printouts
Adding controls to ensure the processes are done properly

*
Physical data flow diagrams are often more complex than logical data flow diagrams simply because of the many data stores present in the system.
The acronym CRUD is used for Create, Read, Update, and Delete.
A CRUD matrix shows which programs or processes add, read, update, or delete master file records.
Intermediate data stores—consist of transaction files used to store data between processes.
A physical data flow diagram may appear more linear that a logical model.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
CRUD Matrix
The acronym CRUD is often used for
Create
Read
Update
Delete
These are the activities that must be present in a system for each master file
A CRUD matrix is a tool to represent where each of these processes occurs in a system

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Event Modeling and Data Flow Diagrams
An input flow from an external entity is sometimes called a trigger because it starts the activities of a process
Events cause the system to do something and act as a trigger to the system
An approach to creating physical data flow diagrams is to create a data flow diagram fragment for each unique system event

*
Triggers start activities or processes, which in turn use data or produce output.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Event Response Tables
An event table is used to create a data flow diagram by analyzing each event and the data used and produced by the event
Every row in an event table represents a data flow diagram fragment and is used to create a single process on a data flow diagram

*
A dataflow diagram fragment is represented by one row in the table.
Each DFD fragment is a single process on a data flow diagram.
All the fragments are then combined to form Diagram 0.
The trigger and response column becomes the input and output data flows.
The activity becomes the process.
The data stores are determined by examining the input and output data flows.

The advantage of building data flow diagrams based on events is that the users are familiar with the events that take place in their business area and know how the events drive other activities.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Use Cases and Data Flow Diagrams
Each use case defines one activity and its trigger, input, and output
Allows the analyst to work with users to understand the nature of the processes and activities and then create a single data flow diagram fragment

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Partitioning Data Flow Diagrams
Partitioning is the process of examining a data flow diagram and determining how it should be divided into collections of manual procedures and computer programs
A dashed line is drawn around a process or group of processes that should be placed in a single computer program

*
Analyze each process to determine whether it should be a manual or automated procedure.
Group automated procedures into a series of computer programs.

*
Different user groups—are the processes performed by several different user groups, often at different physical locations in the company? If so, they should be partitioned into different computer programs.
Timing—processes that execute at different times must be in separate programs
Similar tasks—may be included in the same program.
Efficiency—several batch processes may be included in the same program for efficiency.
Consistency—several processes may be included in the same program or job stream for consistency of data.
Security—may be partitioned into different programs for security reasons.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Partitioning Websites
Improves the way humans use the site
Improves speed of processing
Ease of maintaining the site
Keep the transaction secure

*
Each time data must be obtained from a data store or an external partner, a website designer might consider creating a unique Web form and DFD process to validate and process the data or may also use Ajax, sending a request to the server and obtain a small amount of data or an XML document returned to the same page.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Communicating Using
Data Flow Diagrams
Use unexploded data flow diagrams early when ascertaining information requirements
Meaningful labels for all data components

*
Use unexploded data flow diagrams early when ascertaining information requirements—at this stage they can provide an overview of data movement through the system, lending a visual perspective unavailable in narrative data.
Meaningful labels for all data components—labels should not be generic.
Data flow diagrams can be used for documenting high and low levels of analysis and helping to substantiate the logic underlying the data flows of the organizations.

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Summary
Data flow diagrams
Structured analysis and design tools that allow the analyst to comprehend the system and subsystems visually as a set of interrelated data flows
DFD symbols
Rounded rectangle
Double square
An arrow
Open-ended rectangle

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Summary (continued)
Creating the logical DFD
Context-level data flow diagram
Level 0 logical data flow diagram
Child diagrams
Creating the physical DFD
Create from the logical data flow diagram
Partitioned to facilitate programming

Kendall & Kendall Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
7-*
Summary (continued)
Partitioning data flow diagrams
Whether processes are performed by different user groups
Processes execute at the same time
Processes perform similar tasks
Batch processes can be combined for efficiency of data
Processes may be partitioned into different programs for security reasons

Turn in your highest-quality paper
Get a qualified writer to help you with

“ MIS Bus system analysis exam ”

Get high-quality paper

NEW! AI matching with writer

Still stressed from student homework?

Get quality assistance from academic writers!

Order now