CHAPTER 6- AGILE METHODS AND PRACTICAL ASPECTS OF SOFTWARE ENGINEERING

Why need for agile methods for developing software?

1. Advent of technology  increase in complexity

2. Modern software handles data of million users.
3. Incapability of traditional software process models to handle large and complex software.

Agile Software Development

1. It refers to the software process models that are :
 People focused
 Communication oriented
 Flexible(ready to adapt to expected change at any time)
 Speedy(encourage rapid and iterative development of the product in small release)
 Lean(focuses on shortening timeframe and cost and on improved quality)
 Responsive(reacts appropriately to expected and unexpected changes)
 and learning (focuses on improvement during and after product development)
2. Some popular agile methods are :
 Pair Programming
 Scrum

Pair Programming
- It is a practice of software development wherein two programmers work in pairs to develop the software
while sitting at the same workstation. One programmer thinks and the other codes. Both programmers
keep swapping their roles.

- The keyboard owner is called the driver and is responsible for actual coding while their partner, called the
navigator, keeps track of larger issues in the application as they work.

Advantage of Pair Programming

1. Collective code ownership – pairs rotate frequently  both contribute by thinking and coding.
2. Better Code – Pair Programming  informal review process  code is looked by 2 people  code
review and inspection are more successful.
3. Increased discipline – Partners are less likely to take long breaks.
4. Resilient flow – Pair Programming more resilient to interruptions: as one programmer deals with the
interruption while the other keeps working.
5. Improved morale – Pair Programming, if done well, makes work more enjoyable.
6. Mentoring – Everyone learns from the other whether junior or senior.
7. Team Cohesion – People working in pair programming bring more solidity to the team.
8. More with less – With one less workstation, quality delivered is better, comparatively.

P a g e 1 | 12
 Drawbacks of Pair Programming

1. Different skills sets may kill the product – If the skills and experiences between partners are hugely
different, it may reduce productivity.
2. Disagreement may occur – Partners have own thinking patterns and working styles  may create
problem in reaching a consensus.
3. Scheduling Conflicts between partners – Different opinions about how much time to be given to
which components and it may derails the scheduling.
4. Absence of partners – If pair reduces to one, then its efficiency also reduces ten times.

Scrum

- It is an agile software product development strategy that organizes software developers as a team to reach a
common goal of creating a ready for market product.

Working of Scrum

- Scrum Software development team meet to discuss:

1. The backlog
2. What still needs to be completed.
3. How long it will take.

- Scrum relies on Sprints:

1. Sprints are periods of time when software development is actually done.
2. A sprint usually lasts from one week to one month to complete an item from the backlog.
3. The goal of each sprint is to create a saleable product.
4. Each sprint ends with a sprint review.
5. Then the team chooses another piece of backlog to develop – which starts a new sprint.
6. Sprints continue until the project deadline or the project budget is spent.

- Daily Scrum meetings conducted to discuss the progress made since the previous meeting and makes
plan for that day. Features of such meetings are:
 Brief meetings – no longer than 15 mins.
 Each team member needs to be present and prepared.
 The ScrumMaster keeps the team focused on the goal.

P a g e 2 | 12
The Scrum Team

- Should be self-organizing (should able to take independent decisions) and cross-functional (competencies
to accomplish work at hand, without depending on others outside team) .
- The three basic members are :
1. The Product Owner – manages the product backlog and optimise the value of the work of the
Development Team.
2. The Development Team – professionals who work to deliver a potentially releasable increment of
“Done” product at the end of each sprint.
3. The ScrumMaster – work with Scrum Team so that they can adhere to the Scrum theory, practices
and rules.

Scrum Events

Four main events are :

1. Sprints
2. Sprint planning meeting
3. Daily Scrum meeting
4. Sprint review

The Sprints
It is a time-box of one month or less during which a “Done”, usable, and potentially releasable product
Increment is created. The sprint is a container of other scrum events:
 Scrum planning meeting
 Daily Scrum meeting
 Sprint review

