Lecture 5 (part-2)

(Week- 5 and 6)
Sprint and Sprint backlog:
Sprint planning and Web application Design

1
2
 Iterative development, incremental development and Sprinting in the scrum
Iterative development:
 This can be described as a planned rework strategy.
 We use multiple passes to improve what we are building so that we can converge on a good solution.
 The biggest downside to iterative development is that in the presence of uncertainty it can be difficult
up front to determine (plan) how many improvement passes will be necessary.

Incremental development:
 We break the product into smaller pieces so that we can build some of it, learn how each piece is to
survive in the environment in which it must exist,
 Adapt based on what we learn, and then build more of it.
 Incremental development gives us important information that allows us to adapt our development effort
and to change how we proceed.
 The biggest drawback to incremental development is that by building in pieces, we risk missing the big
picture.
 We see the trees but not the forest.
Sprint in Scrum
 Scrum leverages the benefits of both iterative and incremental development,
 While negating the disadvantages of using them individually. 3

 Scrum does this by using both ideas in an adaptive series of time-boxed iterations called sprints
 Sprinting in scrum

 During each sprint we perform all of the activities necessary to create a working product increment
(some of the product, not all of it).
 We make some design decisions, create some code based on those decisions, and then test the design and
code—all in the same sprint.
 This has the benefit of quickly validating the assumptions that are made when developing product
4
features.
 By doing all of the related work within one sprint, we are able to quickly rework features,
 Product backlog to Sprint backlog: Your design and implementation
tasks in the sprint of scrum

 You have your product backlog, to implement all PBI, it can take many weeks or months of work

 This cannot be done in one sprint

 To determine the most important subset of product backlog items to build in the next sprint, the

Scrum team performs sprint planning.

 During sprint planning the Scrum team breaks the PBIs into tasks which are entered into the

sprint backlog,

 Breaking product backlog items into tasks is a form of design and just-in-time planning for how

to get the PBI of product backlogs implemented

 Product back log to Sprint backlog: Sprint planning activities

Reference of image:
Book-- Essential Scrum—Kenneth S. Rubin
SIT725 Advanced Software Engineering
1) Velocity: How many Two part Sprint Planning: Design activities for breaking down PBI into tasks
story points per sprint
in past and We will discuss more in detail later classes.
2) Available hours by
Check realistically selected PBI be developed together in the
team
same sprint given one or more constraints, technical/business,

Check realistically selected PBI be

Breakdown into developed together in the same sprint
tasks and esti
given the capacity in terms of available
mate hours
hours,

1) Fill forecast based on

velocity

Reference of image:
Book-- Essential Scrum—Kenneth S. Rubin
SIT725 Advanced Software Engineering
 Design Goals for WebApps
 You need to consider your design elements while breakdown the PBIs into tasks
 In next few slides we will discuss necessary design elements
 Design goals:
 Simplicity and Consistency
 Content should be constructed consistently
 Graphic design (aesthetics) should present a consistent look across all parts of the WebApp
 Architectural design should establish templates that lead to a consistent structure
 Interface design should define consistency with regards to interaction, navigation and content
display
 Navigation mechanisms how users will navigate - should be used consistently across all WebApp
elements

8
 WebApp Design Goals
 Identity
 Establish an “identity” that is appropriate for the business purpose
 Robustness
 The user expects strong content and functions that are relevant to the user’s needs
 Navigation
 Designed in a manner that is intuitive and predictable
 Visual appeal
 The look and feel of content, interface layout, color coordination, the balance of text,
graphics and other media, navigation mechanisms must appeal to end-users
 Compatibility
 With all appropriate environments and configurations
 E.g. all major browsers

9
Elements of Design: The design pyramid

User

Interface
design

Aesthetic design

Content design

Navigation design

Functional design

Architecture design

Component design
Construction

Technology
 Elements of Design: The design pyramid
 Interaction design
 The top two levels of the pyramid form the basis of user’s interaction with the systems and can be
