0% found this document useful (0 votes)
13 views52 pages

Agile Practical File Ekansh

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views52 pages

Agile Practical File Ekansh

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 52

DAV INSTITUTE OF ENGINEERING AND

TECHNOLOGY
JALANDHAR

ADHOC WIRELESS AND


SENSOR NETWORKS LAB
Lab File
(BTCS 711-18)

Submitted To : Submitted By:

Mr. Sahul Goyal Name: Ekansh Mahajan


Course: B. Tech
INDEX

S.NO. EXPERIMENTS Page No. Remarks

Understand the
1 3-5

background and
driving forces for
taking an agile
approach to
software
development
Understand the
background and
driving forces for
taking an agile
approach to
software
development
2
Understand the
background and
driving forces for
taking an agile
approach to
software
development
Understand the background and driving forces for taking
an Agile Approach to Software Development.

2 Build out a backlog and user stories. 6-8

3 To study and use automated build tool. 9-13


4 To study-- version control tool. 14-15

5 To study Continuous Integration tool. 16-18


6 Apply Design principle and Refactoring to achieve 19-22
agility.
7 Perform Testing activities within an agile project. 23-26

8 Mini Project: based on tools 27-35

3
Task 1: Understand the background and driving forces for taking an Agile Approach
to Software Development.

Theory: The Agile software


development approach has
become the standard for
modern
software development,
providing organizations
with the flexibility and
responsiveness they need
to meet the changing
demands of the software
4
development
landscape .Agile is a time-
bound,
iterative approach to
software delivery that
builds software
incrementally from the start
of the
project, instead of trying to
deliver all at once
Theory: The Agile software development approach has become the standard for modern
software development, providing organizations with the flexibility and responsiveness
they need to meet the changing demands of the software development landscape . Agile is
a time-bound , iterative approach to software delivery that builds software incrementally
from the start of the project, instead of trying to deliver all at once

Principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of
months ,with a preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the
support they need, and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.

5
7. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation

AGILE SDLC PROCESS FLOW:


1. Concept: Projects are imagined and prioritized.
2. Inception: Team members are created, funding is put in place, and basic environments
and requirements are discussed.
3. Iteration/Constriction: The software development team works to deliver working
software. It is based on requirement and feedback.
4. Release: Perform quality assurance (QA) testing, provides internal and external
training , documentation development, and final version of iteration into the product.
5. Production: It is ongoing support of the software

The following provides a practical understanding of the background and driving


forces behind the adoption of the Agile approach:
1. Customer satisfaction: Agile development places a strong emphasis on continuous
feedback from customers and stakeholders, enabling teams to quickly respond to changing
requirements and deliver value. This approach leads to higher customer satisfaction
because the customer is involved in the development process and can see the product
evolving and responding to their needs.
6
2. Flexibility: Agile development allows teams to adapt to change and respond quickly to
shifting priorities and new information, making it ideal for complex and rapidly changing
environments. The Agile approach is designed to be flexible, with a focus on delivering
value incrementally and iteratively, making it easier for teams to adapt to changing
requirements.
3. Collaboration: Agile development encourages collaboration between cross-functional
teams, including developers, product owners, and stakeholders, leading to better decision-
making and faster delivery. Teams work together to define and prioritize requirements,
and regular meetings, such as daily stand-ups, help keep everyone on the same page.
4. Quality: Agile development prioritizes regular testing and inspection, enabling teams to
catch and fix defects early in the development process, leading to higher-quality software.
By regularly testing and inspecting code, teams can catch and fix defects early, reducing
the risk of more serious and expensive problems down the line.
5. Predictable delivery: Agile development uses iterative development cycles and
frequenter leases, allowing teams to make steady progress and deliver value to customers
faster. The Agile approach provides a more predictable delivery schedule, with regular
releases and a focus on delivering value incrementally, enabling teams to meet customer
needs and expectations.
6. Increased productivity: The Agile approach focuses on delivering value incrementally
and iteratively, enabling teams to work more efficiently and effectively. Teams are
empowered to make decisions and take ownership of their work, leading to increased
motivation and productivity.
Advantages:
●Deployment of software is quicker and thus helps in increasing the trust of the customer.
●Can better adapt to rapidly changing requirements and respond faster.
●Helps in getting immediate feedback which can be used to improve the software in the
next increment.
●People – Not Process. People and interactions are given a higher priority rather than
process and tools.
●Continuous attention to technical excellence and good design.
Disadvantages:
●In case of large software projects, it is difficult to assess the effort required at the initial
stages of the software development life cycle.
●Agile Development is more code focused and produces less documentation.

