210170107522 Software Engineering

PRACTICAL -1
Aim: Prepare the project abstract and identify the appropriate process model.

Problem: In recent times, during the pandemic, online education was boosted
because offline was not possible as well as traveling. So, with respect to that
many e-learning platforms were developed. The problem was that the platforms
lacked proper education tutorials and assessments too. So, in our forum, we tried
to rectify the problem and found a better solution.

Purpose: Web Applications provides the facility to study online anywhere at any
time worldwide by creating an account on this platform. It allows students to
learn any course and give the exam through our platform and give results with the
certification after completion of the course which is automatically generated as
per the marks obtained by the student.

Selected process model: Prototyping Model

Why I have selected Prototyping Model?

While developing the software systems, it’s requirements are changed with time
and situation. So, in that point Prototyping Model is helpful. And also, it is app for
school and students, so it must be tested and approved by the different schools for
efficiency. So, it is convenient to use prototype model.

1
210170107522 Software Engineering

Prototype Model :

Prototyping is defined as the process of developing a working replication

of a product or system that has to be engineered. It is one of the most popularly
used software development life cycle modules. This models is used when the
customers do not know the exact project requirements beforehand. In this model,
a prototype of the end product is first developed, tested and refined as per
customer feedback repeatedly till a final acceptable prototype is achieved which
forms the basis for developing the final product.

2
210170107522 Software Engineering

PRACTICAL 2
Aim: To Prepare Software Requirement Specification for your project definition.

Functional Requirements:

M1R1: Student Registration module

Input: Student gives their details for registration.

Process: Details will be inserted into the database.

Output: Successfully student account created.

M1R2: Student Login module

Input: Student gives their credentials for login.

Process: Credentials will be cross-verified with the database.

Output: Logged on to the platform.

M2R1: Teacher Registration module

Input: Teacher gives their details for registration.

Process: Details will be inserted into the database.

Output: Successfully Teacher account created.

M2R2: Teacher Login module

Input: Teacher gives their credentials for login.

Process: Credentials will be cross-verified from the database.

Output: Successfully logged on to the platform.

M3R1: Admin module

Input: Admin gives their credentials for login.

Process: Credentials will be cross-verified with the database.

Output: Successfully logged on to the platform.

3
210170107522 Software Engineering

M4R1: Student Courses module

Input: Students can access various courses or allotted courses from the courses section

Process: Students’ assigned courses can be cross-verified with the database.

Output: Courses can be viewed if allotted to that particular student.

M4R2: Teacher Courses module

Input: Teacher can create & record courses and upload them to the courses section.

Process: Course and course details are added to the database.

Output: Courses can be viewed by a particular student which was added by the teacher.

M4R3: Admin Courses module

Input: 1) Admin can approve or disapprove the courses added by teacher.

2) Admin can also remove students from particular courses.

Process: Updation in the database as per the admin decision.

Output: 1) As per the admin approval courses can be viewed.

2) As per the admin approval students can view the course.

M5R1: Teacher Assignment module

Input: Teacher creates an assignment and uploads it to the assignment section.

Process: Assignment is inserted into the database.

Output: Assignment can be viewed by the particular student.

M5R2: Student Assignment module

Input: Students can view and submit the assignment in the assignment section.

Process: Submitted assignment is updated in the database.

Output: Submitted assignments can be viewed by the particular teacher.

M6R1: Teacher Exam module

Input: Teacher creates an exam and uploads the question and answers (if MCQs) in the
exams section.

4
210170107522 Software Engineering

Process: Exams questions and answers is inserted into the database.

Output: Exams questions can be viewed by the particular student.

M6R2: Student Exam module

Input: Students can view the exam and answer the asked questions in the exams
section.

Process: Exams questions’ answers are updated in the database.

Output: Answers can be viewed and checked by either platform(if MCQs) or the
particular teacher.

Non-Functional Requirements:

M1R1: Platform Performance Indicator

