CS 455 CH 9, 10, Kanban

Attributes

"Responsibilities," describes a class that has been selected for inclusion in the analysis model. Are the set of data objects that fully define the class within the context of the problem.

Object-oriented analysis

An approach to analysis modeling that focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements. Ex: UML & Unified Process

Secondary scenarios

Answers to the primary questions result in the creation of this set that is part of the original use case but represents alternative behavior. - alternative behavior

Structured Analysis

Considers data and the processes that transform the data as separate entities. Data objects are modeled in a way that defines their attributes and relationships. Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system.

The requirements model as a bridge between the system description and the design model

System description/Analysis model/Design model

Writing a Formal Case

The goal in context identifies the overall scope of the use case. The precondition describes what is known to be true before the use case is initiated. The trigger identifies the event or condition that "gets the use case started" [Coc01b]. The scenario lists the specific actions that are required by the actor and the appropriate system responses. Exceptions identify the situations uncovered as the preliminary use case.

Analysis Package

Various elements of the requirements model (e.g., use cases, analysis classes) are categorized in a manner that packages them as a grouping in a manner that makes them more manageable for large systems. Assembles a collection of related classes.

Kanban

a strategy for optimizing the flow of stakeholder value through a process that uses a visual, work-in-progress limited pull system. Central to its definition is the concept of "flow," where the movement of customer value throughout the product development system. It optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.

• Entity classes

also called a model or business classes, are extracted directly from the statement of the problem (e.g., FloorPlan and Sensor ). These classes typically represent things that are to be stored in a database and persist throughout the duration of the application (unless they are specifically deleted).

Flow-Based Events

an enhance Scrum events.

Service Level Expectation

forecasts how long it should take a given item to flow from start to finish within your workflow. Two parts: 1. a period of elapsed days 2. a probability associated with that period (e.g., "85% of work items will be finished in eight days or less").

Workflow

includes a shared understanding within the Scrum Team of how work is defined (work items), the start state of the process, the active states for the work items, and the finished state of the process.

# symbol

indicates that an element is accessible only to packages contained within a given package.

stereotype

is an "extensibility mechanism" [Arl02] within UML that allows you to define a special modeling element whose semantics are custom-defined. In UML stereotypes are represented in double angle brackets (e.g., <<stereotype>>).

A class depends on another class if

it uses/depends objects of that class

Flow Metrics and Analytics

makes the flow transparent and enable flow-oriented inspection and adaptation. These metrics are a reflection of the current health and performance of the Scrum Team's approach. They will also point to interventions that can improve Scrum Team function and the value it delivers.

• Controller classes

manage a "unit of work" from start to finish. That is, controller classes can be designed to manage (1) the creation or update of entity objects, (2) the instantiation of boundary objects as they obtain information from entity objects, (3) complex communication between sets of objects (4) validation of data communicated between objects or between the user and the application. In general, controller classes are not considered until the design activity has begun.

Budd [Bud96] suggests a taxonomy of classes that includes:

producers (sources) and consumers (sinks) of data, data managers, view or observer classes, and helper classes .

fl ow-oriented elements

represent the system as an information transform, depicting how data objects are transformed as they fl ow through various system functions. Ex: DFD, data models

UML activity diagram

supplements the use case by providing a graphical representation of the fl ow of interaction within a specific scenario.

Flow-Based Daily Scrums

the meeting itself takes place around the Kanban board and focuses on where flow is lacking and on what actions the Scrum Team can take to get work flowing again.

Class-based elements model

the objects that the system will manipulate, the operations that will be applied to the objects to the effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. Ex: Class diagrams, collaboration diagrams

Multiplicity

where "one or more" is represented using 1..*, and "0 or more" by 0..*. In UML, the asterisk indicates an unlimited upper bound on the range.

To help in the identification of collaborators, you can examine three different generic relationships between classes [Wir90]:

(1) is-part-of relationship - All classes that are part of an aggregate class are connected to the aggregate class via an is-part-of relationship (aggregation). (2) has-knowledge-of relationship (3) depends-upon relationship - implies that two classes have a dependency that is not achieved by has-knowledge-of or is-part-of. Each of the three generic relationships is considered briefly in the paragraphs that follow.

The requirements model must achieve three primary objectives:

(1) to describe what the customer requires (2) to establish a basis for the creation of a software design (3) to define a set of requirements that can be validated once the software is built.

Questions that must be answered if use cases are to provide value as a requirements modeling tool.

(1) what to write about, (2) how much to write about it (3) how detailed to make your description (4) how to organize the description?

Software Domain analysis

- It is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks. - It doesn't look at a specific application, but rather at the domain in which the application resides. The intent is to identify common problem-solving elements that are applicable to all applications within the domain.

The analysis model and requirements specification

