chapter 5 (agile modeling, prototyping, and scrum) Flashcards

1
Q

Prototyping

A

Prototyping is an information-gathering technique useful
in seeking
– User reactions
– Suggestions
– Innovations
– Revision plans

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Prototyping

A
  • Patched-up
  • Nonoperational
  • First-of-a-series
  • Selected features
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Patched-Up Prototype

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Nonoperational Scale Model prototype

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

First-Of-A-Series Prototype

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Selected Features Prototype

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Users’ Role in Prototyping

A
  • Honest involvement
  • Communicate the purpose of the prototype clearly
  • Get suggestions for changing, expanding the prototype
    and innovation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Agile Modeling

A

Agile methods are a collection of innovative, user-centered approaches to systems development

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Values and Principles of Agile Modeling

A
  • Communication
  • Simplicity
  • Feedback
  • Courage
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

The Basic Principles of Agile Modeling

A
  • 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
  • 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
  • Provide rapid feedback
  • Encourage quality
  • Review and adjust behavior occasionally
  • Adopt simplicity
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Four Basic Activities of Agile Modeling

A
  • Coding
  • Testing
  • Listening
  • Designing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Coding

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

testing

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

listening

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

designing

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Four Resource Control Variables of Agile Modeling

A
  • Time
  • Cost
  • Quality
  • Scope
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Four Core Agile Practices

A
  • Short releases
  • 40-hour work week
  • Onsite customer
  • Pair programming
18
Q

The Agile Development Process

A
  • 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
19
Q

Writing User Stories

A
  • 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
20
Q

scrum

A
  • 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 (two to
    four weeks for development)
  • Product backlog
  • Sprint backlog
  • Sprint
  • Daily scrum
  • Demo
21
Q

There are three roles in Scrum:

A

– Product owner
– Scrum Master
– Team member

22
Q

Team members:

A

– Work to create and improve user stories
– Generate estimates
– Self-organize to complete the work
– Exhibit willingness to participate in any activity to help
the project

23
Q

Product Backlog

A
  • Features and other deliverables designers intend for the
    product based on user stories
  • The list of user stories is reorganized so that the most
    important user stories appear on the top
24
Q

Sprint Cycle

A
  • Stories are deliverables the team accomplishes
  • Tasks are parts of the story or units of work that each
    team members does
  • The sprint cycle can vary in length, but the usual is two
    weeks
  • At the end of the cycle, determine whether the product
    should be released
25
Q

Two-Week Release Advantages

A
  • Team spirit remains high
  • Completing the product is more real to the team
  • Continual feedback from customers
26
Q

Lessons Learned from Agile Modeling

A
  • 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
  • The 40-hour work week improves worker effectiveness
  • Balanced resources and activities support project goals
  • Agile values are crucial to success
27
Q

Other Unique Scrum Features

A
  • Scrum planning meeting
  • Planning poker
  • Daily meetings
  • Sprint burndown chart
  • Sprint review
28
Q

Two parts to a Scrum planning meeting:

A

– Product owner presents the list of features on the
wish list of user stories
– Estimate the resources needed to complete all of the
features
▪ Common way to do this is to play planning poker

29
Q

Planning Poker

A
  • Planning poker is a way to help the team determine
    estimates for completing the features from user stories
  • There are rules for the game
30
Q

Planning Poker Rules

A
  • A moderator keeps the estimation meeting running
    efficiently
  • The product owner presents one of the user stories that
    needs estimating
  • Each team member chooses a card with a number on it
    and lays it face down
  • A lower numbered card means that a project can be
    completed faster
  • The numbers may represent the number of days it takes
    to finish a feature, story points, or even difficulty in
    abstract terms
  • Team members turn over their cards at the same time
  • The team members with the highest and lowest estimates
    may defend their ratings
  • The entire team can discuss the estimates
  • A new hand is then played and so on
31
Q

Daily Scrum Meetings

A
  • Called a stand-up meeting because it lasts only a few
    minutes
  • Team members tell each other what tasks they’ve been
    working on since the previous daily Scrum
  • Tasks they expect to complete during the current daily
    Scrum
  • Obstacles might get in their way
32
Q

Sprint Burndown Chart

A
  • Way to keep track of performance
    – Horizontal axis tracks the time that has elapsed
    – Vertical axis may track the number of tasks remaining
    or the number of hours to complete the remaining
    tasks
    – Red line shows hours of work remaining, and the
    yellow bars show the number of tasks remaining
33
Q

Sprint Review

A
  • Team gets together in a meeting to review the work done
  • Note any tasks that were not completed
  • User stories completed are prominently documented
  • User stories the team committed to that were not finished
    are noted
34
Q

Kanban
Key elements of the Kanban system as applied to
software development are:

A

– Visualize the workflow
– Keep work-in-process (WIP) as small as possible
– Reevaluate the workflow, reassigning priorities if need
be
– Strive for continual improvement

35
Q

Scrum Advantages

A

– Quick product development
– Exercises a user-oriented approach
– Encourages teamwork
– Less confusing than more formal approaches
– Flexibility
– Satisfying to team members
– Rewards smaller but meaningful accomplishments
– Provides feedback
– Adaptability

36
Q

Scrum Disadvantages

A

– Documenting features improperly
– Releasing products with errors
– Releasing products too soon for the user
– Completing the sprint backlog under pressure
– Working as a geographically dispersed team may be
difficult
– Working as a team when special skills are required may be
challenging
– Replacing team members who leave the team is difficult

37
Q

Devops – Development Operations

A
  • Decrease the deployment time for newly developed
    applications and maximize profit by rapidly addressing
    market opportunities and getting customer feedback in a
    timely manner
  • Development and operations are working in parallel
    streams within a DevOps culture
38
Q

Comparing Agile Modeling and Structured Methods

A
  • Improving the efficiency of systems development
  • Risks inherent in organizational innovation
39
Q

risks in adopting organizational innovation

A

-organizational culture
-individual rights
-timing
-measuring impact
-cost
-clients’ reactions

40
Q

Risks When Adopting New Information
Systems

A
  • 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