Input: If errors are generated in the platform.

Process: Performance is calculated on the bases of error and updated in the database.

Output: Performance is viewed by an admin.

M2R1: Average Monthly Users (Active)

Input: Monthly users are provided to this module.

Process: Monthly user count’s average is inserted into the database.

Output: Average monthly users can be viewed by the admin.

M3R1: Maintainability and Safety

Input: N/A

Process: Performing security checks and compliance, UI design restructures and

database design restructures.

Output: Maintainability and Safety can be monitored by the admin.

M4R1: Scalability

Input: N/A

Process: Adding new courses and expert teachers.

Output: Growth of the platform.

5
210170107522 Software Engineering

M5R1: Reliability

Input: N/A

Process: By giving constant good education to students.

Output: Reliability can be achieved by the stakeholders.

PRACTICAL -3

6
210170107522 Software Engineering

AIM: Estimation of project metrics for your project defination.

Functionals Levels

Components Count Low Average High Total

External Inputs 8 3x3 3x4 2x6 33

External outputs 5 1x4 0x5 4x7 32

External Enquiry 5 2x3 3x4 0x6 18

External internal files 1 0x5 0x7 1 x 10 10

Internal Logical files 4 0x7 2 x 10 2 x 15 50

Total Unadjusted FP (UFP): 143

Degree of Influences (DI):

Characteristic Degree of Influence Description

(DI)

1. Data Communication 3 Dataflow throughout the

platform.

2. Distributed data processing 2 Data is provided to various

users, which are eligible.

3. Performance 4 Significant performance is

required.

4. Heavily used configuration 1 Minimum hardware

requirements.

5. Transaction rate 1 Yearly transaction.

6. Online data entry 2 Moderate data entry work is

required.

7. End user efficiency 5 It is soulfully designed for end

user efficiency.

8. Online update 5 Data lost is essential

9. Complex processing 1 Incidental complex processing is

required.

7
210170107522 Software Engineering

10. Reusability 5
Maximum reusability required.

11.Installation ease 0 No installation required.

12.Operational ease 1
Minimum operations required.

13.Multiple sites 0
It is an independent platform.

14.Facilitate change 5 It is specifically designed for

educational purposes.

Total Degree of Influence (TDI): 35

Scale of Degree of Influence(DI):

Rating Degree of Influence

0 Not present, or no influence

1 Incidental influence

2 Moderate influence

3 Average influence

4 Significant influence

5 Strong influence throughout

Three Formulas for Size Estimation of the FIS:

● Total Degree of Influence (TDI) = Sum of the Influence Factors

● Value Adjustment Factor (VAF) =0.65 + (0.01 * TDI)
● Function Points (FP) = VAF * unadjusted FP

Value Adjustment Factor (VAF) = (TDI x 0.01) + 0.65 = (35 x 0.01) + 0.65 = 1

Adjusted Function Point Count (FP) = UFP x VAF = 143 x 1 = 143

Line of Code = (SLOC per FP for Java) x FP = 30 x 143 = 4290

Effort Estimation:

An LOC-oriented estimation model is used for effort estimation.

8
210170107522 Software Engineering

The number of lines of code is then defined by:

LOC = FP x Language Factor (Language Factor varies by Language of

Programming)

KLOC = 4.29 (4290 LOC)

Then the effort is

Effort (Coding) = a x Size b

Development Time (T) =c*(Effort)^d

a and b are constants that depend on the project, and size is measured in thousands of lines of code
(KLOC).

Software Project a b c d

Organic 3.2 1.05 2.5 0.38

Semi-detached 3 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

Because of the decision, the software project has an “organic” structure. a =

3.2 is determined for Organic Project b = 1.05 is determined for Organic

Project c = 2.5 is determined for Organic

Project d = 0.38 is determined for Organic Project

E = 3.2 x 4.29 ^ 1.05 = 3.2 x 4.6 = 15.6 (man month)

