University Institute of

Engineering and Technology

ASD Lab Practical

Submitted to: Submitted by:
Professor Rajkumari Dhruv kumar
 Experiment-1

What is Agile? It’s advantages and disadvantages.

 Agile is the ability to create and respond to change. It is a way of dealing with, and
ultimately succeeding in, an uncertain and turbulent environment.
 Agile is a collection of principles used in software development and project
management.
 Agile focuses on enabling teams to deliver work in small, workable increments,
thus delivering value to their customers with ease.
 Evaluation of the requirements, plans, and results take place continuously. This
helps the team in responding to changes in a quick manner .

Advantages of Agile Methodology:

 In Agile methodology the delivery of software is unremitting.

 The customers are satisfied because after every Sprint working feature of the
software is delivered to them.
 Customers can have a look of the working feature which fulfilled their
expectations.
 If the customers has any feedback or any change in the feature then it can be
accommodated in the current release of the product.
 In Agile methodology the daily interactions are required between the business
people and the developers.
 In this methodology attention is paid to the good design of the product.
 Changes in the requirements are accepted even in the later stages of the
development.

Disadvantages of the Agile Methodology :

 In Agile methodology the documentation is less.

 Sometimes in Agile methodology the requirement is not very clear hence it’s
difficult to predict the expected result.
 In few of the projects at the starting of the software development life cycle it’s
difficult to estimate the actual effort required.
 Because of the ever-evolving features, there is always a risk of the ever-lasting
project.
 For complex projects, the resource requirement and effort are difficult to
estimate.
 

SOLID Principles—
What does the SOLID principles actually means? Well, it’s just an
acronym of the five principles listed as below.
 S - Single Responsibility Principle (known as SRP)
 O- Open/Closed Principle
 L - Liskov’s Substitution Principle
 I - Interface Segregation Principle
 D - Dependency Inversion Principle

SRP (Single Responsibility Principle):

The name itself suggest that the “class should be having one and only one
responsibility”. What does it mean? Well let’s take the class A which does the
following operations.
 Open a database connection
 Fetch data from database
 Write the data in an external file

The issue with this class is that it handles lot of operations. Suppose any of the
following change happens in future.
 New database
 Adopt ORM to manage queries on database
 Change in the output structure

So in all the cases the above class would be changed. Which might affect the
implementation of the other two operations as well. So ideally according to SRP there
should be three classes each having the single responsibility.

code:
#include<bits/stdc++.h>
using namespace std;

class User{
public:
    bool Login(string username,string password){
        cout<<username<<" "<<password<<endl;
        cout<<"Login Successfully\n";
        return true;
  }

    bool Register(string username,string password,string email){

        cout<<"Register successfully\n";
  }
};

class Error{
public:

    void logError(string error){

        cout<<error<<endl;
  }
};

class Email{
public:

    bool sendEmail(string message){

        cout<<"Sent Email\n";
  }
};

int main(){
    User *us=new User();
    us->Login("Dhruv kumar","198038");

    Error *err=new Error();

    err->logError("Error!! Please try again");

    Email *em=new Email();

    em->sendEmail("hello");
}

Output:
Dhruv kumar 198038
Login Successfully
Error!! Please try again
Sent Email
Open Closed Principle:

 This principle suggests that “classes should be open for extension but closed
for modification”.
 What is means is that if the class A is written by the developer AA, and if the
developer BB wants some modification on that then developer BB should be
easily do that by extending class A, but not by modifying class A.
 The principle states that software entities like class, modules, functions, etc.;
should be able to extend a class behaviour without modifying it.
 This principle separates the existing code from modified mode to provide
better stability, maintainability and minimizes the changes in the code.
 In a nutshell, the developer must need to change only a specific part of the
code (a class or a function) every time a requirement changes.

Code:
include<iostream>
using namespace std;
class Rectangle{
public:
    int length,breadth;
    Rectangle(int l,int b){
        length=l;
        breadth=b;
  }
    int area(){
        return length*breadth;
  }
};

class Square{
public:
    int side;
    Square(int s){
        side=s;
  }
    int area(){
        return side*side;
  }
};

int main(){
    Rectangle *r=new Rectangle(3,4);
    cout<<"Area of rectangle is "<<r->area()<<endl;

    Square *s=new Square(5);

    cout<<"Area of square is "<<s->area();
}

// open for extension, but closed for modification.�

Output:
Area of rectangle is 12
Area of square is 25

LSP (Liskov Substitution Principle)

 This principle suggests that “parent classes should be easily substituted with
their child classes without blowing up the application”. 
 The Liskov Substitution Principle (LSP) states that objects of a superclass
should be replaceable with objects of its subclasses without breaking the
application. 
 In other words, what we want is to have the objects of our subclasses
behaving the same way as the objects of our superclass.

Code:
#include<iostream>
using namespace std;

class Shape{
public:
    void area(){
        cout<<"Area";
  }
};

class Rectangle: public Shape{

public:
    int length,breadth;
    Rectangle(int l,int b){
        length=l;
        breadth=b;
  }
    int area(){
        return length*breadth;
  }
};

class Square: public Shape{

public:
    int side;
    Square(int s){
        side=s;
  }
    int area(){
        return side*side;
  }
};

int main(){
    Rectangle *r=new Rectangle(3,4);
    cout<<"Area of rectangle is "<<r->area()<<endl;

    Square *s=new Square(5);

    cout<<"Area of square is "<<s->area();
}

Output:
Area of rectangle is 12
Area of square is 25

ISP (Interface Segregation Principle):

 The Interface Segregation Principle states that clients should not be forced to
