Agile Software engineering

1. Software Engineering
Dr. Jayashree Nair
Professor & Dean
School of IT

2. Syllabus Intended Learning Outcomes [ILOs]
reflecting domain specific
knowledge, cognitive skills and
non-cognitive skills.
(At the end of the module, students
will be able to …..)
Assessment Tools
(including Sessionals
and Prefinals)
Formative /
Summative
(at least one
formative
assessment
for a module)
Module - 01
Overview, Objectives,Three Perspectives on Software
Engineering , The Agile Manifesto, Principles of Agile,
Application of Agile Software Development
Teamwork: Overview, Objectives, A Role Scheme in
Agile Teams, Remarks on the Implementation of the
Role Scheme, Human Perspective on the Role Scheme,
Using the Role Scheme to Scale Agile Projects,
Dilemmas in Teamwork, Teamwork in Learning
Environments, Teaching and Learning Principles
Customers and Users: Overview, Objectives, The
Customer, Customer Role, Customer Collaboration, The
User, Combining UCD with Agile Development,
Customers and Users in
Learning Environments, Teaching and Learning
Principles, Customer Stories.
1.Describe the Agile manifesto and
its principles. *
2.Relate the principles of Agile to the
existing SD environment. *
3.Explain the various Agile methods
in SD. *
4.List out the objectives of
Teamwork. *
5.Explain about refactoring in an
Agile environment.*
6.Give the Pros and Cons of Pair
Programming technique in Agile
methods.*
MCQ 1
Sessional Exam
Pre Final Exam
FA
SA
SA

3. Syllabus Intended Learning Outcomes [ILOs]
reflecting domain specific
knowledge, cognitive skills and
non-cognitive skills.
(At the end of the module, students
will be able to …..)
Assessment Tools
(including Sessionals
and Prefinals)
Formative /
Summative
(at least one
formative
assessment
for a module)
SOFTWARE DESIGN:
• Design Diagrams: Use Case Diagrams - Class
Diagrams - Interaction Diagrams - State chart
Diagrams - Activity Diagrams
• Design Process- Design concepts : Abstraction,
Architecture, patterns, Separation of Concerns,
Modularity, Information Hiding, Functional
Independence, Refinement, Aspects, Refactoring.
• Object Oriented Design Concepts, Design Classes-
Design Model: Data, Architectural,
Interface, Component, Deployment Level Design
Elements ,
• Code review Analysis.
1.Design State chart diagramS
1.Design Use Case Diagrams
1.Design Interaction Diagrams
1.Design Activity Diagrams
MCQ 1
Sessional Exam
Pre Final Exam
FA
SA
SA

4. Software Engineering
Software engineering is the profession
that applies scientific knowledge in the
construction of software products needed
by customers that are:
1) on time
2) on budget
3) with acceptable performance
4) with correct operation

5. Software Product Attributes
•Maintainability
•Dependability
•Efficiency
•Usability
Efficiency vs Costs

6. Generic Software Process Models
•Waterfall
–Separate and distinct
phases of specification and
development
Efficiency vs Costs

7. Generic Software Process Models
Spiral Model

8. Generic Software Process Models
Prototyping Model

9. Software Industry
Problems
➔ Coping with change
➔ Software quality Management
of software projects
Solution
➔ Agile development -- enhances
and supports diversity
Outcome
➔ Better processes

10. Three perspectives of Software Engineering
❖ The Human perspective
➢ cognitive and social aspects
➢ Refers to learning and interpersonal
processes (teammates, customers,
management)
❖ The Organizational perspective
➢ managerial and cultural aspects
➢ refers to the workspace and issues that
spread beyond the team.
❖ The Technological perspective
➢ practical and technical aspects
➢ refers to how-to and code-related
issues. HOT
Organizational
Perspective
Technological
Perspective
Human
Perspective
Software
Engineering

13. The Agile Manifesto
❖ People - teammates, customers,
management
❖ high priority to the people who
participate in the development
process
❖ decision related to the
development process → influence
on people who are part of the
development environment, their
relationships and communication

14. The Agile Manifesto
❖ main target of software projects is to
produce quality working software
● Focus is on working s/w or solution
○ Documents only for essential
requirement and accessible to all
○ Actual development commences
early
○ S/W that business can see and give
feedback

15. The Agile Manifesto
● development process is based on an
on-going and on a daily basis
contract with the customer.
● enables to cope successfully with the
frequent changes that characterize
software projects.
● Creates agile culture

16. The Agile Manifesto
● establish a development process that
copes successfully with changes
○ customers cannot predict a-priori all
their requirements;
● Respond to change and refine plan
without much implications on cost
● Encourages team to spend more time
working than creating project plans

