Software Eng. Mat - 1

The Sohware Develop.
Life Cycle and Its

Application
The Sohware Development Life Cycle and Its Application
Abstract
The Sohware Development Life Cycle (SLDC) is a concept that is incredibly important to have a deep
understanding of as a sohware engineer. With this project, my goal was to learn the complexities of each
step conceptually and apply my skills to an actual application. The SDLC includes the following phases:
planning and requirement analysis, design and development, implementation, testing, integration, and
maintenance. In order to apply these concepts, I created a web application for users to schedule messages to
be sent at a future time and date. The API is written in Ruby on Rails and the front end is written in
ReactJS. There is also a PostgreSQL database that stores data such as saved messages and user
information.
Table of Contents 2
Abstract 3
Keywords 3
1. Introduction 3
2. The Software Development Life Cycle 4
2.0 What is it? 4
2.1 The Phases 6
2.1.0 Initiation 6
2.1.l System Concept Development 6
2.1.2 Planning 6
2.1.3 Requirements Analysis 7
2.1.4 Design 7
2.1.5 Development 7
2.1.6 Integration and Testing 8
2.1.7 Implementation 8
2.1.8 Operations and Maintenance 9
2.1.9 Disposition 9
2.2 Agile Development and Extreme Programming 9
2.2.0 Application of Agile and XP in this Application 11
3. My Application 11
3.0 Phases and their Results 11
3.0.0 Initiation 11
3.0.l System Concept Development 12
3.0.2 Planning and Requirements Analysis 13
3.0.3 Design 14
3.0.4 Development 20
3.0.5 Integration and Testing 20
3.0.6 Repetition of Phases 21
3.0.7 Implementation 21
3.0.8 Operations and Maintenance 22
3.0.9 Disposition 22
3.1 Technologies Used 22
4. Conclusion 22
5. Future Work 23
6. Link to Source Code 24
Appendix A - Client Contract 25
Appendix B - Software Requirement Specification Document 26
Citations 31
THE SOFTWARE DEVELOPMENT LIFE CYCLE 2
Abstract
The Software Development Life Cycle (SLDC) is a concept that is incredibly
important to have a deep understanding of as a software engineer. With this project,
my goal was to learn the complexities of each step conceptually and apply my skills to
an actual application. The SDLC includes the following phases: planning and
requirement analysis, design and development, implementation, testing, integration, and
maintenance. In order to apply these concepts, I created a web application for users
to schedule messages to be sent at a future time and date. The API is written in Ruby
on Rails and the front end is written in ReactJS. There is also a PostgreSQL database
that stores data such as saved messages and user information.
Keywords
Software, Life Cycle, Application, Design, Development
1. Introduction
The Software Development Life Cycle (SDLC) has been widely adapted through most,
if not all, technology based companies. With the advancement oftechnology, and the
increasing number of companies that rely on their own custom applications, learning
and understanding the complexities of the SDLC is increasingly important. Of course
knowing how to code is the basis for any software engineering career, but
understanding
the SDLC brings a lot ofnew skill bases to the table, all of which are beneficial to the
engineering process. These skills include planning, designing, and testing. The SDLC
traditionally has ten phases which are initiation, system concept development, planning,
requirements analysis, design, development, integration and testing, implementation,
operations and maintenance, and disposition [2]. Despite being distinct phases, they are
not all required in every situation and often are either skipped or combined together [2].
These phases are all addressed in more detail later. Additionally, variations on the SDLC,
including increasingly important aspects devoted to security in software engineering, are
addressed as well [reference].
Created and illustrated here is a web application made with the intention of learning and
critiquing the phases demonstrated in the SDLC. The application serves the purpose to
allow users to schedule messages to be sent to any person. It is written in ReactJS and
Ruby on Rails, with a PostgreSQL database. Due to the importance ofa client in the
SDLC, a fellow student, studying similar concepts, acted as the client for this project. The
intricacies of the application and important pieces ofcode are reviewed later.
2. The Software Development Life Cycle
2.0 What is it?
The Software Development Life Cycle is a basis or framework for structuring, planning,
and executing tasks involved with developing an information system [5]. Due to the
difference in requirements ofsystems along with numerous other differences, variations
on the SDLC have been developed. Before beginning a project, it is important to
determine which of these is the most suitable, especially with the recent advancement
of web-based technologies [5]. The SDLC includes distinct phases designed to give
software engineers a clearly defined goal for how to work [2]. It aims to aid
developers and other project staff to create a system that meets all technical and user
requirements as well as exceeds customer expectations [2]. These phases all revolve
around a central theme of quality assurance. The major priority of the project team is to
provide quality software to the users and client. A visual ofthis cycle is demonstrated
below.
System
Disposition • Initiation •I Concept
Developme
nt
f
Operations
& Planning
Maintenance
Quality
Assurance
Requirement
s Analysis
Design
-
THE SOFTWARE DEVELOPMENT LIFE CYCLE s
2.1 The Phases