COCOMO Development Time (T) = c * (Effort Applied)^d = 2.5 * ( 15.6) ^ 0.38 = 7.1 Months

“c ” and 'd' depend on the modes of the difficulty so d is decided as 0.38 as it is for the other organic
software projects. COCOMO model calculates effort in staff months (19 days per month or 152 working
hours per month).

Therefore such a software project needs: Staff = Effort / Duration = 15.6 / 7.1 = 2.2 persons

Cost Estimation:

The salary of each group member is 20000Rs./p.m @145Hrp.m, therefore the estimated cost of the
Project is:

15.6 man month = 15.6 x 145 (hours in a month) = 2262 man hours

Cost = Effort x $ (the hourly salary)

9
210170107522 Software Engineering

C = 2262 man-hours x (20000/145) man-hours = 312Rs

PRACTICAL -4

AIM: To prepare Use Case Diagrams and Data Flow Diagrams for your project
defination.

Use Case Diagram:

10
210170107522 Software Engineering

Data Flow Diagram:

11
210170107522 Software Engineering

Level 0

Level 1

12
210170107522 Software Engineering

Level 2

13
210170107522 Software Engineering

PRACTICAL -5
AIM: To prepare E-R diagram and data dictionary for your project defination.

Data Dictionary:

Table 1: Admin

FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION

admin_id integer(10) Primary key It uniquely identifies
the admin.
f_name varchar(50) It stores the admin's
first name.
l_name varchar(50) It stores the admin's
last name.
email varchar(50) Not Null It stores the admin
email address.

passwd varchar(50) It stores passwords.

Table 2: Teacher
FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION
t_id integer(10) Primary key It uniquely identifies
the teacher.
f_name varchar(50) It stores the teacher's
first name.
l_name varchar(50) It stores the teacher’s
last name.
email varchar(50) Not Null It stores the teacher's
email address.

14
210170107522 Software Engineering

passwd varchar(50) It stores passwords.

exp varchar(50) Not Null It stores the expertise

of the teacher.

Table 3: Student

FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION

s_id integer(10) Primary key It uniquely identifies
the student.
f_name varchar(50) It stores the student's
first name.
l_name varchar(50) It stores the student's
last name.
email varchar(50) Not Null It stores the student’s
email address.
passwd varchar(50) It stores passwords.

address varchar(50) Not Null It stores the address of

the student.

Table 4: Course

FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION

15
210170107522 Software Engineering

c_id integer(10) Primary key It uniquely

identifies the
courses.
c_name varchar(50) Not Null It stores the
name of the
course.
desc varchar(200) Not Null It stores the
description of the
courses.
creator integer(10) Foreign key It stores the
creator id of the
course.
price integer(10) Not Null It stores the price
of the course.
duration integer(10) Not Null It stores the
duration of the
course.

Table 5: Assignment

FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION

16
210170107522 Software Engineering

assignment_id integer(10) Primary key It uniquely

identifies the
assignment.
a_name varchar(50) Not Null It stores the name
of the assignment.
c_id integer(10) Foreign key It stores the id of
the respective
courses.
creator_id integer(10) Foreign key It stores the creator
id of the
assignment.
desc varchar(200) Not Null It stores the
description of the
assignment.
start_date date Not Null It stores the start
date of the
assignment.
end_date date Not Null It stores the end
date of the
assignment.

Table 6: Enrolled Courses

FIELD NAME DATA TYPE CONSTRAINTS DESCRIPTION

17
210170107522 Software Engineering

s_id integer(10) Foreign key It stores the student

id who enrolled in a
course.
c_id integer(10) Foreign key It stores the course id
in which the student
enrolled.
enroll_date date Not Null It stores the enroll
date of the course.

ER Diagram:

18
210170107522 Software Engineering

PRACTICAL -6

19
210170107522 Software Engineering

AIM: To Prepare the Activity Diagram and Swim lane diagram for the Project.