Sprint Planning Meeting

 The work to be performed in the Sprint is planned.
 This plan is created by the collaborative work of the entire Scrum Team.

Daily Scrum Meeting

 Brief meetings – no longer than 15 mins, for Development Team to synchronise activities and create a
plan for the next 24 hours.
 This meeting is held at the same time and place each day to reduce complexity.
 During each meeting, each Development Team member explains:
(i) What has been accomplished since the last meeting?
(ii) What will be done before the next meeting?
(iii) What obstacles are in the way?

Sprint Review
 Informal meeting
 Held at the end of the Sprint to inspect the Increment (What was done in the Sprint) and adapt the
Product Backlog if needed.

P a g e 3 | 12
Version Control Systems

- These are specific, specialized set of software tools that help a software team manage changes to source code
over time.
Purpose/Utility of Version Control System
1. Supports Partial Edits
- A version control system enables multiple people to simultaneously work on a single project.
- Main copy and work copies are stored separately. A member of software team works/edit their own
copy and does not work directly on the main copy.
- Thus, temporary/partial edits by one person do not interfere with another person’s work.
2. Supports Multiple Systems
- A person can work on their own copy irrespective of the system/computer they are working on.
3. Efficient Integration of Work
- It integrates the work done by different team members in an efficient way without losing any work.
4. Saves Multiple versions of Software
- It maintains the previous versions of the software project. Team can get access to historical versions of
their project.
- This feature insures team’s work against computer crashes or data loss.

Terminology used in Version Control System

1. Work Copy or Working Copy

- It is the personal copy of all the files in the project available to each user/developer of the project.
- When a developer is happy with the edits made by him/her, he/she commits the changes to a repository, i.e.
the changes are reflected in the central database.

2. Repository
- Also called Repo sometimes.
- Repository is a database of all the edits to, and/or historical versions (snapshots) of the software project.

3. Version
- Whenever some edits/changes are committed to the repository/database, a new version of the database
gets created.

4. Database History
- It stores multiple copies of the database storing each version of the database.
- Two types are:
(i) Linear History – each change to the database is made after the previous one.
(ii) Branching History – when different users make edits simultaneously. In this case, the version
history splits and then merges again.

P a g e 4 | 12
5. Commit/update
- Commit -> make changes from the working copy to the repository permanent. It means changes made
in the working copy will be reflected in the database.
- Update means, updating local working copy from the central repository.

6. Push/Pull Requests
- With distributed control systems, the commit works with the local repository of a developer and Push means
sending the committed changes to the global repository. Pushing can take place only after committing.
- Pull, does the opposite, i.e., updating local repository by pulling the changes available in the global repository.

Types of Version Control Systems

1. Centralised Version Control System
2. Distributed Version Control System

Centralised Version Control System

- Each user has own working copy, but there is only one repository, the central repository.
- Whenever a developer wants to make changes from his/her working copy to repository, he commits the changes
and these changes are reflected in the central repository.
- After every commit (from any developer) , the other members of his/her team can see the changes and updates
their own working copies.

P a g e 5 | 12
 Distributed Version Control System
- Multiple repositories.
- In fact, each developer has own copy of repository along with personal working copy.
- Whenever a developer commits changes, the changes are made permanent in his/her local repository. The other
team members can see these changes only if the developer pushes the changes from his/her local repository to
the central repository and then they pull these changes to their own local repository.

Advantages of distributed version control system

1. Modern
2. Fast
3. Less prone to errors
4. Lot of features

Disadvantage of distributed version control system

1. Complex
2. Difficult to understand

Some popular Version Control Systems

1. Git (a distributed version control system)

2. Mercurial (a distributed version control system)
3. Subversion (a centralized version control system)

Business Use-Case Diagram

- The use case diagram is one of the great tool that help business people to convey and the IT people to understand
the system. It is a requirement analysis concept and describes the system’s actions from the user point of view.
- It is formal way of representing how a business system interacts with its environment by illustrating the activities
that are performed by the users of the system.
- It does not specify the structure of the system.