Much of the information described here comes from resource [2].
2.1.0 Initiation
The Initiation phases identifies a problem to be solved through software engineering. A project
sponsor must be chosen; this is a person of authority over the project and is in charge of mediating
issues of scope and determining functional requirements. It is also stressed that this process be
documented and a concept proposal is expected to be a deliverable. This document illustrates the
needs defined in business terms and the overall mission of the system. The Concept Proposal is
made by the program manager or sponsor and is presented to the executive board for approval.
2.1.1 System Concept Development
System Concept Development is used to define the scope of the system. This may include a high-
level schedule, cost summary, and other plans that may be required for the specific type of
system, usually determined by all members of the project team. Documents made during this
phase may include the System Boundary Document, Cost Benefit Analysis, Feasibility Study,
and Risk Management Plan. These documents are typically presented to stakeholders for
review and approval.
2.1.2 Planning
Most ofthe documents needed during the other phases of the SDLC are made here. These may
include an Acquisition Plan, Concept of Operations, and Project Management Plan, but there are
many more that may be relevant to different projects. A summary is usually presented to
stakeholders at this point, and a detailed plan is presented and reviewed.
2.1.3 Requirements Analysis
The Requirements Analysis phase starts after the documents prepared in the previous
phases are reviewed and approved. Any document stating user needs in the system
will serve as the basis for document created in this phase that illustrate user requirements
and system requirements. Details such as system inputs, interfaces, and processes are
described here. Typically, a Software Requirement Specification document or
Functional Requirements document is created during this phase which includes
information about how to meet user requirements. This may address issues with users
with disabilities such as color-blindness, hearing loss, or cognitive disabilities, or
mobility impairments. A Test Plan may also be created during this phase and may
include details on unit test, integration test, and/or system tests. The portion
ofdocumentation is often created by the development team with the help ofa Quality
Assurance (QA) team whose purpose is to make sure different types ofusers can
easily use the system.
2.1.4 Design
In the Design phase, detailed requirements are to be turned into detailed specifications
that engineers will use during the Development phase. These specifications should
address how functional, physical, interface, and data requirements are to be met in the
system. This is usually done iteratively through the entire life cycle process. Designs may
include database designs and user interface designs.
2.1.5 Development
The purpose ofthe Development phase is to convert designs from the Design phase into
a functional system. This not only includes the software that should be written, but also
the infrastructure that should be set in place. These infrastructures may include
hardware,
software, and communication systems that are required for the functionality of the overall system.
Besides the code that is written, some deliverables expected as a result of this phase include a
Contingency Plan that directs the client what to do in case of emergency; a Software
Development document which illustrates test cases and results, how the components work, and
approvals; the test files and data; and an Integration Document which illustrates how the software
and hardware components work together.
2.1.6 Integration and Testing
The Integration and Testing phase aims to determine if the requirements specified in the
specifications document are met. Three different types of testing are ideal to include in this
phase: integration testing of subsystems, security testing, user testing or acceptance testing, and
unit testing. Each of these types of tests setve a different purpose and help all stakeholders
determine flaws in the system prior to deployment. Unit testing, which tests small portions of
code and is traditionally done during the development phase. Several analysis reports may be
produced from these tests and should presented to stakeholders before moving on to the
implementation phase. During this meeting, details on how implementation should take place
are imperative to address.
2.1.7 Implementation
During this phase, the system is deployed to the production environment. It is important to
inform users of the potential system changes prior to deployment and to train any professionals
on the new system if required. A post-implementation review is commonly completed to make
sure all requirements are met and the system is functioning in production as expected.
Ifeverything is in order, a contract between the development
team and the client project manager is signed, stating that the system has been completed
and delivered [2].
2.1.8 Operations and Maintenance
More than half the cost of the development life cycle is due to the Operations and
Maintenance phase. This phase may include identifying system operations, maintaining
data, identifying problems, and revising documentation that received additional analysis
(e.g. security audit/analysis). A User-Satisfaction report may be developed during this
phase to identify and potential user end problems to address in future development
iterations.
2.1.9 Disposition
This phase is done only when a system has become obsolete or been replaced by
another. Prior to shutting down the system, it is necessary to make sure all documentation
and resources are in order. A plan for shutdown should be written and followed
strictly, making sure to backup all resources and data from the system. It is also
recommended that a security and contingency plan be made and stored with the system
in case it has to be setup again.
2.2 Agile Development and Extreme Programming
Agile development is an iterative process that aims to increase the speed of development
by working incrementally. Agile development techniques include customer involvement,
incremental delivery, flexibility for developers to make their own development plan,
being open to constant change, and keeping code and overall system simple for future
expansion [6], [7]. A comparison of agile and the more traditional plan-driven
development is illustrated below [6].