7
●Agile development is heavily dependent on the inputs of the customer. If the customer
has ambiguity in his vision of the final outcome, it is highly likely for the project to get off
track.
●Face to Face communication is harder in large-scale organizations.
●Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it’s a difficult situation for new programmers to adapt to the
environment.

The following provides


a practical
understanding of the
background and
driving forces behind
the adoption of the
Agile approach:
1. Customer satisfaction:
Agile development places a
strong emphasis on
continuous

8
feedback from customers
and stakeholders, enabling
teams to quickly respond to
changing requirements and
deliver value. This approach
leads to higher customer
satisfaction because the
customer is involved in the
development process and
can see the
product evolving and
responding to their needs.
2. Flexibility: Agile
development allows teams
to adapt to change and
respond quickly to

9
shifting priorities and new
information, making it ideal
for complex and rapidly
changing
environments. The Agile
approach is designed to be
flexible, with a focus on
delivering
value incrementally and
iteratively, making it easier
for teams to adapt to
changing
requirements.
3. Collaboration: Agile
development encourages
collaboration between
cross-functional
10
teams, including
developers, product
owners, and stakeholders,
leading to better
decision-making and faster
delivery. Teams work
together to define and
prioritize
requirements, and regular
meetings, such as daily
stand-ups, help keep
everyone on the
same page.
4. Quality: Agile
development prioritizes
regular testing and

11
inspection, enabling teams
to
catch and fix defects early
in the development
process, leading to higher-
quality software.
By regularly testing and
inspecting code, teams can
catch and fix defects early,
reducing
the risk of more serious and
expensive problems down
the line.
5. Predictable delivery:
Agile development uses
iterative development
cycles and frequent
12
releases, allowing teams to
make steady progress and
deliver value to customers
faster.
The Agile approach
provides a more predictable
delivery schedule, with
regular releases
and a focus on delivering
value incrementally,
enabling teams to meet
customer needs
and expectations.
6. Increased productivity:
The Agile approach focuses
on delivering value
incrementally
13
and iteratively, enabling
teams to work more
efficiently and effectively.
Teams are
empowered to make
decisions and take
ownership of their work,
leading to increased
motivation and
productivity.
The following provides
a practical
understanding of the
background and

14
driving forces behind
the adoption of the
Agile approach:
1. Customer satisfaction:
Agile development places a
strong emphasis on
continuous
feedback from customers
and stakeholders, enabling
teams to quickly respond to
changing requirements and
deliver value. This approach
leads to higher customer
satisfaction because the
customer is involved in the
development process and
can see the
15
product evolving and
responding to their needs.
2. Flexibility: Agile
development allows teams
to adapt to change and
respond quickly to
shifting priorities and new
information, making it ideal
for complex and rapidly
changing
environments. The Agile
approach is designed to be
flexible, with a focus on
delivering
value incrementally and
iteratively, making it easier

16
for teams to adapt to
changing
requirements.
3. Collaboration: Agile
development encourages
collaboration between
cross-functional
teams, including
developers, product
owners, and stakeholders,
leading to better
decision-making and faster
delivery. Teams work
together to define and
prioritize
requirements, and regular
meetings, such as daily
17
stand-ups, help keep
everyone on the
same page.
4. Quality: Agile
development prioritizes
regular testing and
inspection, enabling teams
to
catch and fix defects early
in the development
process, leading to higher-
quality software.
By regularly testing and
inspecting code, teams can
catch and fix defects early,
reducing

18
the risk of more serious and
expensive problems down
the line.
5. Predictable delivery:
Agile development uses
iterative development
cycles and frequent
releases, allowing teams to
make steady progress and
deliver value to customers
faster.
The Agile approach
provides a more predictable
delivery schedule, with
regular releases
and a focus on delivering
value incrementally,
19
enabling teams to meet
customer needs
and expectations.
6. Increased productivity:
The Agile approach focuses
on delivering value
incrementally
and iteratively, enabling
teams to work more
efficiently and effectively.
Teams are
empowered to make
decisions and take
ownership of their work,
leading to increased
motivation and
productivity.
20
Task 2: Build out a backlog and user stories.