Activity and Swim lane digram:

PRACTICAL 7

20
210170107522 Software Engineering

Aim: To Identify Domain Classes from the Problem Statements and prepare Class
Diagram.

Class Diagram:

Idenifying classes for domain,

Result
Exam
Class
Teacher
Course

21
210170107522 Software Engineering

22
210170107522 Software Engineering

PRACTICAL -8
AIM: 1. To design test cases for your project definition 2. To prepare test case
using testing tools.

23
210170107522 Software Engineering

2. To prepare test case using testing tool

● Software testing tools are required for the betterment of the application or software.

● That's why we have so many tools available in the market where some are open-source
and paid tools.

● The significant difference between open-source and the paid tool is that the
opensource tools have limited features, whereas paid tool or commercial tools have no
limitation for the features. The selection of tools depends on the user's requirements,
whether it is paid or free.

● The software testing tools can be categorized, depending on the licensing (paid or
commercial, open-source), technology usage, type of testing, and so on.

● Some Testing tools are:

○ Katalon Studio

○ Ranorex Studio
○ Test complete

24
210170107522 Software Engineering

○ Lambda test

○ Postman

○ Protractor

○ Perfecto

○ Eggplant

○ soapUI

○ Tricentie

○ Selenium

Selenium is one of the most widely used open-source Web UI (User Interface) automation
testing suite.
It was originally developed by Jason Huggins in 2004 as an internal tool at Thought Works.
Selenium supports automation across different browsers, platforms and programming languages.
Selenium can be easily deployed on platforms such as Windows, Linux, Solaris and Macintosh.
Moreover, it supports OS (Operating System) for mobile applications like iOS, windows mobile
and android.
Selenium supports a variety of programming languages through the use of drivers specific to
each language.
Languages supported by Selenium include C#, Java, Perl, PHP, Python and Ruby.
Currently, Selenium Web driver is most popular with Java and C#.
Selenium test scripts can be coded in any of the supported programming languages and can be
run directly in most modern web browsers.
Browsers supported by Selenium include Internet Explorer, Mozilla Firefox, Google Chrome
and Safari.

25
210170107522 Software Engineering

PRACTICAL 9
AIM: To install version control tool and study its features.

VERSION CONTROL:
In software engineering, version control (also known as revision control,
source control, or source code management) is a class of systems responsible for
managing changes to computer programs, documents, large web sites, or other
collections of information. Version control is a component of software
configuration management.
The need for a logical way to organize and control revisions has existed for
almost as long as writing has existed, but revision control became much more
important, and complicated, when the era of computing began. The numbering of
book editions and of specification revisions are examples that date back to the
print-only era. Today, the most capable (as well as complex) revision control
systems are those used in software development, where a team of people may
concurrently make changes to the same files.
Version control systems (VCS) are most commonly run as stand-alone
applications, but revision control is also embedded in various types of software
such as word processors and spreadsheets, collaborative web docs and in various
content management systems, e.g., Wikipedia's page history. Revision control
allows for the ability to revert a document to a previous revision, which is critical
for allowing editors to track each other's edits, correct mistakes, and defend against
vandalism and spamming in wikis.
Types of Version Control:
 Local Version Control Systems
 Centralized Version Control Systems
 Distributed Version Control Systems

1. Local Version Control System:

It basically maintains the track of files within the local system. It is the
simplest one but the most error-prone. The chances to rewrite a file by mistake are
very large.

26
210170107522 Software Engineering

2. Centralized Version Control System:

In a Centralized VCS basically snapshots of the changes are saved on the
server. The main or centralized server tracks all the changes. Every user can have
their branch where they can commit changes and merge with the main branch after
review.

27
210170107522 Software Engineering

3. Distributed Version Control System:

In Distributed VCS the user completely clones a copy of Server files to its
local repo. Hence each user has a backup of server files. So, this overcomes the
drawback of Centralized Version Control as even if the server goes down or
crashes or dies every user has a backup that can be restored to the server again.