(� 0
) ►1�=1
Extreme Programming (XP) is an extreme approach to iterative development and stresses

the importance of delivering small increments of the system (sometimes multiple
increments each day) and testing for each build of the system increments. Some of
the techniques used in extreme programming include incremental planning, small
releases, simple design, test driven development, refactoring, pair programming,
collective ownership, continuous integration, sustainable pace, and having an on-site
customer. XP techniques are commonly used in agile development life cycles.
Below is a diagram illustrating a simple example of extreme programming [6].

(�
}-{::=.}-{�rte-)
I
c = >-<= > c� �,
I
Agile development and extreme programming both focus on decreasing delivery time and
therefore, often lack the amount ofdocumentation seen in other types ofdevelopment
such as waterfall or plan-based development [6].
2.2.0 Application of Agile and XP in this Application
Working in small increments, test driven development, and refactoring were all
used during the construction ofthe application in this case.
3. REO: A Message Scheduling Application
3.0 Phases and their Results
3.0.0 Initiation
The purpose of the application, REO (short for reoccur), is illustrated below.
With the constant distractions of today's society, reminders are important.
These reminders may be for tasks that need to be completed, to laugh, or
to wish someone a happy holiday. With the application "REO", short for
reoccur, this is all possible. Users of the web-based application are able
to schedule messages to be sent to themselves, a family member, or a
project group. Either emails or text messages, users of REO can get
helpful reminders to complete tasks, send their significant other funny
images every day, or use for business purposes to make sure meeting
attendees are present. The uses for REO are endless and there is a
significant amount of potential for expansion.
The Concept Proposal in my case was created by myselfand presented to the client for
approval. The agreement is slightly different from the one illustrated by the DOJ [2] but
includes relevant information and signatures confirming the initiation ofthis project.
Appendix A shows a copy ofthe agreement. A physical copy with signatures was also
signed on the same date. Below is the agreement text.

THE SOFTWARE DEVELOPMENT LIFE CYCLE II
••Tue client agrees to sponsor this system development and work
with the developer to determine user requirements and technological
restrictions and requirements.
The project manager agrees to oversee this project and work with the
client project manager/sponsor to determine user requirements and
technological restrictions and requirements.
Both project manager and client agree to meet every other week after
project initiation to discuss details and progress on development."
3.0.1 System Concept Development
Since this project had no cost (besides my own time), no Cost-Benefit Analysis
was done. However, much of the other scope planning was done through the
proposal submitted for a scholarship to do this project. This was done prior to
the beginning of the semester. A high-level schedule was created to mark
intended milestones. The milestones indicated below, are the components to be
completed during each week and (in bold) each sprint.
Schedule
Jan 8 - Start of project
Jan 15 - planning
Jan 22 - project setup and login
page Feb 5 - home page
Feb 19 - new message page
March 5 - scheduled messages page/component