- provide a means for assessing quality once the software is built. - should describe what the customer wants, establish a basis for design, and establish a target for validation.

When a complete CRC model has been developed, the representatives from the stakeholders can review the model using the following approach [Amb95]:

1. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). 2. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. 3. The review leader reads the use case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. 4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. 5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use case, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards.

"potential" object. We must consider each further before a final decision is made. Coad and Yourdon [Coa91] suggest six selection characteristics that should be used as you consider each potential class for inclusion in the analysis model:

1. Retained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function. 2. Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way. 3. Multiple attributes. During requirement analysis, the focus should be on "major" information; a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity. 4. Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class. 5. Common operations. A set of operations can be defined for the potential class and these operations apply to all instances of the class. 6. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model.

Wirfs-Brock and her colleagues [Wir90] suggest five guidelines for allocating responsibilities to classes:

1. System intelligence should be distributed across classes to best address the needs of the problem. 2. Each responsibility should be stated as generally as possible. 3. Information and the behavior related to it should reside within the same class. 4. Information about one thing should be localized with a single class, not distributed across multiple classes. 5. Responsibilities should be shared among related classes, when appropriate.

Use case diagram

A graphical representation of a usage scenario and the representation can facilitate understanding, particularly when the scenario is complex.

Flow-Based Sprint Planning

A meeting uses flow metrics as an aid for developing the Sprint Backlog

Sprint

Contains the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

Association

Defines two analysis classes that are related to one another in some fashion. Multiplicity defines how many of one class are related to how many of another class.

Behavioral elements

Depict how external events change the state of the system or the classes that reside within it. Ex: Stae diagrams, sequence diagrams

Flow-Based Sprint Review

Inspecting Kanban flow metrics as part of the Sprint Review creates opportunities for new conversations about monitoring progress towards a goal. It provide some additional information when the Product Owner discusses likely target and delivery dates. Reviewing a Scrum Team's SLE may cause the Product Owner to revise the Product Backlog.

Flow-Based Sprint Retrospectives

Inspects and adapts the definition of "Workflow" to optimize the flow in the next Sprint. Using a cumulative flow diagram to visualize a Scrum Team's Work in Progress, average approximate Cycle Time and average Throughput may be valuable.

Scenario-based models

It depicts how the user interacts with the system and the specific sequence of activities that occur as the software is used. Ex: Use cases, users stories

Primary scenarios

It does not consider alternatives

UML swimlane diagram

It is a useful variation of the activity diagram and allows you to represent the flow of activities described by the use case and at the same time indicate which actor (if there are multiple actors involved in a specific use case) or analysis class has responsibility for the action described by an activity rectangle. It represents the flow of actions and decisions and indicates which actors perform each.

Purpose of Kanban

It is designed to enhance and expand the practices of the Scrum framework.

A grammatical parse

It is used to extract candidate classes, attributes, and operations from text-based narratives. Criteria for the definition of a class are defined.

Class Responsibility Collaboration (CRC)

It provides a simple means for identifying and organizing the classes that are relevant to the system or product requirements. The card's purpose is to fail early, to fail often, and to fail inexpensively. It is a lot cheaper to tear up a bunch of cards than it would be to reorganize a large amount of source code."

Kanban with Scrum Theory

Kanban can be helpful at Done" increment. stage. By y visualizing work in new ways, a Scrum Team can apply the set of practices laid out in this guide to more effectively optimize value delivery. A beneficial side effect of optimizing value delivery is that it provides many more opportunities to inspect and adapt process and product. Tightening the customer feedback loop with Kanban is a proven strategy for empirically improving a process. Kanban's hyperfocus on transparency, visualization, and flow, combined with the Scrum framework, form a powerful foundation on which to design a process to deliver optimal customer value.

Colaborations

are identified by determining whether a class can fulfill each responsibility itself. If it cannot, then it needs to interact with another class.

Use cases

are simply an aid to defining what exists outside the system (actors) and what should be performed by the system. In some situations, it becomes the dominant requirements engineering mechanism. However, this does not mean that you should discard the other modeling methods when they are appropriate.

Collaborators

are those classes that are required to provide a class with the information needed to complete a responsibility. In general, it implies either a request for information or a request for some action.

• Boundary classes

are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Entity objects contain information that is important to users, but they do not display themselves. Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. (For example, a boundary class called CameraWindow would have the responsibility of displaying surveillance camera output for the SafeHome system.)

Operations

define the behavior of an object. Four broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting) (2) operations that perform a computation (3) operations that inquire about the state of an object, (4) operations that monitor an object for the occurrence of a controlling event. - Accomplished by operating on attributes and/or associations, an operation must have "knowledge of the nature of the class attributes and associations.