Product Backlog

The product backlog is the list of all the work that needs to get done. It usually
contains user stories, bugs, technical tasks, and knowledge acquisition. The
backlog is periodically refined by the product owner and scrum team to ensure
2–3 sprints worth of work is always defined and prioritized.

A solid backlog should be DEEP:

 Detailed: Sufficiently detailed such that any member of the scrum team can
work on the user stories independently
 Emergent: Flexible, work will fluctuate based on the needs of the team,
business, or customer
 Estimated: Size and complexity is estimated using story points — If a story
comes with a high estimate, it is likely large enough to break apart into more
than one user story
 Prioritized: User stories are ordered in the backlog based on product priority
— If all stories in the sprint are completed early the team should pull in the
next user story on the backlog

Backlog refinement sessions are led by product managers. You will always want
your user stories to meet the INVEST criteria. Some simple tips to make that
refinement meeting run smoothly:

 Invite the whole team! That includes UX, testers, etc


 Have your user stories written and distributed to the team so they can review
before the refinement session
 Prioritize the user stories
 Limit conversation per user story using a timer — if it takes longer than the
allotted
o time you probably need to go back and define the user story better
 Estimate a reference story so that you can estimate the rest of your stories
relative to the reference
 Spend enough time on refinement — if you’re just starting out you may need
21
to spend a couple of full days to refine the backlog

User Stories

User stories are simple, powerful constructs that describe functionality from the
point of view of your user. Simple enough! They usually look something like
this:
 As a <role or personal>, I can <goal or need>, so that <why>
 As a <user class>, I want to <perform or do something>, so that <I get
some value or benefit>

User stories need to meet specific criteria to be considered “ready” by the scrum
team. The most popular is INVEST:

 Independent: The lowest level of functional decomposition — they should


stand on their own and allow for the business to change direction with
minimal cost and impact to emerging requirements

 Negotiable: High level enough that implementation is flexible — there


should be enough room to inspect and adapt the implementation based on
constraints and business requirements

 Valuable: Demonstrated value to the business and the user — each user story
represents an increment of product that can be demonstrated to a potential
customer of the system

 Estimable: Sufficient knowledge about how the user story will be developed
(and tested) that the scrum team can provide a high-level estimate for how
long the user story will take to implement

 Sized to Fit: Such that the work to deliver the user story can be completed in
a sprint to facilitate faster time to market and feedback from customers

 Testable: Using well-defined acceptance criteria prior to any implementation


work — what will it take to satisfy our customer’s need and how will we
verify that those needs have been met

Let’s expand on testable criteria. Every great user story has even better
acceptance criteria! Acceptance criteria is focused on the intended outcome as a
result of the action specified in the user story. It should always focus on “what”
instead of “how”. Here is a simple format to follow when writing your
22
acceptance criteria:

 Given <some pre-condition(s)>, when <some action(s)>, then <expected


result/behavior>

 Pre-conditions are optional — they don’t always exist

Sample User Stories

Online Banking Application:

User Role User or Customer


Goal To be Refunded
Reason Money deducted but not received on the other end
Acceptance 1. The sender has valid transaction ID
Criterion 2. Users should be notified and be able to track
refunds.

User Role User or Customer


Goal To register with application
Reason To be registered with an app and be able to access and
use it.
Acceptan 1. Users can only submit the forms once by
ce filling it completely.
Criterion 2. Users will receive a notification email after
successful registration of the user.

User Role User or Customer


Goal To transfer funds/money
Reason One user is able to send money to another user.
Acceptan 1. Users should be registered with the application.
ce 2. His/her bank account should be linked
Criterion with the application.
3. The bank account should have enough money to
transfer the funds.

23
Task 3: To study and use automated build tool.

Automated Build Tool is a software that compiles the source code to


machine code. Automation tools are used to automate the whole process of
software build creation and the other related processes like packaging binary
code and running the automated tests. HERE are some automated build tools:-

Jenkins

Price: Free

Fig.1 Jenkins

Jenkins is an open-source tool. It can perform the task of building, testing, and
deploying software. The platform is easy to install. For any project, Jenkins will
work as a CI server and as a continuous delivery hub. It has features of
extensibility and easy configuration.