Not every week has a deliverable because some components may take longer than others, or
additional phases needed be done during that time. This schedule was made in consultation with
the client.
3.0.2 Planning and Requirements Analysis
The Planning and Requirements Analysis phases, in this case, were combined into one phase.
Traditionally, there are many planning documents that need to be made and reviewed, especially
for large systems with large teams. However, in this case, with the size of the development team
and having only one person represent the client, these documents were not required. Instead, the
planning took place as more of a conversation and the results were compiled into the Software
Requirements Specifications document, traditionally created during the Requirements Analysis
phase. This document specifies the purpose of the application, descriptions of user actions and
components, interface requirements, and nontechnical requirements.
The document illustrates the high-level components to be included in the application, also
specifying which components are of lower priority and are to be addressed in subsequent
installments of development. Below is a list of the high-level components.
• Login page
• Sign-Up Page
• Dashboard/Homepage
• New Message Page
The full document, which shows the subcomponents of the pages listed above, can be
referenced in Appendix B.
3.0.3 Design
The Design phase is often repeated through the development process when new designs
are needed that were not originally anticipated or need to be edited to accommodate
new or unforeseen circumstances. Most ofthe sprints of this project involved some
edits or additions to designs.
Below are the user interface designs followed by the database designs for the system
including the logo, signup and login page, home page and new message page. Links
included in the designs including 'Settings', 'Friends', and 'REO Gold' are features to be
implemented in future iterations ofthe project.
Logo
Login Page
Sign-Up Page
THE SOFTWARE DEVELOPMENT LIFE CYCLE IS
Dashboard/Homepage
R
welcome back! Dashboard
lc,qr.ut
Dashboard
New Message Message to Harry Potter Message to Harry Potter
scheduledfor eveiyday@ 12:00pm scheduledfor everyday@ 12:00pm
Friends ·Lore m Ipsum dolo,sit amet. .ore, ips1 dolo, it Imt't.
REOGold c onse ctetur adipiscing elit, sectdo corsec1e1ur actipisci"lg elu. sectdo •
Settings elusmodtempor ,n cldidunt utlaborc. , usnodt oor incididunt ut labore ...
New Message Page

- --
REO
- -
LC,co.
Welcome backr New

Message • Emall 30 X
Dashboard Choosefile from folder
New Message
Friends
REOGold
settings
Database Design
Below is the Entity Relation (ER) diagram for the database system of the application. In
this case, there are only two tables, Users and Messages. Users have a unique usemarne,
password, first_narne, last_narne, email, and phone number. Messages have
unique combination of to_whom [the message is sent], from_whom [the message is sent], and
time. Messages also have a reminder_time, type (email or text), reminder (true or false),
repeat, attachment, and text. The only relationship is that Users send Messages.
This information is all represented in the ER diagram below.
�-
�
�e------------- u-s"'"e'-R-
-� --- --- --
ema11
A design of the database showing similar information to the above ER diagram is below. It
indicates the types for each attribute ofthe entities.
USER
usemame password first_name last_name email phone
varchar(20) password varchar(20) varchar(20) varchar(50) char(IO)
MESSAGE
reminder_time text
varchar(50) varchar(20) DateTime DateTime varchar(500)

foreign key �> USER.usemame

j
--, -
attachment repeat reminder type
file enum(daily, weekly, monthly, yearly) DateTime enum(email, text)