GIT AS VERSION CONTROL:

GIT is a free and open-source version control system designed to handle
everything from small to large project with speed and efficiency.
Following is some of the important features of git:
1. Distributed System
Having a distributed system, Git allows the users to work simultaneously on the
same project, without interfering with others’ work. When a particular user gets
done with their part of the code, they push the changes to the repository and these
changes get updated in the local copy of every other remote user which pulls the
latest copy of the project.

28
210170107522 Software Engineering

2. Branching
Git allows its users to work on a line that runs parallel to the main project files.
These lines are called branches. Branches in Git provide a feature to make changes
in the project without affecting the original version. The master branch of a version
will always contain the production quality code. Any new feature can be tested and
worked upon on the branches and further, it can be merged with the master branch.
Branching and merging can be done very easily with the help of a few Git
commands. A single version of a project may contain n number of branches as per
the user’s requirement.
3. Lightweight
Git stores all the data from the central repository on to the local repository
while cloning is done. There might be hundreds of users working on the same
project and hence the data in the central repository might be very huge. One might
be worried that cloning that much data into local machines might result in system
failure but Git has already taken care of such a problem. Git follows the criteria of
lossless compression that compresses the data and stores it in the local repository
occupying very minimal space. Whenever there is a need for this data, it follows
the reverse technique and saves a lot of memory space.
4. Speed
Since Git stores all the data related to a project in the local repository by the
process of cloning, it is very much efficient to fetch data from the local repository
instead of doing the same from the remote repository. Git is very fast and scalable
compared to other version control systems which results in the handling of large
projects efficiently. The fetching power from a local repository is about 100 times
faster than what possible with the remote server.
5. Compatibility
Git is compatible with all the Operating Systems that are being used these days.
Git repositories can also access the repositories of other Version Control Systems
like SVN, CVK, etc. Git can directly access the remote repositories created by
these SVNs.

29
210170107522 Software Engineering

6. Non-Linear Development
Git allows users from all over the world to perform operations on a project
remotely. A user can pick up any part of the project and do the required operation
and then further update the project. This can be done by the Non-linear
development behaviour of the Git.

Some Keywords of Git World:

 Repository / Repo:
A Repository is usually used to organize a single project. Repositories can
contain folders and files, images, videos, spreadsheets, and data sets – anything
your project needs. Git has two repository types: Local and Remote. The local repo
is on your computer for only your direct use. The remote repo is typically
elsewhere and for your indirect use. Git supports multiple remote repositories.
1) Remote Repo:
Typically, we work in teams and need to work on a codebase together. The
codebase is on a “central” server and people retrieve files from it and commit to it.
Git refers to the centralized server as a “remote repository”. The remote repo is
usually not on your machine and is the one shared by the team. The team “pushes”
commits to it when ready to share with the team. While one of your remote repos
could be another team member’s local repo, in a corporate environment at least one
(or the only!) is typic ally a Git repo on a server anointed as the central/official
repo.
Note that a remote repo is optional. When not sharing code with others, there is
technically no need for a remote repo (you may want one for backup or CI). There
is also no need for a remote repo if your local repo is considered the central one by
all team members.
2) Local Repo:
The local repo is on your computer and has all the files and their commit history,
enabling full diffs, history review, and committing when offline. This is one of the
key features of a “distributed” version control system (DVCS), locally having the
full repository history.

30
210170107522 Software Engineering

 Branch & Branching

Branches allow you to develop features, fix bugs, or safely experiment with
new ideas in a contained area of your repository. You always create a branch from
an existing branch. Typically, you might create a new branch from the default
branch of your repository. You can then work on this new branch in isolation from
changes that other people are making to the repository. A branch you create to
build a feature is commonly referred to as a feature branch or topic branch.

 Merge:
In Git, the merging is a procedure to connect the forked history. It joins two or
more development history together. The git merge command facilitates you to take
the data created by git branch and integrate them into a single branch. Git merge
will associate a series of commits into one unified history. Generally, git merge is
used to combine two branches.

 Commit:
It is used to record the changes in the repository. Every commit contains the
index data and the commit message. Every commit forms a parent-child
relationship. When we add a file in Git, it will take place in the staging area. A
commit command is used to fetch updates from the staging area to the repository.
The staging and committing are co-related to each other. Staging allows us to
continue in making changes to the repository, and when we want to share these
changes to the version control system, committing allows us to record these
changes.

 Push:
The push term refers to upload local repository content to a remote repository.
Pushing is an act of transfer commits from your local repository to a remote
repository. Pushing is capable of overwriting changes; caution should be taken
when pushing.

31
210170107522 Software Engineering

 Pull and Pull Request:

The term pull is used to receive data from Remote Repo. It fetches and merges
changes from the remote server to your working directory. The git pull command
is used to pull a repository. Pull request is a process for a developer to notify team
members that they have completed a feature. Once their feature branch is ready,
the developer files a pull request via their remote server account. Pull request
announces all the team members that they need to review the code and merge it
into the master branch.

32
210170107522 Software Engineering

Practical 10
Aim: i) Study Principles, Practices, tools of DevOps, and find out various
advantages and disadvantages of DevOps.
ii) Study of any two Open source tools in DevOps DevOps
● DevOps is more than just development and operations teams working together.

It’s more than tools and practices. DevOps is a mindset, a cultural shift, where teams adopt new
ways of working.

● A DevOps culture means developers get closer to the user by gaining a better understanding
of user requirements and needs. Operations teams get involved in the development process
and add maintenance requirements and customer needs. It means adhering to the following
key principles that help DevOps teams deliver applications and services at a faster pace and
higher quality than organisations using the traditional software development model

Principles of DevOps

● Collaboration

The key premise behind DevOps is collaboration. Development and operations teams coalesce
into a functional team that communicates, shares feedback, and collaborates throughout the
entire development and deployment cycle. Often, this means development and operations teams
merge into a single team that works across the entire application lifecycle.
The members of a DevOps team are responsible for ensuring quality deliverables across each
facet of the product. This leads to more ‘full stack’ development, where teams own the complete
backend-to-frontend responsibilities of a feature or product. Teams will own a feature or project
throughout the complete lifecycle from idea to delivery. This enhanced level of investment and
attachment from the team leads to higher quality output.

33
210170107522 Software Engineering

● Automation

An essential practice of DevOps is to automate as much of the software development lifecycle

as possible. This gives developers more time to write code and develop new features.
Automation is a key element of a CI/CD pipeline and helps to reduce human errors and increase
team productivity. With automated processes, teams achieve continuous improvement with short
iteration times, which allows them to quickly respond to customer feedback.

● Continues improvement

Continuous improvement was established as a staple of agile practices, as well as lean

manufacturing and Improvement Kata. It’s the practice of focusing on experimentation,
minimizing waste, and optimizing for speed, cost, and ease of delivery. Continuous
improvement is also tied to continuous delivery, allowing DevOps teams to continuously push
updates that improve the efficiency of software systems. The constant pipeline of new releases
means teams consistently push code changes that eliminate waste, improve development
efficiency, and bring more customer value

● Customer centric action

DevOps teams use short feedback loops with customers and end users to develop products
and services centered around user needs. DevOps practices enable rapid collection and
response to user feedback through use of real-time live monitoring and rapid deployment.
Teams get immediate visibility into how live users interact with a software system and use
that insight to develop further improvements.

● Create with end in mind

This principle involves understanding the needs of customers and creating products or services
that solve real problems. Teams shouldn’t ‘build in a bubble’, or create software based on
assumptions about how consumers will use the software. Rather, DevOps teams should have a
holistic understanding of the product, from creation to implementation

