DevOps - Plan and Code

Completed : 15.10.2017 Created by: AYDIN ÇALIKOĞLU

Preview
DevOps - Plan and Code

SOFTWARE REQUIREMENTS
SPECIFICATION
for
PLAN and CODE
Prepared by Group 1
CSE343 - Software Engineering
Gebze Technical University
November 15, 2017

1 Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the Plan and Code
which is part of web-based open-source DevOps software.It will explain the purpose and
features of the Plan and Code or rather Trello and Git tools that will be used.Additionally
the interfaces of the Plan and Code part and what can be done in Plan and Code part
and the constraints under which it must operate. This document is intended for users
of the software and also potential developers.
1.2 Document Conventions
This Document was created based on the IEEE template for System Requirement Spec-
i cation Documents.
1.3 Intended Audience and Reading Suggestions
 Typical Users, such as students, who want to use DevOps e.g. (for managing their
group projects)
 Advanced/Professional Users, such as engineers or researchers, who want to use
DevOps portal for more demanding their projects plans.
 Programmers who are interested in working on the project by further developing
it or x existing bugs.
1.4 Product Scope
Plan and code" part of DevOps portal is a tool that allows developers to plan their
work better and they can use it to synchronize their code very easily.Developers can
add new projects and represent their jobs with using cards.Every cards represents a new
assigned job for developer.In this way, Developers determines jobs done easily.
This is a software part a "DevOpslife cycle"
4
1.5 References
Trello”s website: https://trello.com/
Github”s website: https://github.com/
5
2 Overall Description
2.1 Product Perspective
Plan and code" part of the Dev-Ops portal is designed to handle projects and works in
it automatically via Trello Api. Project manager can start-up new projects and works
in it, developers can choose between these works and sent it to test when they nished
working on it.
Planning part”s main functionality is that all the project members can see process
of the project via Trello but all the required changes in Trello, can be made from our
portal. So this leads the project management to be more compact.
On the other hand, coding part of Dev-Ops portal will handle synchronization between
GitHub and Trello very eciently. Project members can see easily where their code right
now.
2.2 Product Functions
Project:
1. New Project: Creation of new project
2. Show Projects: Displaying existing projects in Trello
3. Choose Project: Deciding which project will be current project
4. Current Project: Displaying current project in Trello
Works:
1. Add Work: Creating new work in current project
2. Show Works: Displaying existing works in Trello
3. Choose Work: Deciding which work will be tested
4. Current Work: Displaying current card in Trello
5. Show Work: Choosing this work as new job
6. Delete Work: Removing work from works list
6
Members:
1. Add Member: Authorize a new member in current project
Code:
1. Close branch: Sending current work to test
Git:
1. Get Current Project Link : Getting current project link for built team
2.3 User Classes and Characteristics
 Typical Users, such as students, who want to be organized while developing pro-
grams not big projects.
 Big Companies, which want to handle more than one projects at once. Developer
team and project managers can work together easily with this software.
2.4 Operating Environment
 Web
 LocalHost
2.5 Design and Implementation Constraints
In the planning section, there are 5 lists by default including ToDo, Doing, Built, Test
and Deploy. So the manager can not set the number of lists and name of lists.
Each work has to pass successfully from all the lists until it is deployed. For example,
a non-built work can not be tested.
The manager can not manually switch works from one list to another.
2.6 User Documentation
Administrators create a project via Trello and authorize speci c members for this project.
Members plan to do the work after the plan will be recorded in the section. A member
of the Coding team chooses one of the tasks to be done and indicates that he is working
on it, and the job goes to the doing section. After completing its work through github,
it says that it has delivered the built. Built members is delivered to the test members
if successful. test members is delivered to the deploy members if successful. Therefore,
the application will run after you complete certain steps on trello.
7
2.7 Assumptions and Dependencies
DevOps communicates via the trello and github tools, and there are some restrictions
on the use of these tools via the DevOps portals. The trello tool can only be used online
because the trello tool does not have Local Server support.
8
3 External Interface Requirements
3.1 User Interfaces
Figure 3.1
9
3.2 Hardware Interfaces
Figure 3.2
3.3 Software Interfaces
Figure 3.3.
10
4 System Features
4.1 Cards
Everything you need to organize projects of any size. Open a card and you can add
comments, upload le attachments, create checklists, add labels and due dates, and
more.
4.1.1 Description and Priority
Open a card to keep information such as attachments, checklists and due dates. Priority:
High
4.1.2 Stimulus/Response Sequences
Users can open and close cards,in case they are managers, they can assign cards to
others.
4.1.3 Functional Requirements
REQ-1:Cards will not appear on the list when they are closed.Closed cards are considered
successful. REQ-2:Users are responsible for bad-input
4.2 User Management
What project managers do with users which are registered to the project
4.2.1 Description and Priority
Managing user in a project. Priority: High.
4.2.2 Stimulus/Response Sequences
Project Managers can add and remove anyone to the project and keep track of changes.
4.2.3 Functional Requirements
REQ-1: Those who are not registered to the system cannot be added to the project.
REQ-2: Users can use other tools when they are added. REQ-3: User information will
be stored in a database and will be compared when they log in.
11
4.3 Boards
A list is a collection of cards. They may represent a collection of ideas, things to
remember, or di erent stages of a work
ow.
4.3.1 Stimulus/Response Sequences
Users can create boards from cards they can also edit and remove them.
4.3.2 Functional Requirements
REQ-1:Boards must have cards. REQ-2:Empty boards must not be shown.
12
5 Other Nonfunctional Requirements
5.1 Performance Requirements
Plan and Code" is dependent on GitHub and Trello performances.
The board performance for boards which has lots of cards (>1000) the board might
not perform as well. Because Trello has to load open cards and attachments every time
a board is opened, boards with a large number of open cards may see slower load times
and generally reduced usability. We suggest having fewer than 1,000 open cards on any
Trello board (and under 500 if there are a lot of attachments or checklists on the cards).
5.2 Safety Requirements
"Plan and Code" is dependent on GitHub and Trello safeties.
GitHub provides dedicated rewall and VPN services to help block unauthorized sys-
tem access and also provides Distributed Denial of Service (DDoS) mitigation services.
5.3 Security Requirements
GitHub provides dedicated rewall and VPN services to help block unauthorized system
access and also provides Distributed Denial of Service (DDoS) mitigation services.
The Safe Harbor (http://export.gov/safeharbor/) framework used as a guideline for
good security practice for Trello. The Trello speci c security policy can be found here
https://trello.com/privacy.
5.4 Software Quality Attributes
Plan and Code" provides to use planning and coding together with interactive way on
DevOps Portal from both experts and typical users. However, users must already have
a basic knowledge of Trello and GitHub before using it.
13
6 Other Requirements
6.1 Appendix A: Glossary
1. Project: Every project is represented as Board in Trello. When a project is created,
new Board is created in Trello.
2. Work: Every work is represented as Card in Trello. When a work is created, a
new Card is created in current board”s To Do" list in Trello. Card”s location in
board will change in time. Ex. if test is successful for any card, this card will be
carried to Done" list. When user chooses to start work on chosen work. Card
will be carried to Doing" list.
3. List: As mentioned above, Projects are represented as Boards in Trello.When a
project is created, there will be 6 default lists in this board as: To Do" Doing"
Build" Test" Deploy" Done"
4. Branch: Every work is represented as Branch in GitHub. When close branch is
pressed, code will be sent to test.


Tüm Yorumlar - All Contents