I
Some additional UML diagrams developed during the design phase are included
below. UML Use Case Diagram
Gmall
API
Acto
r
User
UML Class Diagram
! User
+ usemame unique SUing
+ name· siring
M
Message
+ phone: stnng
+ to: siring
+ email siring
+ lrcm. User
+ password: passwd + type enum(TEXT, EMAIL)
+messages Messa98{0 :1 + reminder boot
N
+ createMessage() + reminder tlme DateTme
+ deleteMessage0 + attachment string
+ viewMessagesU + repeat:
enumlDAILY.
+login() WEEKl.Y, MONTHLY,
YEARLY)
+ logout() + text: su,ng
..
--
J
UML Interaction Diagram
Inltlallzatlon User Message
creates
createMessage{)
-
3.0.4 Development
During this phase, the database design is turned into a database system. The database system in
this case used PostgreSQL. Additionally, the user interface designs were converted into ReactJS
components. Components in ReactJS are small parts of pages. For example, the header for each
page is a component that can be used repeatedly on each page. This is convenient because there
is a lot less repeat code than other frameworks or basic HTML. API endpoints, from where data can
be collected, were created in the Rails portion ofthe application. The server listens for endpoint
strings that match the API endpoints from Redux which calls the APL On a successful match,
the API sends back the specified data. An example of this might be ' api/$ {user}/messages·
where user represents a variable (i.e. the user that is requesting the data). This API endpoint
would return all the scheduled messages that the specified user has scheduled. Some ofthe
development phase usually involves testing, primarily unit testing. In this case, test driven
development was used throughout the development phase. Test driven development (TDD) is
where the test is written before the functionality and the functions are written to make the tests
pass. This is an Extreme Programming technique used frequently in Agile development. TDD is
beneficial for many reasons including easier refactoring.
3.0.5 Integration and Testing
Much of the testing of the system was done during the development phase due to TDD.
Since the developer team was only made up of one person and the client understands the easy-
to-read tests, creating documentation ofthese tests and their results did not seem
necessary. Especially considering much of this life cycle was similar to agile methods, lack of
documentation was not a problem.
3.0.6 Repetition of Phases
Similar to how Agile development functions, several phases during this life cycle process were
repeated. Design, Development, and Testing phases were repeated for most of the sprints.
Also common to Agile, is the use of sprints which is the name of short periods of time in which
developers are to "sprint" to complete features. Much of the life cycle process was perfonned
iteratively. Agile development stresses the importance of client communication and feedback
which constitutes sprint review meetings: meetings held after each sprint with the client to discuss
what has been done and what is to be completed next. I met with my client after every two-
week sprint. Since the majority of the project was completed in accordance with the previously
planned schedule, there was never much concern from the client. He did provide some design
critiques however, which were implemented into the system.
3.0.7 Implementation
This application was not far enough along in the process to be deployed to a production server but
was set up using Heroku in a development environment which could be used in the future to test
production setup. Heroku is an easy-to-use deployment service based on Amazon Web Services
and supports a wide variety of languages including ruby which was used here.
3.0.8 Operations and Maintenance
Due to the short time span dedicated to doing this project, this phase was not possible.
As the project continues to be developed, maintenance will become increasingly
important especially as exposure and the number ofusers increases.
3.0.9 Disposition
Since the system has not become obsolete, the Disposition phase was not required.
However, ifthe system is replaced or shutdown in the future, following the guidelines for
the Disposition phase will become pertinent.
3.1 Technologies Used
This application is made using ReactJS, a Javascript framework, on the front-end (user
interface), Redux to manage the state of the application, and Ruby on Rails which acts as
the Application Programming Interface (API) and directly communicates with the
PostgreSQL database system.
4. Conclusion
The Software Development Life Cycle (SDLC) is widely used in technology based
companies and variations such as agile development with extreme programming have
become increasingly popular as the importance of clean code and fast delivery rises. I
have researched the ten phases of the SDLC and applied the techniques to creating my
own web-based application. The application created is a message scheduler that aims to
help people remember tasks, send reminders to others, or send encouraging messages to
friends. The application uses ReactJS to create the user interface which communicates
through Redux, the state manager, to Ruby on Rails which is the application
programming interface (API) and directly queries the PostgreSQL database.
5. Future Work
Security is also a topic that is becoming increasingly important when discussing
development especially with the advancement ofweb technologies [3], [8]. Due to this
innovation, including security in the phases of the SDLC is essential.
The Secure SDLC is a variation ofthe SDLC that stresses the importance of security
[8]. Most security defects are due to known software defects [8]. Multiple frameworks
have been made for detecting and fixing these issues before a product makes it to
production. However, these are difficult to adapt into already functioning software
development life cycles. Some tools used to address security throughout the software
development life cycle include threat models, penetration testing, and ratings.
Difficulties in security are most commonly seen or are developed during the design phase
[4] [I]. Creating security models including threat models, risk estimation, and
identification of security goals [4] can be done during this phase to ensure more secure
software.
The difficulties with using these new methods, especially in an agile based life cycle, is
that it often consumes large costs, both time and money. Additionally, if developers are
unfamiliar with security or the concepts recommended to make their code more secure,
they are unlikely to implement the changes to the life cycle. One research study
recommends training individuals on these techniques [4] which may solve the problem of
knowledge but would increase costs.
Despite these cost issues, implementing security into the software life cycle is
incredibly important. With the advancement oftechnology and the reliability users
expect systems to have, any vulnerability puts the company at risk. With some initial
training, developers would be able to have a better basis for how to fix problems they
already know exist in their code base(s). Though there is a great time and financial cost
for this training, it will outweigh the consequential risks ofnot putting security as a top
priority during the development life cycle.
For this project, implementing these techniques in future iterations is a high priority,
especially as deploying to production draws nearer.
6. Link to Source Code