24
Features:
o Testing of isolated changes in a larger codebase.
o Automation of testing of builds.
o Work Distribution.
o Automation of software deployment.
Verdict: You will get good community support for Jenkins. It supports all major
platforms. It
can test and deploy on multiple platforms at a fast rate. It can distribute the work
across multiple machines.

25
Best for small to large businesses.

Website: Jenkins

Maven

Price: Free

Fig 2 Maven

Maven is an application that provides functionalities for project management. It


has functionalities for project building, reporting, and documentation. You will
be able to access the new features instantly. It is extensible through plugins.
There will be no limitation on building the number of projects into a JAR,
WAR, etc.

Features:
o It supports working on multiple projects simultaneously.
o There will be consistent usage for all projects.
o It has features for dependency management.
o It provides a large and growing repository of libraries and metadata.
o It provides functionality for release management: It can distribute individual
outputs.
o For managing the releases and distributing the publications, Maven will
get integrated with your system. No additional configuration will be
required for this.
Verdict: As per the customer reviews, the tool is good for build automation and
dependency management. For dependency management, it provides support to
the central repository of JARs.
Best for small to large businesses
26
Website: Maven

Gradle
Price: Gradle offers a free trial of 30 days for Gradle Enterprise. You can
contact the company for the pricing of Enterprise subscriptions.

Fig 3 Gradle

Gradle can be used for multiple project types i.e. mobile apps to microservices.
It has functionalities for building, automating, and delivering software. It is an
open-source platform. For dependency management, it provides the
functionalities like transitive dependencies, custom dependency scopes, file-
based dependencies, etc.

Features:
 For software development, it will allow you to use any programming language.
 It can deploy on any platform.
 It supports monorepos as well as multi-repo strategy.
 It will help you to deliver continuously.
 It has various execution options like Continuous build, Composite
Builds, Task Exclusion, Dry Run, etc.
Verdict: As per the customer reviews it has good integration capabilities.
Gradle has features of web-based build visualization, collaborative debugging,
parallel execution, incremental builds, task time outs, etc.
Best for small to large businesses

Website: Gradle

Travis CI

Price: It is free to test open-source projects. It provides the first 100 builds for

27
free. There are four pricing plans i.e. Bootstrap ($69 per month), Startup ($129
per month), Small Business ($249 per month), and Premium ($489 per month).

Fig 4 Travis CI

GitHub projects can be synced with Travis CI. It can perform auto deployments
on passing the builds. It will be able to deploy on multiple cloud services. The
tool can be used by signing up and linking the repository. It will allow you to
build the apps and test them.

Features:
 GitHub integration.
 It has pre-installed database services.
 It supports pull requests.
 It will provide a clean VM for every build.
Verdict: Travis CI is easy to install and configure. It has a clean interface. This tool
will be
the best option if you are creating an open-source project as it provides free
services for open- source projects.
Best for small to large businesses

Website: Travis CI

Bamboo

Price: The price of Bamboo will be based on the number of agents. An increase
in the number of agents will increase the number of processes that can run
concurrently. It provides a free trial of 30 days. Bamboo offers two pricing plan

28
i.e. for small teams and growing teams.
The plan for small teams will cost you $10 (No remote agent) for a maximum
of 10 jobs. The plan for growing teams will cost you $1100 (One remote agent)
with unlimited jobs.

Fig 5 Bamboo

Bamboo is a continuous delivery tool that can be used from coding to


deployment. It has functionalities to build, test, and deploy projects. It can be
integrated with Jira, Bitbucket, and Fisheye. It has a clean user interface and is
intuitive.

Features:
 It will allow you to create multi-stage build plans.
 You can assign agents to critical builds and deployments.
 The tool can run parallel automated tests.
 It can release in each environment.
 While releasing, the flow can be controlled through pre-environment settings.
Verdict: With this tool, all tasks like automated builds, tests, and releases can be done
in one
workflow. It has various built-in capabilities and doesn’t require plugins.
Best for small to large businesses.

29
Task 4: To study version control tool.

Introduction

Version control — also known as source control or revision control — is an