DevOps Practices DevOps practices reflect the idea of continuous improvement and automation.
Many practices focus on one or more development cycle phases. These practices include:

● Continuous development

This practice spans the planning and coding phases of the DevOps lifecycle. Version-control
mechanisms might be involved.
● Continuous testing

This practice incorporates automated, prescheduled, continued code tests as application code is
being written or updated. Such tests can speed the delivery of code to production.

34
210170107522 Software Engineering

● Continuous integration (CI)

This practice brings configuration management (CM) tools together with other test and
development tools to track how much of the code being developed is ready for production. It
involves rapid feedback between testing and development to quickly identify and resolve code
issues.

● Continuous delivery

This practice automates the delivery of code changes, after testing, to a pre production or
staging environment. A staff member might then decide to promote such code changes into
production.

● Continuous deployment (CD)

Similar to continuous delivery, this practice automates the release of new or changed code into
production. A company doing continuous deployment might release code or feature changes
several times per day. The use of container technologies, such as Docker and Kubernetes, can
enable continuous deployment by helping to maintain consistency of the code across different
deployment platforms and environments

● Continuous monitoring

This practice involves ongoing monitoring of both the code in operation and the underlying
infrastructure that supports it. A feedback loop that reports on bugs or issues then makes its way
back to development.

● Infrastructure as code

This practice can be used during various DevOps phases to automate the provisioning of
infrastructure required for a software release. Developers add infrastructure “code” from within
their existing development tools. For example, developers might create a storage volume on
demand from Docker, Kubernetes, or OpenShift. This practice also allows operations teams to
monitor environment configurations, track changes, and simplify the rollback of configurations.

35
210170107522 Software Engineering

DevOps Tool

 Advantages of DevOps

Disadvantages of DevOps

● Complexity

● No standardised version

36
210170107522 Software Engineering

● Teething problem

● Early adoption overheads

● Technical dissonance

● Operational impediments

DevOps Tools 1. Docker

Docker overview Docker is an open platform for developing, shipping, and running
applications. Docker enables you to separate your applications from your infrastructure so
you can deliver software quickly. With Docker, you can manage your infrastructure in the
same ways you manage your applications. By taking advantage of Docker’s methodologies
for shipping, testing, and deploying code quickly, you can significantly reduce the delay
between writing code and running it in production. The Docker platform Docker provides
the ability to package and run an application in a loosely isolated environment called a
container. The isolation and security allows you to run many containers simultaneously on a
given host. Containers are lightweight and contain everything needed to run the application,
so you do not need to rely on what is currently installed on the host. You can easily share
containers while you work, and be sure that everyone you share with gets the same
container that works in the same way. Docker provides tooling and a platform to manage
the lifecycle of your containers:

● Develop your application and its supporting components using containers.

● The container becomes the unit for distributing and testing your application.

● When you’re ready, deploy your application into your production environment, as a container
or an orchestrated service. This works the same whether your production environment is a
local data center, a cloud provider, or a hybrid of the two

2. Slack

● Slack is a messaging app for business that connects people to the information that they need.
By bringing people together to work as one unified team, Slack transforms the way that
organisation communicate.

● Working in Slack

○ Slack helps you to work in a more connected, flexible and inclusive way.

○ Inclusive

37
210170107522 Software Engineering

■ In Slack, everyone in an organisation has access to the same shared and searchable
information. When teams work together in channels, information can be shared with everyone at
once, helping teams to stay aligned and make decisions more quickly.

○ Flexible

■ Slack supports asynchronous work. When work is organised in channels, you can access the
information you need in your own time, regardless of your location, time zone or function. Ask
questions, catch up with new developments and share updates without having to coordinate
schedules.

○ Connected

■ Slack makes it easy to contact your colleagues – you can message anyone inside or outside
your organisation and collaborate just as you would in person. People can work in dedicated
spaces called channels, which bring the right people and information together

38