https://github.com/GillianLemke/MessageScheduler
Appendix A - Client Contract
Concept Proposal and System Development Agreement for REO
Stakeholders
Project Manager: Gillian Lemke
Client Project Manager/Sponsor: Jacob Rickerd
Description of System
With the constant distractions oftoday's society, reminders are important. These
reminders may be for tasks the need to be completed, to laugh, or to wish someone a
happy holiday. With the application "REO", short for reoccur, this is all possible. Users
ofthe web-based application are able to schedule messages to be sent to themselves, a
family member, or a project group. Either emails or text messages, users of REO can get
helpful reminders to complete tasks, send their significant other funny images everyday,
or use for business purposes to make sure meeting attendees are present. The uses for
REO are endless and there is a significant amount of potential for expansion.
Agreement to Complete System and Collectively Determine Requirements

The client agrees to sponsor this system development and work with the
developer to detennine user requirements and technological restrictions and
requirements.
The project manager agrees to oversee this project and work with the client
project manager/sponsor to detennine user requirements and technological
restrictions and requirements.
Both project manager and client agree to meet every other week after project initiation to
discuss details and progress on development
January 2. 2018
Client Signature Date
January 2. 2018
Developer Signature Date
Appendix B - Software Requirement Specification Document* **

*Page numbers changed here for consistency with rest of document
** Original document contains database designs
Table of Contents
Table of Contents..............................................................................................................25
1. Introduction.................................................................................................................26
1.1 Purpose................................................................................................................... 26
1 .2 Document Conventions............................................................................................. 26
1 .3 Intended Audience and Reading Suggestions............................................................26
1 .4 Product Scope........................................................................................................... 26
1 .5 References............................................................................................................... 27
2. Overall Description....................................................................................................27
2.1 Product Perspective................................................................................................. 27
2.2 Product Functions.................................................................................................... 27
2.3 User Classes and Characteristics.............................................................................27
2.4 Operating Environment........................................................................................... 28
2.5 User Documentation............................................................................................... 28
2.6 Assumptions and Dependencies...............................................................................28
3. External Interface Requirements..................................................................................28
3.1 User Interfaces........................................................................................................ 28
3.2 Hardware lnterfaces................................................................................................. 28
3.3 Software Interfaces.................................................................................................. 29
3.4 Communications Interfaces...................................................................................... 29
4. Other Nonfunctional Requirements.........................................................................29
4.1 Performance Requirements...................................................................................... 29
4.2 Security Requirements............................................................................................. 29
4.3 Software Quality Attributes...................................................................................... 29
1. Introduction
1.1 Purpose
This web application is a servicefor scheduling messages, either email or text messages.
Many audiences will be able to use thisproduct. For example, teachers can use it to send
reminders to students, students can send themselves reminders, parents can send their
children chore lists or daily to dos. friends can send each otherfunny messages orpictures,
significant others can send anniversary messages. family can wish each other happy
holidays or birlhdays, and many olher situations. The service this application provides is
relevant to allpeople ofdifferentprofessions, ages, andpurposes. This is thefirst installment
ofthe application and when it is released, will be version 1.0. The scope ofthis installment
will cover basic login and authentication, a homepage/dashboard where users can view
scheduled messages and can create new ones, a settings page. Version 1.0 will only allowfor
emails to be sent. Otherfeatures may be added as we come across their need, however, for
thefirst release, we will try to keep it simple so we can deploy quickly.
1.2 Document Conventions
The basic requirements are illustrated in section I.I. Those requirements arefor thefirst
installment ofdevelopment and the application 'sfirst release. After that release, we will
illustrate additional requirements. These additional requirements that could be developed
during this installment but have a lowerpriority include adding Single Sign-On (SSO)
through Google, uploading contacts to the application to more easily send messages, sending
text messages, invitingfriends tojoin the platform, and others. Sending text messages will be
available 011/y through a "gold" account. This upgrade will cost aset amount per monthfor
unlimited text messages and a "silver" account will cost a smallfeefor each text message
sent. Thefeature allowing users to invitefriends, will give the user a week of.free "gold"
membership. Users will be able to sync their account with Facebook to invitefriends that
way. They can also invite friends through email. "Gold" and "silver" membership will be
pushed to the next installment of the project, while SSO and other smallfeatures will be
oflowpriorityfor the current installmell/.
1.3 Intended Audience and Reading Suggestions
This document isfor the clientproject leader, software engineers, designers, security
engineers, and testers. The rest ofthis document includes project scope, general descriptions,
and interface requirements. It is recommended thatproject manager(s) read only the
general descriptions while all engineers should read through the entirety ofthe document,
especially the requirements sections.
1.4 Product Scope
The goal ofthis service is to simplify lives through use ofreminders, make afun environmentfor
friends, and serve as a calendarfor groups or one 's self.
1.5 References
The Pivotal Tracker chart will serve as the developer 's toolfor keeping track ofcompleted
features. This will be the basisfor sprint reviews and weekly updates on progress. This is
also the place where any relevant development materials will be linked. For specifics on
stories/chores/bugs, review the project on Pivotal Tracker.
Pivotal Tracker project: created and maintained by Gillian Lemke - tech lead
2. Overall Description
2.1 Product Perspective
This is a self-containedproduct. This specific release is the beginning ofa large system with
additionalfeatures partially illustrated in section 1.2.
2.2 Product Functions