important software development practice for tracking and managing changes
made to code and other files. It is closely related to source code
management.
With version control, every change made to the code is tracked. This allows
developers to see the entire history of who changed what at any given time
— and roll back to an earlier version if they need to. It also creates a single
source of truth.
Version control (or source control or revision control) serves as a safety net
to protect the source code from irreparable harm, giving the development
team the freedom to experiment without fear of causing damage or creating
code conflicts.
Version control enables teams to collaborate and streamline development to
resolve conflicts and create a centralized location for code

Use of version control tools

As organizations accelerate delivery of their software solutions through


DevOps, controlling and managing different versions of application artifacts —
from code to configuration and from design to deployment — becomes
increasingly difficult.

Version control software facilitates coordination, sharing, and collaboration


across the entire software development team. It enables teams to work in
distributed and asynchronous environments, manage changes and versions of
code and artifacts, and resolve merge conflicts and related anomalies.

Version Control system

A version control system (VCS) tracks changes to a file or set of files over time.
The most common type is a centralized VCS, which uses a server to store all the
versions of a file. Developers can check out a file from the server, make
changes, and check the file back in. The server then stores the new version of
the file.

Types of version control systems

The two most popular types are centralized and distributed. Centralized version
control systems store all the files in a central repository, while distributed
version control systems store files across multiple repositories. Other less
30
common types include lock-based and optimistic.

31
Lock-Based: A lock-based version control system uses file locking to manage
concurrent access to files and resources. File locking prevents two or more users
from making conflicting changes to the same file or resource.

Optimistic: In an optimistic version control system, every user has their own
private workspace. When they want to share their changes with the rest of the
team, they submit a request to the server. The server then looks at all the
changes and determines which ones can be safely merged together.

Centralised: A centralized version control system (CVCS) is a type of VCS


where all users are working with the same central repository. This central
repository can be located on a server or on a developer's local machine.
Centralized version control systems are typically used in software development
projects where a team of developers needs to share code and track changes.

Distributed: A distributed version control system (DVCS) allows users to


access a repository from multiple locations. DVCSs are often used by
developers who need to work on projects from multiple computers or who need
to collaborate with other developers remotely.

Benefits of version control

Quality: Teams can review, comment, and improve each other’s code and assets.
Acceleration: Branch code, make changes, and merge commits faster.
Visibility: Understand and spark team collaboration to foster greater release
build and release patterns.

Some main version control systems

The three most well-known version control tools are Git, Subversion, and Mercurial.

Git
Git is the most popular option and has become synonymous with "source code
management."Git is an open source distributed system that is used for software
projects of any size, making it a popular option for startups, enterprise, and everything
in between.

Subversion
SVN is a widely adopted centralized VCS. This system keeps all of a project's
files on a single codeline making it impossible to branch, so it's easy to scale for large
projects. It's simple to learn and features folder security measures, so access to
subfolders can be restricted.

Mercurial
Mercurial is a distributed VCS that offers simple branching and merging
capabilities. The system enables rapid scaling and collaborative development, with
an intuitive interface. The flexible command line interface enables users to begin
using the system immediately.
32
Task 5: To study Continuous Integration tool.

Introduction

Continuous integration (CI) is an agile and DevOps best practice that enables
multiple developers to contribute and collaborate in a shared code base at a rapid
pace. Without continuous integration, developer collaboration is a tedious manual
process of coordinating code updates and merges.

Four pillars of Continuous Integration

Source Control Version Management: Probably the most important foundational


pillar of continuous integration is source control version management. It is used to
communicate and resolve editing conflicts between multiple developers working in
the same codebase. Source control version management comes in a variety of tools,
the most popular being Git and Subversion. CI-as-a-service products center around
the version control system.

Automated testing: Most serious software projects include an additional code base
that is not explicitly responsible for the business product and features. This
secondary code base is a test suite and acts as a set of assertions that assures
the primary code base is working correctly without bugs. During development,
these tests are run by developers to validate that new code has not caused any
regression on existing features. These test cases can also be run by extraneous tools
to automate this validation process. CI service products will automatically run the
test cases for a project on user-specified events. Generally, when a developer pushes
code using the version control system an event will trigger the full test suite to run
automatically.

Build Automation: “Builds” are the artifacts created to snapshot the current release
version of a software project. Builds are distributed to end users through various
networks. There is generally a set of scripted steps a project will take to create a
build artifact. CI tools help streamline this build process with the use of automatic
triggers from the version control system. One example trigger would be when new
code is merged to the production branch of the codebase upload the build to a
remote server for users to download.