Purpose of Use-Case Diagrams

- To determine the functional requirements of a system.

Types of Use-Cases
(i) Business Use- Cases that define the system at abstract level.
(ii) System Use-Cases that define the system at the implementation level.

P a g e 6 | 12
Elements of Use-Case Diagrams
1. Actor – It is a person or a thing, which are outside the system, and are involved in a task, e.g. in a banking system,
account holders are not part of the system but they are involved in banking tasks such as deposit, withdraw etc.
It is represented as a stick figure.

2. Use-case – It represents a task of the system with which actors interact, and is a way to depict one functionality
of the system. It is represented through an oval with the name of the use -cases in it.

3. Communication – It is the linking line joining an actor and its task, i.e. , a use-case. E.g.

4. Boundary of System – Represented by a Rectangle, which contains all use-cases together. And Actors are not
part of the system.
5. Types of relationship – Use-cases generally have relationships of following three types:
(i) <<include>> relationship – When a use-case must use another use-case, then such relationship is shown
as <<include>> relationship.

e.g.1. a patient getting admitted in a hospital must be registered first.So the use -case patient
admission(the base use-case) must include the use case patient registration (include use-case).

P a g e 7 | 12
 e.g.2. to authorize car loan (base use-case), the banking system must first check credit history (include
use-case) of the applicant. Thus,

(ii) <<extend>> relationship – When a use-case may call another use-case then this is extend relationship.
The base use-case in an extend relationship calls another use-case (called extension) if certain conditions
are met.
e.g., in a word processor, the Check Spelling use-case may call the use-case Add word to custom
dictionary.

(iii) Generalisation relationship – When two use-cases have a relationship such that one use-case represents
a general version of the functionality and the other use -case represents specific case of same
functionality, then this relationship is called Generalisation ( or parent-child relationship).This is shown
with a communication with a triangle pointing at parent .

e.g.1.

The Student admission use-case is the parent use-case and Open University admission and Regular
admission use-cases are the child use-cases.

e.g.2.

*The child use-case may add to or override the behaviour of its parent use-case.

P a g e 8 | 12
Sample use-case diagrams

1. Basic Hospital System use-case diagram

2. Basic Banking System use-case diagram

P a g e 9 | 12
Rules for creating Use-Case Diagrams

1. First, you must list main system functions (i.e. use cases) in a column. While doing so, do the following:
- Think of business events demanding system’s response.
- Users’ goals/needs to be accomplished via the system.
- Create, Read, Update, and Delete (CRUD) data tasks.
- Naming use-cases – user’s needs usually can be translated in data task.

2. Once you have decided and named the use-cases,

(a) Write names of use-cases (b) Draw ovals around the names of use-cases.

3. For each use-case, determine the main flow of functionality and relationships among them, if any.
4. Now draw system boundary around all the use-cases together.
5. Determine the actors and name them.
6. Outside the system boundary, draw actors and connect them with use cases.
7. Specify include and extend relationships between use cases.

Question: An online institute wants to develop a browser-based training system to help people prepare for a
certification exam. The basic working of this system would be:
 A user can request a quiz for the system. The system should randomly pick a set of questions
from its database, and compose a quiz out of it.
 User takes the quiz.
 System rates the user’s answers, and gives hints if the user request it.
 In the end of the quiz, a result report is generated.
 In addition to users, there are tutors who provide questions.
 There are subject-experts too who certify question to make sure they are not too trivial.

Solution:
1. Identifying use cases
(i) Take Quiz use-case
(ii) Provide hint use-case
(iii) Report result use-case
(iv) Add Questions use-case
(v) Certify Questions use-case
2. Identifying actors : User , Tutor , Subject-expert
3. Identifying relationships in use-cases

P a g e 10 | 12
Question: Draw a Use-case diagram depicting an ATM system.

Question: Draw a use-case diagram for an online Book store.

P a g e 11 | 12
Question: Draw a use-case diagram for a banking system.

P a g e 12 | 12