High level components include (items with • indicate lowpriority):
• Login page
• Signup page
• Dashboard/homepage
• New message page
• Settings page
• Signupl/ogin with Google*
2.3 User Classes and Characteristics

Components with characteristics include (items with • indicate lowpriority):
• Login page
o Username
o Password
o Authentication
o Login with Google*
• Sign-up page
o Username (unique)
o Name
o Password
o Phone number
o Signup with Google•
• Dashboard/homepage
o Preview ofscheduled messages
o Friends onli11e (available iflinked with Facebook) •
o Preview ofreceived messages (email only) •
o Signupfor membership*
• New message page
o Email option
o Message to send
o Contact email to send to

o Attach document/image*
o Search Google images/gift*
o Text option•
o Select contactfrom contact book*
o Send to Facebookfriend*
• Settings page
o Change password
o Change email
o Add/change avatar
o Ability to he searched*
o Setup Mo-factor authentication*
o Block user*
o Change language*
2.4 Operating Environment
This is a web application that will be responsivefor use on a mobile or

tablet view but will primarily be usedfor desktop. It must be compatible
with all web browsers including Google Chrome, Safari, Internet Explorer,
and Mozilla Firefox. A low priorityfor this installment is that it willfunction
with Google SSO. It mustfunction on all operating systems and will be
developed using MacOSX and will be tested on Ubuntu through
continuous integration.
2.5 User Documentation
The.first installment ofthe application will not include a user manual or

online help option.
2.6 Assumptions and Dependencies
We assume that the technologies selected by the developers are reliable.

Ifthefeature involving Google SSO is reached during this installment, we
assume the dependence is reliable.
3. External Interface Requirements

3.1 User Interfaces
Designsfor UI components are not yet completed. The components will be

built using ReactJS and will communicate with the AP/ through Redux.
The use ofMaterial UI is still under consideration.
3.2 Hardware Interfaces
The application should be supported on all web platforms.

3.3 Software Interfaces
The system willfunction starting.from the lowest level on a PostgreSQL

database. The AP/ will be built using Ruby on Rails and will communicate
with the user interface, which is built using React.JS, through Redux, a state
managementframework Webpack willpackage the project
before deploying to the server and will serve a single JavaScriptfile to users.
The application will be deployed on Heroku or Amazon Web Services and will
use TravisCIfor continuous integration with a connection through GitHub.
3.4 Communications Interfaces
Emails will be sent.from users using Google 's SMTP Server. This will ensure
proper encryption ofmessages, something that may be more difficult to
guarantee ifcompany server were to be used. The application itselfwill be
served through HTFPS and will use TLSforproper security.
4. Other Nonfunctional Requirements

4.1 Performance Requirements
Since Jhe project has not yet been deployed, performa11ce requireme11ts are
notyet know11. As the iteralions are released, requirements may be added to
this section and may include speed of queriesfor many users, speed ofthe
application 's server(s), and speed ofthe SMTP server.
4.2 Security Requirements
Security upon sign-in is incredibly important. The developers are in charge