33
Automated Deployments: When builds are ready to be distributed they go through
a deployment process. Depending on the project deployment can have a variety of
outcomes. For example, web projects are deployed to publicly accessible web
servers. During this deployment, the artifact that was generated in the build phase is
copied onto the web servers. The deployment process for mobile and desktop vary
and may involve uploading to a ‘store’ so users may download the app.
Continuous Integration Tools

Bitbucket Pipelines
Bitbucket Pipelines is a CI tool directly integrated into Bitbucket, a cloud version
control system offered by Atlassian. Bitbucket Pipelines is an easy next step to
enable CI if your project is already on Bitbucket. Bitbucket Pipelines are managed
as code so you can easily commit pipeline definitions and kick off builds. Bitbucket
Pipelines, additionally offers CD. This means projects built with Bitbucket Pipelines
can be deployed to production infrastructure as well
Website: https://bitbucket.org/product/features/pipelines

Jenkins
Jenkins is a veteran CI Tool with a long proven track record. It is open source and
driven by community updates. Jenkins is primarily intended to an on-premise
installation. Jenkins is a great option when your organization needs on-prem support
for handling sensitive customer like HIPAA compliance data.

Website: https://jenkins.io/

Circle CI
Circle CI is CI Tool that gracefully pairs with Github, one of the most popular
version control system cloud hosting tools. Circle Ci is one of the most flexible CI
Tools in that it supports a matrix of version control systems, container systems, and
delivery mechanisms. Circle Ci can be hosted on-premise or used through a cloud
offering.

Website: https://circleci.com/

GitLab
Gitlab is a new CI Tool which offers a full DevOps experience. Gitlab was created
with intentions to improve Github’s overall experience. Gitlab offers a modern UX
with container support.
34
Website: https://about.gitlab.com

Atlassian Bamboo
Another CI offering from Atlassian. Whereas Bitbucket Pipelines is purely a cloud
hosted option, Bamboo offers a self hosted alternative

35
Task 6: Apply Design principle and Refactoring to achieve agility.

DesignPrinciple

1. Single-Responsibility Principle
“There should be never more than one reason for a class to change.”

As you can see, this principle states that an object/class should only have one
responsibility and that it should be completely encapsulated by the class. Here,
when we talk about a responsibility, we mean a reason to change. This principle
will lead to a stronger cohesion in the class and looser coupling between
dependency classes, better readability, and code with lower complexity.
It is much more difficult to understand and edit a class when it has various
responsibilities. So if we have more than one reason to change, the
functionality will be split into two classes and each will handle its own
responsibility.
We care about separating the functionalities because each responsibility is an
access of change. When a class has more than a single responsibility, those
responsibilities become coupled and this coupling can lead to a fragile code base
that is difficult to refactor when your requirements emerge.

2. Open-Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification.”

Here, the idea is that an entity allows its behavior to be extended but never by
modifying its source code. Any class (or whatever you write) should be written
in such a way that it can be used as is. It can be extended if need be, but it can
never be modified. You can consider this when you are writing your classes.
Use the class in any way you need, but modifying its behavior comes by adding
new code, never by modifying the old. The same principle can be applied to
modules, packages, and libraries.
By applying the open-closed principle you will get a loose coupling, you
will improve readability and, finally, you will be reducing the risk of
breaking existing functionality.

3. Liskov Substitution Principle


“Subtypes must be substitutable for their base types.”

As its name says, Liskov's Substitution Principle was defined by Barbara


Liskov. The idea here is that objects should be replaceable by instances of their
subtypes without affecting the functioning of your system from a client’s point
36
of view. Basically, instead of using the actual implementation, you should
always be able to use a base class and get the result you were waiting for. Often
when we want to represent an object, we model our classes based on their
properties, but, instead of that, we should actually be putting more of our focus
on the behaviors.
This principle basically confirms that our abstractions are correct and helps us
to get code that is easily reusable and class hierarchies that are very easily
understood.
What many say is that Liskov’s Substitution Principle has a very strong relation
with the previous principle, the Open-Closed Principle. Robert C. Martin even
says that “a violation of LSP is a latent violation of OCP.”