Cockburn [Coc01b] recommends a "brainstorming" session to derive a reasonably complete set of exceptions for each use case. In addition to the three generic questions suggested earlier in this section, the following issues should also, be explored:

• Are there cases in which some "validation function" occurs during this use case? This implies that validation function is invoked and a potential error condition might occur. • Are there cases in which a supporting function (or actor) will fail to respond appropriately? For example, a user action awaits a response but the function that is to respond times out. • Can poor system performance result in unexpected or improper user actions? For example, a Web-based interface responds too slowly, resulting in a user making multiple selects on a processing button. These select queue inappropriately and ultimately generate an error condition.

Each step in the primary scenario is evaluated by asking the following questions [Sch98a]:

• Can the actor take some other action at this point? • Is it possible that the actor will encounter some error condition at this point? If so, what might it be? • Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by some event outside the actor's control)? If so, what might it be?

Optimizing flow requires defining what flow means in a Scrum context. Each Scrum Team must create its definition of "Workflow" containing the following elements:

• Defined points at which the Scrum Team considers work to have started and to have finished. • A definition of the individual units of customer value that are flowing through the Scrum Team's system (most likely Product Backlog Items (PBIs)). • A definition of the workflow states that the PBIs flow through from start to finish (of which there must be at least one active state). • Explicit policies about how workflows through each state (which may include items from a Scrum Team's definition of "Done" and pull policies between stages). • A definition of how Work in Progress (WIP) will be limited. • A set Service Level Expectation (SLE) that communicates a forecast of how long it should take to complete work items.

CLASS; The taxonomy of class types can be extended by considering the following categories:

• Entity classes also called a model or business classes • Boundary classes • Controller classes

Analysis classes manifest themselves in one of the following ways:

• External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. • Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem. • Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. • Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. • Organizational units (e.g., division, group, team) that are relevant to an application. • Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. • Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.

While it is up to the Scrum Team to define its workflow, there are a few elements it must include:

• Identifying work items that are not yet in an active state as "not started." • Identifying work items entering the active state ("started") as Work in Progress (WIP). • Identifying work items that have passed through all of the active states planned for that item as "finished."

The requirements modeling action results in one or more of the following types of models:

• Scenario-based models of requirements from the point of view of various system "actors." • Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements. • Behavioral and patterns-based models that depict how the software behaves as a consequence of external "events." • Data models that depict the information domain for the problem. • Flow-oriented models that represent the functional elements of the system and how they transform data as they move through the system.

Analysis rules of thumb that should be followed when creating the analysis model:

• The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. "Don't get bogged down in details" [Arl02] that try to explain how the system will work. • Each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system. • Delay consideration of infrastructure and other nonfunctional models until design. That is, a database may be required, but the classes necessary to implement it, the functions required to access it, and the behavior that will be exhibited as it is used should be considered only after problem domain analysis has been completed. • Minimize coupling throughout the system. It is important to represent relationships between classes and functions. However, if the level of "interconnectedness" is extremely high, efforts should be made to reduce it. • Be certain that the requirements model provides value to all stakeholders. Each constituency has its own use for the model. For example, business stakeholders should use the model to validate requirements; designers should use the model as a basis for design; QA people should use the model to help plan acceptance tests. • Keep the model as simple as it can be. Don't add additional diagrams when they add no new information. Don't use complex notational forms when a simple list will do.

Scrum Teams achieve flow optimization by using the following four practices:

• Visualization of the workflow - to makes its workflow transparent. • Limiting WIP - it refrains from pulling more than that number of work items into a given part of the workflow. Ex: Sprint, is a way of controlling how much work a Development Team is going to attempt during a specified period. • Active management of work items in progress - Responding quickly to blocked work items. - Making sure that work items are only pulled in to the workflow at about the same rate that they leave the workflow. - Ensuring work items aren't left to age unnecessarily and are completed according to an established SLE (SERVICE LEVEL EXPECTATION). - Unclogging work that piles up in a column or columns. • Inspecting and adapting their definition of "Workflow"

Some additional things to consider during a flow-based Daily Scrum are as follows:

• What work items are b locked and what can the Scrum Team do to get them unblocked? • What is the Work Item Age of each item in progress? What work items have violated or are about to violate their SLE and what can the Scrum Team do to get that work completed? • Are there any things that may impact the Scrum Team's ability to complete work today that is not represented on the board?

The four basic metrics of flow that Scrum Teams using Kanban will need to track are as follows:

• Work in Progress (WIP): The number of work items started but not finished (according to the Scrum Team's definition of "Workflow"). • Cycle Time: The amount of elapsed time between when a work item "starts" and when a work item "finishes." • Work Item Age: The amount of elapsed time between when a work item "started" and the current time. • Throughput: The number of work items "finished" per unit of time. Note the measurement of throughput is the exact count of work items.