ofdelermining the best lech110/ogies to usefor user authentication and
database encryption. Additionally, messages being sent and created must be
kept secure. Since Google 's SMTP server will be usedfor this, those security
concerns are low. The application, as previously mentioned, must be run over
HTFPS and use TLS. See Section 3.4for more on secure communications.
4.3 Software Quality Attributes
The application must be available to users.from across the globe. Since the
application is being developed iteratively, adaptability andflexibility are
important. There are many additional
features that will be added in other versions so keeping adaptability in mind
while developing is imperativefor the application 's success. In order to
ensure usability, QA testing is advised before the deployment ofthe.final
iteration. This QA testing will make sure the application is easy to use by
persons ofany technical background. Additional unit, integration, and
system testing is expected to be done during development to ensure clean
and reliable code.
THE SOFTWARE DEVELOPMENT LIFE CYCLE JO
Citations
1. Dasanayake, Sandun, Jouni Markkula, and Markku Oivo. "Concerns in software
development: a systematic mapping study." Proceedings of the 1 8th International
Conference on Evaluation and Assessment in Software Engineering. ACM, 2014.
2. The Department ofJustice Systems Development Life Cycle Guidance
Document. (2003) US Department of Justice.
3. Pistoia, Marco, and Omer Tripp. "Integrating Security, Analytics and Application
Management into the Mobile Development Lifecycle." Proceedings ofthe
2nd International Workshop on Mobile Development Lifecycle. ACM, 2014.
4. Rindell, Kalle, Sarni Hyrynsalmi, and Ville Leppanen. "Busting a myth: Review
ofagile security engineering methods!' Proceedings ofJhe I2th International
Conference on Availability, Reliability and Security. ACM, 201 7.
5. Selecting a development approach. (February 2005). Center for Medicare and
Medicaid Services.
6. Sommerville, I. (2016). Software engineering.
7. What is Agile Software Development Life Cycle? (March, 201 6). QuickScrum.
8. Yuan, Xiaohong, et al. "Retrieving relevant CAPEC attack patterns for secure
software development." Proceedings ofthe 9th Annual Cyber and
Information Security Research Conference. ACM, 201 4.

Software Eng. Mat - 1

Uploaded by

Copyright:

Available Formats

Software Eng. Mat - 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Eng. Mat - 1

Uploaded by

Copyright:

Available Formats

The Sohware Develop.

Life Cycle and Its

The Software Development Life Cycle (SLDC) is a concept that is incredibly

important to have a deep understanding of as a software engineer. With this project,

requirement analysis, design and development, implementation, testing, integration, and

that stores data such as saved messages and user information.

Software, Life Cycle, Application, Design, Development

and understanding the complexities of the SDLC is increasingly important. Of course

requirements analysis, design, development, integration and testing, implementation,

including increasingly important aspects devoted to security in software engineering, are

addressed as well [reference].

2. The Software Development Life Cycle

2.0 What is it?

difference in requirements ofsystems along with numerous other differences, variations

on the SDLC have been developed. Before beginning a project, it is important to

2.1 The Phases

2.1.1 System Concept Development

2.1.3 Requirements Analysis

2.1.6 Integration and Testing

and delivered [2].

2.1.8 Operations and Maintenance

(e.g. security audit/analysis). A User-Satisfaction report may be developed during this

in case it has to be setup again.

2.2 Agile Development and Extreme Programming

by working incrementally. Agile development techniques include customer involvement,

development is illustrated below [6].

Extreme Programming (XP) is an extreme approach to iterative development and stresses

Below is a diagram illustrating a simple example of extreme programming [6].

2.2.0 Application of Agile and XP in this Application

used during the construction ofthe application in this case.

3. REO: A Message Scheduling Application

3.0 Phases and their Results

With the constant distractions of today's society, reminders are important.

These reminders may be for tasks that need to be completed, to laugh, or

to schedule messages to be sent to themselves, a family member, or a

helpful reminders to complete tasks, send their significant other funny

significant amount of potential for expansion.

signed on the same date. Below is the agreement text.

••Tue client agrees to sponsor this system development and work

with the developer to determine user requirements and technological

restrictions and requirements.

client project manager/sponsor to determine user requirements and

technological restrictions and requirements.

project initiation to discuss details and progress on development."

3.0.1 System Concept Development

the beginning of the semester. A high-level schedule was created to mark

intended milestones. The milestones indicated below, are the components to be

completed during each week and (in bold) each sprint.

Jan 8 - Start of project

Jan 22 - project setup and login

page Feb 5 - home page

Feb 19 - new message page

March 5 - scheduled messages page/component

3.0.2 Planning and Requirements Analysis

• New Message Page

edits or additions to designs.

implemented in future iterations ofthe project.

New Message Page

Welcome backr New