4. Interface Segregation Principle


“Classes that implement interfaces, should not be forced to implement
methods they do not use.”

Here, it’s about how to write interfaces. So what is stated? Basically, once an
interface is becoming too large/fat, we absolutely need to split it into small
interfaces that are more specific. And the interface will be defined by the client
that will use it, which means that the client of the interface will only know
about the methods that are related to them.
Actually, if you add methods that shouldn’t be there, the classes implementing
the interface will have to implement those methods as well. That is why the
client shouldn’t be forced to depend on interfaces that they don’t use. ISP is
intended to keep a system decoupled and thus easier to refactor, change, and
deploy.

5.Dependency Inversion Principle


“High-level modules should not depend on low level modules, rather both
should depend on abstraction. Abstraction should not depend on details;
rather detail should depend on abstraction.”

The last of the SOLID principles, but not the least, this principle is primarily
concerned with reducing dependencies amongst the code modules. Basically,
the Dependency Inversion Principle will be of a great help when it comes to
understanding how to correctly tie your system together.
If your implementation detail will depend on the higher-level abstractions, it
will help you to get a system that is coupled correctly. Also, it will influence
the encapsulation and cohesion of that system.

37
Refactoring

Refactoring code is changing code with two crucial constraints:

1. The changes make the code easier to understand and thus cheaper to modify.
2. The changes never change the functionality, the observable behavior, of the
code.

That second constraint bears repeating: a refactoring should never change the
behavior of a program. This means that if the program is called before and
after a refactoring with the same set of inputs, the resulting set of output
values will be the same.

Code refactoring aims to keep software from degrading, or, when it’s already
degraded, to improve its design so it becomes easier to understand and change.
Code refactoring is important to eliminate design flaws, achieve
maintainability, and extensibility of a software system.
Crucially, code refactoring changes the design of the code, but never the
behavior of the software. Never the twain shall mix.
The Process of Refactoring

To minimize the likelihood that you’ll accidentally introduce bugs as part of


your refactoring, you want to follow a strict process.

38
1. Ensure you can back out — restore to a version that was proven to work
correctly. Make sure you’ve committed all your changes and all tests
against the committed code succeed. This way you can restore back to
this point if your refactoring doesn’t go as you envisioned.
2. Identify what you want to refactor and how — which refactorings to use.
3. If you have multiple refactorings to execute to accomplish a bigger
restructure, you can optionally, select a subset of automated tests to verify
unchanged behavior after each individual refactoring.
4. Iteratively: apply a refactoring and verify behavior is unchanged. If the
tests show you did change the behavior, change the code, never the tests.
5. If you used a subset of automated tests during the refactoring process, run
all tests to verify unchanged behavior for the whole application.

Here again, if something broke, change the code to make the tests pass —
don’t change the tests.
If you realize that you’re just not going to be able to get the tests passing
again in a reasonable amount of time, restore back to the working code
you had before the refactoring process.

6. Assess the effect of the refactorings on quality characteristics of the


software (e.g., complexity, understandability, maintainability) or the
process (e.g., productivity, cost, effort).

If they’re not satisfactory and can’t easily be improved, restore back to


the working code you had before the refactoring process.

Benefits

More readable code! Be sure to give the new method a name that
describes the method’s purpose: createOrder(), renderCustomerInfo(),
etc.

Same level of abstraction in both methods, which helps understanding of the


code.
Less code duplication. Often the code that is found in a method can be
reused in other places in your program. So you can replace duplicates
with calls to your new method.

Isolates independent parts of code, meaning that errors are less likely
(such as if the wrong variable is modified)

39
Task 7: Perform Testing activities within an agile project.

Agile is an iterative development methodology, where the entire project


team participates in all the activities. The requirements evolve as the
iterations progress, through collaboration between the customer and the
self-organizing teams. As Coding and Testing are done interactively and
incrementally, during the course of development, the end-product would
be of quality and ensures customer requirements.
Every iteration results in an integrated working product increment and is
delivered for User Acceptance Testing. The customer feedback thus
obtained would be an input to the next / subsequent Iterations.

Continuous Integration, Continuous Quality

Continuous Integration is the key for Agile Development success.