27. `

31. Application of Agile Manifesto to
Agile Projects

32. Agile in Practice
● Whole Teams
● Short Releases
● Time Estimation
● Measures
● Customer Collaboration
● Test Driven Development
● Pair Programming
● Refactoring

33. Whole team Approach
● project team (including all role
holders and the customer)
communicate in a face-to-face
fashion as much as possible.
● development team work in a
collaborative workspace
● all team members participate in the
actual process planning

34. Short Releases
● Short releases usually of 2-3
months
● short iteration usually of one or two
weeks
○ Business Days
■ Previous iteration review
■ Project status review
■ Planning of next iteration
● Customer feedback at the end of
each iteration

35. Measures
Monitoring process transparent and known to all project stakeholders
● ON-TIME OR SPEED OF DELIVERY
○ burndown and the burnup charts
● PRODUCT QUALITY
○ tracking customer satisfaction, steady revenue growth, and testing success
● PROJECT VISIBILITY
○ Transparency - providing plans ahead of actions available to everyone
● PREDICTABILITY
○ Velocity - how much work has been completed at a sustainable pace

36. Customer Collaboration
● Customer part of process
● Avoids need to speculate on
customer requirements
● all team members have access to the
customer during the entire process.
● helps the teammates to cope
successfully with changes

37. Test Driven Development
● Unit and acceptance tests are integrated
with development process
● Encourages developers to build automatic
unit and acceptance tests
○ Unit test written prior to coding
○ Functionality added to pass test
○ Helps control development process
● Acceptance tests lead to development of
products that meets customer requirements

38. Pair Programming
● Each code developed by 2 teammates
● There is personal responsibility
● HArd to be distracted and leads to focus
● Driver- works with keyboard, thinks at
lower level
● Navigator - thinks of development at
higher level
● All team members familiar with all
aspects of developed software

39. Refactoring
● Improving Design of Existing
Code without affecting
functionality
● Time is dedicated to improve
software readability
● Reduce complexity of code

83. Teamwork

84. Objectives
● Characteristics of Teams in agile s/w development
● Allocation of roles to team members
● Using benefits of role assignment at individual, team and organization levels
● Dilemmas in teamwork and mechanisms to overcome them
● Mechanism to achieve, empower and maintain agile team spirit
● Basic skills to exploit strength of agile teams

85. Team
● At least 2 members working towards common goal
● Each person is assigned a specific role to perform
● Completion of mission requires some dependency among team members
Software Project teams accomplish complex task of software development
● Software development is about a tangible product

86. Role Scheme
● Role Assignment
○ Each team member is assigned a specific role to perform
○ Each team member will have an additional role assigned to them in addition to
primary role
● Software development is complex
○ Project management and progress split amongst all team members
○ BEnefits for individual, company and project

87. Role Groups

88. Role Groups

89. Role Groups

90. Role
Groups/Schemes
in Agile Projects

91. Role Scheme
● How does role scheme reflect HOT properties of Agile methods
● How is role scheme related to Agile MAnifesto
● What are benefits of role rotation

92. Dilemmas in Team work
● Allocation of incentives, rewards and bonuses
○ Teamwork is a basic working assumption is agile development
○ Team members cooperate, share information and exchange feedback with
each other
■ measuring individual performance is usually counter-productive
■ Major reason for conflicts
Dilemmas and conflicts associated with teamwork should be discussed openly
by all team members, and a solution that meets the needs of the individuals as
well as the entire team should be established.

93. Dilemmas in Team work
● Everyone gets X% of their salary as a bonus
● Distribute bonus evenly among team members
● Let team decide how bonus should be distributed

94. Rewards in Agile Teams
● rewards should encourage teamwork rather than individual
performance
● individual rewards maybe smaller in relation to team rewards.
● handwritten notes like thanking a team member for something special
and specific they did can do wonders for an individual
● Time - a team can be offered an incentive
★ a week off if they meet some delivery milestone.
★ choosing work of their choice in a sprint

95. Role Maintenance Activities
Activities performed on daily basis to enable entire team understand progress of the project
● Standup meetings
○ Individual performance
○ Expectations from team
● Presentation to customers
○ Present tasks of iteration
○ Individual contribution to task achievement
● Feedback from customers
○ With all team members
○ Personal reflection

96. Customers and Users

97. Customers’ Role in Agile
Consulting with customers is at the heart of an Agile enterprise.

98. Customers Collaboration over contract
Negotiation
● Customer is at the heart of
the agile enterprise
● Agile process supports
customer’s role
● Enhancing Communication
with Customers
● Customer feedback to
increase product quality

99. Customer
● Customer may be one who pays for the product or has
business interests
● It is based on ongoing communication between the customer
and the team members
● Communication to facilitate
○ the requirements gathering
○ The way testing is performed and
○ Achieving suitability of the developed product

100. User
● They are the main clients
● HCI - Human Computer Interaction
● User perspective considered from beginning of product
development life cycle
Customer Group
● User Evaluator
● Customer
● Acceptance Tester

101. Customer Role
The customer is involved in
the development process
continuously
1. Setting Project Release
Schedule

102. Project Release Planning
● The architects present
their vision about
○ the product architecture
○ the existing architecture
○ anticipated changes.
● Customer describes
○ the project vision
○ the project main
stories
○ the guidelines
according to which
development
priorities will be
set.

103. Project Release Planning
● Other stakeholders
present their expectations
from the development
process.
● The project manager
presents
○ his or her view of
the development
process
○ the working
environment
○ his/her personal
expectations.

104. Business Day
● Discuss the development tasks of each iteration
● Takes place between each two consecutive iterations and
releases
● The rest of the iteration days are development days

105. Business Day
● All project stakeholders are invited to participate
○ Team, customer, managers, external members, users
● Planned to eliminate pressure over weekends
● Business Day Activities
○ presentation of the accomplishments of the ending iteration;
○ measures’ review;
○ customer feedback;
○ Reflective session;
○ planning of the next iteration.

106. Business Day Activities
○ presentation of the accomplishments of the ending
iteration;
○ measures’ review;
○ customer feedback;
○ Reflective session;
○ planning of the next iteration.

107. Presentation of the System
● Main features developed as per user stories for the ended iteration is
presented
● User story
○ should be understandable to customers and developers,
○ Is a unit of functionality of the product
○ Is implemented as a tested and integrated code
○ Is small enough such that many stories can be implemented
in an iteration
‘‘The most important stories to do first are the ones that contain the highest
business value.”

108. Presentation of the system
1. Make sure the system is fully integrated and includes all stories of
the ending iteration and is deployable
2. Ensure Customers and users are aware of all the features of the
system
3. Each team member presents his/her work - to raise accountability
4. Overall understanding of project components and features is
increased

109. Business Day Activities
○ presentation of the accomplishments of the ending
iteration
○ measures’ review
○ customer feedback
○ Reflective session
○ planning of the next iteration.

110. Mesures Review
Presentation and analysis of ending iteration metrics
● Present data to the entire team, by facts
● Discuss reason behind the metrics
● Ensure customer is aware of the process and progress

111. Mesures Review
Presentation and analysis of ending iteration metrics
■ Product metrics (no of written and passed tests)
■ Pulse metrics (continuous integration)
■ Burn-down metrics (measure of achieving
iteration goals)
■ Fault metrics (measure of new and open defects)

112. Business Day Activities
○ presentation of the accomplishments of the ending
iteration
○ measures’ review
○ customer feedback
○ Reflective session
○ planning of the next iteration.

113. Customer Feedback
○ a short, informal verbal summary of the iteration given
by the customer
○ Focus on product rather than process
○ Customer’s message to be included in iteration
summary

114. Business Day Activities
○ presentation of the accomplishments of the ending
iteration
○ measures’ review
○ customer feedback
○ Reflective session
○ planning of the next iteration.

115. Reflective Session
○ Discuss issues in the development model
○ Kind of timeout session

116. Business Day Activities
○ presentation of the accomplishments of the ending
iteration
○ measures’ review
○ customer feedback
○ Reflective session
○ planning of the next iteration.

117. Planning Next Iteration
○ Begins of summary of previous iteration and the
reflective sessions
○ Customers, team members and interested persons can
attend

118. Planning Next Iteration
1. Customer tells the stories that were prepared in advance
to be developed in the next iteration
2. In addition the following are also added
a. Incomplete stories of previous iteration
b. Refactoring tasks
c. User stories that emerged from Business day
activities

119. Planning Next Iteration
3. Customer has to prioritize the stories
4. Development time of each of these tasks is estimated by
the developers who take ownership of them
5. The actual planning is set according to the available time
of the team members
6. The development loads are balanced among the
developers.

120. The User
HCI
➔ interface design and evaluation
➔ the interactions between users and systems
(hardware and/or software)

121. The User
Usability of a product - the extent to which a product can be
used by specified users to achieve specific goals with
● Effectiveness
● Efficiency
● Satisfaction

122. Integration of User with development environment
UCD- User Centric Design
● Experience is King
● Focus is on gaining a deep
understanding of who will be using the
product.
● Design techniques that emphasize user
needs during design of user interface
● Design designs can be validated and
tested

123. Why UCD?
● Design decisions can be validated and tested
● Guesswork is minimised
● Quality of experience vs. No. of features
○ Iphone vs Nokia?
● Create products for competitive market

124. Agile and UCD
Agile UCD
satisfy the customer through early and
continuous delivery of valuable software
create an experience for end-users
where they can achieve their goals
easily and efficiently
Working software is the primary
measure of progress
The satisfaction of end-user needs (user
goals) balanced with the achievement of
business goals is the primary measure
of success
Deliver working software frequently end-user experience could be poor or
worse

126. Business Day

127. Project Planning