grouped together as interaction design
 Interface design: structure and organization of the user interface.
 Aesthetic design: look and feel of the WebApp.
 Information design: Underpins the content and the way user access to the content
 Content design: layout, structure and outline for all WebApp content
 Navigation design: navigation flow between content objects and WebApp functions
 Functional design: overall behavior and functionality supported by the WebApp, such as
order entry, database process, computational functions
 Technical design
 Architecture design: overall structure for the WebApp.
 Component design: detailed processing logic required to implement functional component that support
a complete set of WebApp functions. 11
Information Design: Information Structures

 An Information architecture might be as simple as a site map.

 Which represents the navigation structure.
 Or how the information is structured for the WebApp and how users might
interact with that structure.

 There is a number of ways in which we can represent the architecture of the

information and content of our Web App.

12
 Information Design: Information Structures

Linear
structure
Grid
structure

Network
structure Hierarchical
structure
13
 Information Structures
 Linear structure: are encountered when we have a predictable sequence of
interactions, although some variation or diversion is common.

 Matrix (or grid) structure: can be applied when WebApp content is organized
categorically in two or more dimensions. It is useful only when highly regular content
is encountered.

 Hierarchical structure: the most common WebApp architecture and is used to reflect
natural information taxonomies.

 Network (or graph) structure: very effective in cross-connecting related aspects

within a WebApp and allowing substantial navigation flexibility.

Also, the architectural structures can be combined to form more complex structures.
14
 What Makes a Good Structure

 Fan-out: a measure of the width of the navigation structure below a single node
(i.e. the number of outward links from a single node).
 The appropriate ‘Fan-out’ of the hierarchical structure should be related to the:
 Complexity of the WebApp options and how distinct the choices are.

 Avoid creating structures that are more than three to four layers deep.

 The hierarchy should be designed in a way that ensures that the categories are as
individual as possible.


15
 Blueprints: Adding Details to a Structure
 Identifying the characteristics of the information architecture that provides
you with a starting point for information design.

 We can use a blueprint to show how the various content objects map into a
specific information structure.

 A blueprint often looks like a site map. However, it also include additional
information that aids in interpretation of the design, such as:
 Whether content is dynamic or static.
 Whether content is personalized for individual users.
 What content objects are mapped to which Web pages.
 What navigational paths will address given tasks.

16
 What Form Does a Blueprint Take?
 The format will be defined by what characteristics we are trying to capture!

 An initial high-level blueprint might focus on the overall information structure.

 A second iteration might elaborate on structural information and provide insight into
the nature of a search interface and how it allows access to content.

 A third iteration might emphasize

how can we personalise our content.

17
 An example
A preliminary information structure:

SIT725
Advance
18 d
Software
Enginee
ring
 Example (cont’d)
A high-level blueprint:

Dark
cylinders =
data sources Image references: . R. S. Pressman and
D. Lowe: Web Engineering, A
Practitioner’s Approach, McGraw-Hill,
Red icons = 2009.
dynamically
constructed
pages.

Yellow = our
static main
pages
SIT725
Advance
19 d
Software
Enginee
ring
 Content design and sequence diagram

The interaction analysis indicates how software will respond to external events.
For content design, you should:
 Evaluate all the use cases to fully understand the sequence of interaction within the system.
 Identify events that drive the interaction sequence and understand how these events relate to specific
objects.
 Identify content classes and its operations
 Create a sequence diagram for each use case.
 Review the models to verify accuracy and consistency.

20
Content design: Design class- Class responsibilities and
collaboration (CRC) modelling
 Design classes have “responsibilities”
 Responsibilities are the attributes and operations encapsulated by the class
 Design classes collaborate with one another
 Collaborators are those classes that are required to provide a class with the information
needed to complete a responsibility.
 In general, a collaboration implies either a request for information or a request for
some action.
 [Ref: 2]

21
CRC (Ref:2):
Responsibilities and Collaborations
 Responsibilities:
 System intelligence should be distributed across classes to best address the needs of the problem
 Each responsibility should be stated as generally as possible
 Information and the behavior related to it should reside within the same class
 Information about one thing should be localized with a single class, not distributed across multiple
classes.
 Responsibilities should be shared among related classes, when appropriate.
 Collaborations
 Classes fulfill their responsibilities in one of two ways:
 A class can use its own operations to manipulate its own attributes, thereby fulfilling a
particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class can fulfill each responsibility itself
22
CRC card (Ref:2)
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/ type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

23
 Identifying design classes using CRC
1. Select a use case, use problem domain class to identify a responsible class for this use case
2. Select a controller class from whom this object receive first message and handle system’s
internal process, you may need more than one for other use cases
3. Create CRC cards by performing textual analyses from this use-cases description and role
playing of this use case
4. Role play of this use case by thinking about what happens and which is helpful.
I. Role playing involves thinking of your self as one of the instances (the role) and
walking through what you would do.
II. You can even have several people and let each of them play a class as you walk
through a use case. It becomes a performance of the use case.
5. In the CRC card left side, write the actions/responsibility as the methods for this class, piece
of information as attributes.
6. As you progress in role play, you may identify that this class needs information from other
classes, need action to be completed. Write their class-name (attribute name) format on
right side of CRC
7. Update the CRC cards of the other class or create new CRC cards for other class as you go
8. Mention in those CRCs about other classes’ responsibilities and attributes as you role play of
this use-case
9. Repeat 1-9 for all other use cases
10. Review the structural model for missing and/or unnecessary classes, attributes, operations, 24
and relationships.
 CRC modelling ([Ref: 2])
 Entity classes, also called model or business classes, are extracted directly from the
statement of the problem (e.g., FloorPlan and Sensor).

 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.

 Controller classes manage a “unit of work” from start to finish. That is, controller
classes can be designed to manage the creation or update of entity objects; the
instantiation of boundary objects as they obtain information from entity objects;
complex communication between sets of objects; validation of data communicated
between objects or between the user and the application.

25
 Relationships in your design class
Association: This is a relationship among instances of object classes
which can be presented in your class diagram

Multiplicity of association: This indicates how many objects participate

in a given relationship:
These can be different types as below
 0..10 means minimum of 0 and maximum of 10
 1, 2 means can be either 1 or 2
* means any number

26
 Aggregation and composition in your design class
 Aggregation: This is a part-of relationship between a component object and an aggregate object in
your design class/content class/process class model
 The parts in the relationship can exist separately
 The relationship is represented with open diamonds

 Composition: This is a part object that belongs to only one whole object and that lives and dies with
the whole object
 The parts in the relationship can’t exist separately
 The relationship is represented with filled diamonds

27
 Example content class diagram
• The arrow means that from one class you can easily access the second associated class to which the
association points, but from the second class, you cannot necessarily easily access the first class.
• An association with an arrow at one end indicates one-way navigability.
• Another way to think about this is that the first class is aware of the second class, but the second class
object is not necessarily directly aware of the first class.
• An association with no arrows usually indicates a two-way association, sometimes it means that
navigation is not significant,
class content

Album
Artist
- cover: String
- description: String - name: String
- downloadLink: String
- name: String
- price: float

Song

- length: String
- name: String
 Sequence diagram
 A sequence diagram indicates how events cause transitions from object to object.
 Once events have been identified by examining a use case and use case descriptions, then a sequence
diagram can be created.
 This is a representation of how events cause flow from one object to another as a function of time.
 In essence, the sequence diagram is a shorthand version of the use case and related description.
 It represents key classes and the events that cause behavior to flow from class to class.

An actor

An Object anObject:aClass

A Lifeline

A Focus of control

A Message aMessage()

Object destruction x
 Lifeline sd Dynamic View

HomeOwner
 Lifelines
 When drawing a sequence diagram, lifeline notation
elements are placed across the top of the diagram.
 Lifelines represent either roles or object instances that
participate in the sequence being modelled.
 Lifelines are drawn as a box with a dashed line
descending from the centre of the bottom edge (Figure
3).
 The lifeline's name is placed inside the box.

30
 Message
 The message sd Dynamic View

 A message is sent from sender to receiver, HomeOwner Sensors

directed line with solid arrow head

 The message represents an
operation/method that the receiving Request Activation() :int

object's class implements.

 HomeOwner is calling a method which has
been implemented in the class of sensor
object