Integrate frequently, at least daily such that you are ready for a release as
and when required. Testing in Agile becomes an essential component of
all the phases of the development, ensuring continuous quality of the
product. Constant feedback from everyone involved in the project adds to
the quality of the product.
In Agile, communication is given utmost importance and the customer
requests are received as and when necessary. This gives the satisfaction to the
customer that all the inputs are considered and working quality product is
available throughout the development.

Agile Methodologies

There are several Agile Methodologies that support Agile Development. The
Agile Methodologies include −

40
Scrum
Scrum is an Agile development method that emphasizes on team-centric approach.
It advocates participation of the entire team in all the project development
activities.

XP
Extreme programming is customer-centric and focuses on constantly
changing requirements. With frequent releases and customer feedback, the
end-product will be of quality meeting customer requirements that are
made clearer during the process.
FDD
Feature Driven Development (FDD) involves designing and building
features. The difference between FDD and other Agile Development
Methodologies is that the features are developed in specific and short
phases separately.
DSDM
Dynamic Software Development Method (DSDM) is based on Rapid
Application Development (RAD) and is aligned to the Agile Framework.
DSDM focuses on frequent delivery of the product, involving users
actively and empowering the teams to make quick decisions.
Lean Software Development
In Lean Software Development, focus is on eliminating waste and giving value
to the customer. This results in rapid development and product of value.
Waste includes partially done work, irrelevant work, features that are not used
by the customer, defects, etc. that add to delays in delivery.
Kanban
Kanban focuses on managing work with an emphasis on just-in-time (JIT)
delivery, while not overloading the team members. The tasks are
displayed for all the participants to see and for the Team Members to pull
work from a queue.
Kanban is based on −
Kanban Board (Visual and Persistent across the Development)
Work-in-progress (WIP) Limit
Lead Time

41
Agile Testing Methodologies

The testing practices are well defined for every project, whether Agile or
not, to deliver quality products. Traditional Testing principles are quite
often used in Agile Testing. One of them is Early Testing that focuses on −
o Writing Test Cases to express the behavior of the system.
o Early Defect Prevention, detection and removal.
o Ensuring that the right test types are run at the right time and as part
of the right test level.
In all the Agile Methodologies we discussed, Agile Testing in itself is a
Methodology. In all the approaches, Test Cases are written before Coding
The other commonly used Agile Testing Methodologies are −
Test-Driven Development (TDD) − Test-Driven Development (TDD)
is based on coding guided by tests.
Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven
Development (ATDD) is based on communication between the customers,
developers and testers and driven by pre- defined Acceptance Criteria and
Acceptance Test Cases.
Behavior-Driven Development (BDD) − In Behavior-Driven
Development (BDD) testing is based on the expected behavior of
the software being developed.

Agile Testing Lifecycle

In Scrum, the Testing activities include −


o Contributing to User Stories based on the expected
behavior of the System depicted as Test Cases
o Release Planning based on Test Effort and Defects
o Sprint Planning based on User Stories and Defects
o Sprint Execution with Continuous Testing
o Regression Testing after the completion of Sprint
o Reporting Test Results
o Automation Testing

42
Testing is iterative and sprints based as depicted in the diagram given
below −

43
Task 8: Mini Project: based on tools
STEP 1: Search gitlab on google

STEP 2: Click on login option on top right corner

44
STEP 3: Fill your email and password to login or you can directly login using existing
google account

STEP 4: Next , create new project and choose create blank projec

STEP 5: Fill your project name

45
STEP 6: Click on create project button given at the bottom

STEP 7: Since you have created a project successfully, so now you can send invitation for
team members to join the group by clicking first on project information and then on
activity

46
STEP 8 : Now , you can see all the team members and can work on the project collectively

47
Creating a milestone

STEP 1: Click on ‘Issues’ and then on ‘Milestones’ present on the left side of the screen

STEP 2: For creating a new milestone, click on the ‘new milestone’

48
STEP 3: Following tab will be opened.

STEP 4: After filling the required details about your project, you can click on ‘create
milestone’

STEP 5: Your milestone is created successfully.

49
STEP 6:Creating a requirement and raising an issue

Creating documentation using wiki

Step 1:Click on Wiki section to create a documentation

Step 2:Write the documentation and click on save changes to publish it.

50
Version Control

Step 1:There are many ways to check version control

51
Step 2: For checking the logs in Wikis, click on wiki section

35

You might also like