quiz Bus System Analysis

sajeer

kendall_ch6_rev.ppt

Home >Information Systems homework help >quiz Bus System Analysis

Kendall & Kendall
Systems Analysis and Design, 9e

Agile Modeling and Prototyping

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.

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.

6-*

Major Topics

Prototyping
Agile modeling

Rules of 4 (Prototyping)

4 Kinds of Prototypes
4 Guidelines for Developing Prototypes

Note: Added by Joe

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.

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.

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.

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.

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.

6-*

Four Kinds of Prototypes
Clockwise, Starting from the Upper Left
(Figure 6.1)

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.

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

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.

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

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

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

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

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.

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.

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.

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.

6-*

Prototype Evaluation Form
(Figure 6.3)

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’

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.

6-*

Values Are Crucial to the Agile Approach (Figure 6.4)

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.

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

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.

6-*

The Basic Principles of Agile Modeling (continued)

Provide rapid feedback
Encourage quality
Review and adjust behavior occasionally
Adopt simplicity

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.

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.

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

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

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

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

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.

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.

6-*

Working with the 4’s (Figure 6.5)

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

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.

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.

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

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.

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.

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.

6-*

There Are Six Vital Lessons That Can Be Drawn from the Agile Approach to Systems (Figure 6.7)

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.

6-*

Strategies for Improving Efficiency Can Be Implemented Using Two Different Development Approaches (Figure 6.8)

6-*

Adopting New Information Systems Involves Balancing Several Risks (Figure 6.9)

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.

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

6-*

Summary

Prototyping
Patched-up system
Nonoperational
First-of-a-series
Selected-features
Prototype development guidelines
Prototype disadvantages

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

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

6-*

Publishing as Prentice Hall