Message
Message Return Value
sd class_1

HomeOwner Sensors

Request Activation() :int

Returning values
Self Message
sd Compare

HomeOwner Control Panel System

Read Data() :int

Get Password from Database()

Return passwprd()

Compare Result()

Message, own method

call
Alternatives, Loops and Break

sd Dynamic View sd Dynamic View

loop
alt Tries
[Maximum Try=3]
[Tries=3]

sd Dynamic View

break

[Entered password=Result]

34
 Conditional Behaviour
sd Compare

Hom eOwner Control Panel System

Read Data() :i nt

Get Password from Database()

Return passwprd()

Com pare Resul t()

Return com pari son resul t()

Instruct system about resul t()
alt passw ord chk

[i f password ok]

Lock the system ()

Alternative, if else condition

If password ok, send ok message to
system for activation, else, lock the
system
Example of loop and Break
 Safe home case study
[Reference: Roger A Pressman , “Software Engineering: A Practitioners’
Approach”, Chapter-5,6, pp. 130-140]

The SafeHome security function enables the homeowner to configure the security system when
it is installed, monitors all sensors connected to the security system, and interacts with the
homeowner through the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system. Each sensor
is assigned a number and type, a master password is programmed for arming and disarming the
system, and telephone number(s) are input for dialling when a sensor event occurs.
The homeowner receives security information via a control panel, the PC, or a browser,
collectively called an interface. The interface displays prompting messages and system status
information on the control panel, the PC, or the browser window.

37
 Safe home case study
[Reference: Roger A Pressman , “Software Engineering: A Practitioners’
Approach”, Chapter-5,6, pp. 130-140]
For basic SafeHome requirements, we define actors: homeowner (a user), setup manager (likely
the same person as homeowner, but playing a different role). For the purposes of this example,
we consider only the homeowner actor. The homeowner actor interacts with the home security
function in a number of different ways using either the alarm control panel or a PC:
 Initiate Monitoring via control panel.
 Inquires about the status of a security zone.
 Inquires about the status of a sensor.
 Presses the panic button in an emergency.
 Activates/deactivates the security system
 Access cameral surveillance system via internet
 Configure System
 View thumbnail snapshots for all cameras
 Configure floor plan
 Encountered an Alarm
38
 Safe home case study
[Reference: Roger A Pressman , “Software Engineering: A Practitioners’
Approach”, Chapter-5,6, pp. 130-140]
uc Use Case Model

SafeHome

Access Camera
Survelliance Via
the Internet

Configure safeHome Sensors

system parameter

Encounters an
error condition

Set Alarm
Home Owner

System activate

Responds to Alarm
event

System
Administrator

39
 Safe home case study
Detailed use case description

Use case: System Activate

Primary actor: Homeowner.
Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside.
Preconditions: System has been programmed for a password and to recognize various sensors.
Trigger: The homeowner decides to “set” the system, i.e., to turn on the alarm functions.
Scenario:
1. Homeowner: observes control panel
2. Homeowner: enters password
3. Homeowner: selects “stay” or “away”
4. Homeowner: observes read alarm light to indicate that SafeHome has been armed
Exceptions:
1. Control panel is not ready: homeowner checks all sensors to determine which are open; closes them.
2. Password is incorrect (control panel beeps once): homeowner re-enters correct password.
3. Password not recognized: monitoring and response subsystem must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated.
5. Away is selected: control panel beeps three times and an away light is lit; all sensors are activated.
Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors
Channels to secondary actors:
40
Support technician: phone line
Sensors: hardwired and radio frequency interfaces
 Safe home case study
Sequence diagram

41
 References
1. R. S. Pressman and D. Lowe: Web Engineering, A Practitioner’s Approach, McGraw-Hill, 2009.
 Chapter 8: WebApp Design
 Chapter 9: Interaction Design
(concentrate on the topics covered in the lecture)
2. Roger S. Pressman : Software Engineering: A Practitioners Approach. (8th Edition, 2014)

3. Essential Scrum—Kenneth S. Rubin

 4. The agile age-Managing projects effectively using agile scrum---Brian vanderjack

42