implement interfaces they don't use.
 Basically, the principle is similar to the SINGLE RESPONSIBILITY
PRINCIPLE in the sense that classes should only implement methods that
they actually use.
 This principle suggests that “many client specific interfaces are better than one
general interface”.
 This is the first principle which is applied on interface, all the above three
principles applies on classes.
 As with all SOLID principles, ISP contributes to making code more
manageable and robust.
 This is particularly in the case where a change has to be made to an interface
which is propagated downwards to all subclasses implementing it.
  Without ISP, the function being updated would have to be updated in the
subclasses too even though they don’t implement any business logic.

Code:

#include <bits/stdc++.h>
using namespace std;

class vehicle{
public:
    string color;
    int price;
    void setprice(int price)
  {
        cout<<"Setting price to "<<price<<endl;
        this->price = price;
  }
    void setcolor(string col)
  {
        cout<<"Setting color to "<<col<<endl;
        color = col;
  }

    virtual void start() = 0;

    virtual void speed() = 0;
};

class car:public vehicle{

public:
    void start()
  {
        cout<<"Starting Car"<<endl;
  }
    void speed()
  {
        cout<<"Speeding Car"<<endl;
  }
    void horn()
  {
        cout<<"Pressing the horn"<<endl;
  }
};

class plane:public vehicle{

public:
    void start()
  {
        cout<<"Starting Plane"<<endl;
  }
    void speed()
  {
        cout<<"Speeding Plane"<<endl;
  }
    void land()
  {
        cout<<"Landing the Plane"<<endl;
  }
};

int main()
{
    car car1;
    car1.setcolor("Blue");
    car1.setprice(5000000);

    car1.start();
    car1.speed();
    car1.horn();

    cout<<endl;

    plane plane1;
    plane1.setcolor("White");
    plane1.setprice(1000000000);

    plane1.start();
    plane1.speed();
    plane1.land();

    return 0;
}

Output:
Setting color to Blue
Setting price to 5000000
Starting Car
Speeding Car
Pressing the horn

Setting color to White

Setting price to 1000000000
Starting Plane
Speeding Plane
Landing the Plane

DSP (Dependency Inversion Principle)

 Dependency inversion principle is one of the principles on which most of the

design patterns are build upon.
 Dependency inversion talks about the coupling between the different classes
or modules.
 It focuses on the approach where the higher classes are not dependent on
the lower classes instead depend upon the abstraction of the lower classes.
 The main motto of the dependency inversion is Any higher classes should
always depend upon the abstraction of the class rather than the detail.
 This aims to reduce the coupling between the classes is achieved by
introducing abstraction between the layer, thus doesn’t care about the real
implementation.

Code:
#include<bits/stdc++.h>
using namespace std;

class Employee{ // Abstraction

public:
    virtual void Work(){
  }
};

class Manager{
public:
    vector<Employee*> employees;
    void addemployee(Employee *e1)
  {
        employees.push_back(e1);
  }
};

class Developer:public Employee{

public:
Developer()
{
    cout<<"Developer added"<<endl;
}
    void Work()
  {
        cout<<"Developing the software"<<endl;
  }
};

class Designer:public Employee{

public:
Designer()
{
    cout<<"Designer added"<<endl;
}
    void Work()
  {
        cout<<"Designing"<<endl;
  }
};

class Tester:public Employee{

public:
Tester()
{
    cout<<"Tester added"<<endl;
}
    void Work()
  {
        cout<<"Testing the code"<<endl;
  }
};

int main()
{
    Manager m1;
    m1.employees.push_back(new Developer());
    m1.employees.push_back(new Designer());
    m1.employees.push_back(new Tester());

    cout<<endl;

    m1.employees[0]->Work();
    m1.employees[1]->Work();
    m1.employees[2]->Work();
    return 0;
}

Output:
Developer added
Designer added
Tester added

Developing the software

Designing
Testing the code
 Experiment -6

USER STORIES
 User story is the smallest unit of work in an agile framework. It’s an end goal,
not a feature, expressed from the software user’s perspective.
 A user story is an informal, general explanation of a software feature written
from the perspective of the end user or customer. 
 The purpose of a user story is to articulate how a piece of work will deliver a
particular value back to the customer. Note that "customers" don't have to be
external end users in the traditional sense, they can also be internal
customers or colleagues within your organization who depend on your team.
Risk management and Testing:
 UNIT TESTING is a type of software testing where individual units or
components of a software are tested. The purpose is to validate that each
unit of the software code performs as expected. Unit Testing is done
during the development (coding phase) of an application by the
developers. Unit Tests isolate a section of code and verify its correctness.
A unit may be an individual function, method, procedure, module, or
object.
o Invalid user type
o Invalid discount amount
o Can’t edit discount (read only mode).
o Cannot miss date (must attempt)

 INTERGRATION TESTING is the process of testing the interface

between two software units or module. It’s focus on determining the
correctness of the interface. The purpose of the integration testing is to
expose faults in the interaction between integrated units. Once all the
modules have been unit tested, integration testing is performed.
o Can’t allow to make changes in discount by the user

 System Testing System Testing is a type of software testing that is

performed on a complete integrated system to evaluate the compliance
of the system with the corresponding requirements.
In system testing, integration testing passed components are taken as
input. The goal of integration testing is to detect any irregularity between
the units that are integrated together.
o Check whether the system meet minimum requirement of internal
memory etc.
o Check whether the system is secure or not.
 Experiment-8
JIRA SOFTWARE

Jira Software is a powerful platform that combines issue collection and agile project
management capabilities into a single application. Using Jira Software helps you plan
and organize tasks, workflows, and reports for your agile team more efficiently.