· Stability in the Frequency Domain1. Consider a closed-loop sys.docx

· Stability in the Frequency Domain
1. Consider a closed-loop system that has the loop transfer
function L(s) = Gc(s)G(s) = Ke-TS / s
1. Determine the gain K so that the phase margin is 60 degrees
when T = 0.2.
2. Plot the phase margin versus the time delay T for K as in part
(a).
2. Include all MATLAB code, calculations and screenshots in a
Word entitled “Lab6_StudentID”.
3. Upload file “Lab6_StudentID”
Shipping SaaS 1
SWE482-1801A-01
Software Engineering Capstone II
Shipping SaaS Team Project
Blake Foster, Courie Gomez, James Allendoerfer, Joseph
Robinson, Terelle Allen
With additional contributions by Phillip Hart and Destiny
Barrera
1/10/2018
Table of Contents
Project Outline 3

Development Methodology 7
Requirements 9
Design 12
Development and Testing 18
Project Schedule 29
Risk Analysis 36
References 39
Project Outline
*Portions of this section have been repurposed from SWE481-
1704B-01 Unit 1 Group Project Proposal
CTU Regional has commissioned the design and implementation
of an inventory tracking and shipping service. The service is
needed as a centralized stateless/RESTful SaaS (Software as a
Service). The team developing the SaaS should be familiar in
database communication, API development, and network
communication. As the customers place an order, the payment is
processed and inventory is pulled from the warehouse. Once
completed, the order is fed to the shipping service, which will
then take on the role of managing the shipment. The service
provides API endpoints related to orders and shipping. The API
can be used by as many applications as necessary. Usage
examples might include employees updating the status of the
order at key points along the way (such as when inventory is
packaged, when the order is placed for carrier pickup, and
entering tracking), calculating shipping costs, or
creating/printing mailing labels. It will also track inventory
numbers and aid in the processing and management of the
shipments themselves. Employees must have access to make
updates as the order progresses. For example, warehouse
employees will be able to update when an order has been
picked, packed, and when it is shipped.

Here, the Shipping SaaS manages incoming order tracking
surrounded by four external systems, each requiring API access
and integration. That said, this picture will be expanded and
explained in greater detail later in the document. However,
there are some issues which need to be addressed.
The design of this application needs to be carefully created.
Since it is being designed with an API that can have a number
of different GUIs created to interact, the API needs to be
efficient, secure, well documented, and reliable. Below is a list
of major issues to consider in the development of the service
(Kodumal, 2015.)
Issues
Description
SaaS API Support from each system
Warehouse System, Customer Service System, Website Order
System.
SaaS Performance
Depending on the size and number of orders, there may be a
minimum level of performance required. Where performance is
the orders completed to time ratio.
Hardware Requirements
Given the system will need to keep track of many orders over
days to weeks, the storage requirements should be discussed.
For example, it may be cheaper and more reliable to use
Amazon Web Services, versus in-house hardware.
C.I.A. Considerations
To what degree will confidentiality be upheld? Considerations
for metrics which provide accountability regarding integrity and
availability should be discussed as well. For example, what are
the expected maintenance cycles for the service?
External System Failure
In the event of an external system failure, the system must be
able to handle such errors with elegance. That being, no data
loss unless the data needed to complete an order remains
incomplete.
Estimation and Scheduling

Developers sometime run into problems when having to
estimate and schedule how long it will take to develop the
software. It’s good to know what you’re getting into so that you
can better estimate the time (Writer, 2010).
Scope Creep
The project requirements and/or complexity grow and can start
to get out of control. Finally, human factors can put the project
at risk (Viswanathan, 2015).
Employee Turnover
Just like the group project it will have many different people. If
one of us have vital information for the project and leave the
group that’s project information that may never get added to the
project. The can really delay and cause a project to fail. It is
good to have sessions where the team can collaborate and share
knowledge (Writer, 2010).
Breakdown of Specification
When coding and integration begins sometime the requirements
might not be clear. This also can happen with the specification.
There can be conflict or it can be incomplete (Writer, 2010).
Productivity
There are times when projects will have long timeline. In this
case some developers tend to be a little laid back. The problem
with this is that it’s easy to lose significant time. It’s good to
set a schedule that is realistic and keep that schedule (Writer,
2010).
Logistics
The development team is not a centralized team so logistics are
a major concern. Logistics directly impact the communication
and collaboration of the team, if not properly addressed.
Gold Plating
It’s a known fact that the developers that are really good like to
show how good they really are. They sometimes add features
that are totally unnecessary. For example a developer will add
Flash to a simple login module just to make it look flashy. This
is a waste of time and programming hours (Writer, 2010).
Procedural Risks

Sometime day to day on the job and operation activities can go
lacking due to lack of understanding of responsibilities, the
priorities are conflicting, or improper process implementation
(Writer, 2010).
Technical Risks
There are times that firms try to diminish the functionality of
software. They do this because overruns that are connected to
high budgets and scheduling and they need to compensate for
this. There is always a battle when it comes to peak
performance and maximum functionality (Writer, 2010).
Unavoidable Risks
Unavoidable risks can include but not limited to obsolescence
of software, changes that happen in government policy, and
many other things that cannot be estimated. As the years have
gone by the software development has become a bit more
complex causing the risk to do the same. It is good to have a
plan to mitigate risks (Writer, 2010).
Development Methodology
*Portions of this section have been repurposed from SWE481-
1704B-01 Unit 1 Group Project Proposal
For this project, the scrum methodology has been selected. As
an agile methodology, scrum is iterative process that breaks
down the development into smaller chunks called sprints. Each
sprint lasts for a set period of time and consists of planning,
development, review, and retrospective. During the planning
stage top items from the backlog are selected. At the end of
each sprint a review is conducted to offer an informal look as to
what has been added or changed during the sprint. The
retrospective step allows for the team to look back at the sprint
and determine what is working and not working as far as the
development model is concerned (Sims, n.d.).
The Agile Method was birthed from real life project
experiences. There were professionals that were limited and
challenged from traditional methods such as Waterfall. The
approach that Agile takes is in response to all of the problems

that were being created in waterfall in the areas of philosophy
and specific processes. Agile is known for having a lightweight
framework that helps teams, giving a constantly developing
technical and functional landscape, and keeping focus on the
business value. One of the benefits of Agile is companies are
able to reduce the risk that is associated with software
development (Version One, n.d.).
Inside Agile there is a method call Scrum. The Scrum
methodology you have the ability to work in what we like to
call sprints. In this agile methodology sprints are set in blocks
of time. The sprints can range from two weeks up until a month.
At the start of a sprint there is a meeting that will take place. In
this meeting the team figures out all of the items they can
commit to and then create a log that states all of the tasks they
will perform during that sprint. In these meetings the Scrum
Master and the product owner are present (Mountain Goat
Software, n.d.).
In an Agile Scrum methodology, each developer is responsible
for completing a feature from initiation to implementation. A
scrum master (SM) is not the leader, rather is a coach, helping
each team member use Agile principles in order to best
complete their feature of work. The SM may also help define
the sprints to be implemented. The Agile methodology allows
for rapid independent development in order to combine features
into a full-fledged system.
Here is a figure taken from (Pressman, 2015) detailing the
scrum process:
Scrum is a lightweight subset of the Agile methodology. Our
current team is just 5 members, which is fitting for a
lightweight methodology. The team is also relatively
independent, also fitting for Agile. Our course is broken down
into 5 sections (sprints) with each member providing their own
unit of work (feature) and is done in a relatively rapid manner
(1 week per sprint). Due to these frequent deliverables, scrum’s
focus on teamwork, and this teams small size scrum is a

development methodology that is well fit for this project.
Requirements
Having a good set of requirements is essential to the success of
a project. Even the most talented development teams a project
will suffer with a bad or incomplete set of requirements. A
good set of requirements leads to fewer defects, less reworking
issues, and a product that is well fit to the needs of the end
users. To determine if a requirement is good it should be
something that customers think is needed, developers think is
achievable, testers think is testable, and stakeholders think will
fulfill the needs of the business (Perrigon, 2016.)
To gather requirements all stakeholders and a representative set
of users will be consulted to know their expectations for the
project. This will take clear communication and cooperation
between everyone involved. All stakeholders will be involved
through the entire requirement elicitation process and also the
remainder of the project. Initially all of the project’s goals and
objectives need to be established, and all requirements need to
be well documented and available to all stakeholders throughout
the project. When determining the requirements all
stakeholders will give their input based off their knowledge and
needs for the project. These requirements will be documented
and confirmed by everyone before the project progresses past
requirement elicitation. Since this project will be utilizing the
scrum methodology, requirements can be added or changed
without too much difficulty, a good set of requirements will set
the project up for success.
Ambler has provided the following basic diagram which models
the engagement between the developer and the stakeholder. This
diagram shows the responsibility of each party for determining
the requirements. The developer and the stakeholder both
collaborate together to solicit the main idea, discuss the idea as
a requirement, and model the potential requirement. The
developer is responsible for estimating the work, but the
stakeholder is responsible for determining the priority of the
requirement as the statement of their need (Ambler, n.d.).

For the Shipping SaaS, the following matrix begins to define the
main ideas for the requirements of the system in order to begin
design. The matrix will also show the analysis of each
requirement, its priority within the stack, and the state
(functional vs non-functional).
Requirement
F/NF
Description
rational
Measurement
Priority
Shippers
NF
Company that ships package
Need shippers in order to ship
High
Carries
NF
Company that delivers the package
Need carries in order to deliver
High
Calculate Price
F
Calculate price to ship package
So customers will get charged the correct price
Based on how its coded and the info received
High
SQL Database
F
Log information
To keep track of shipments
If information is logged or not
High
Fields for customer information

F
User can add information to these fields
So users can enter the correct information in the app
If the fields show up on the UI
High
PC and Phone Compatible
NF
Work all PC and cell Phones
So the user will have more choices
If the app work on all devices
Med
Add shippers and Carriers
F
Add new shippers and Carriers
New business are always arising so this function will help us
keep up with all of the new companies
If shippers and carriers can be added or not
Med
Log In
NF
Log into app
Extra Security
If users can sign in or not
High
Quick Response Time
NF
System to respond in less than 5 sec
So the user will continue to use the app
How fast the system is.
High
Firewall

NF
Layer of Protection
To make sure all of customer information is safe.
High
Design
This application is user the SaaS Architecture. When using the
SaaS Architecture there will be a single configuration that is
used for all carriers. This application can be installed on many
devices to support scalability. For testing purposes there will be
a second version installed to give a select few customers access
to the prerelease versions of the application. One benefit of
SaaS Architecture is you don’t have to deploy a large
infrastructure at a customer location. This will help with
eliminating the upfront commitment of resources (Hacker Noon,
n.d.).
Print Labels
Printer
DB
Order Details
Carrier
Ordering
Customer
The following class diagram depicts the class hierarchy and
begins to show the details and complexity for the required
components that are needed in order to fulfill the requirements.
On the surface, the service interacts with orders. However, the
service has to keep track of users; either individual users or
systems as users, both internal and external. At times the
customer may need to be contacted so that information needs to
be stored. The main goal of the service is to ship orders,
resulting in the need for payment and shipping information.
Since shipping requires a mailing label, the service must also be

able to store that information.
The following is a use case that shows how a warehouse
employee will be able to process an order from start to finish
and set the status in the system.
Additional textual use case examples are as follows:
1.1 Use Case Customer and Ordering
Actors
Customer
System
Purpose
The customer logins in their account and orders something.
Overview
Something needs to be ordered in order for our app to be used
Typical course of events
1. The customer logs in.
2. Order something.
3. Send the information to carrier.
System Response
Will notify the customer that their order is being processed.
1.2 Use Case Carrier
Actors
Carrier
System
Purpose
The carrier logins in their account to finish order.
Overview
The carrier inputs the order in to send it through the system.
1. The carrier logs in.
2. Finish the order by putting information in and making sure
it’s correct.
3. Send the order details so it can be logged in the database.
System Response
Will notify the carrier that their order is being processed.

1.3 Use Case Database
Actors
Database
Purpose
Log orders.
Overview
The DB captures every order that has been requested.
1. Details are sent form the carrier to the DB.
2. The DB logs the information.
3. It show if information is correct or not. (ShipRequest,
ShipResponse)
4. Information is sent so it can continue through the process
System Response
Will log all information dealing with shipments.
1.4 Use Case Printer
Actors
Printer
Purpose
Print Labels.
Overview
The printer gets a request and prints labels.
1. A request will come to the printer
2. Print out labels for boxes.
System Response
Print Successful.
The data that will be required will be what is on the UI above.
For Example, the UI will ask for product name: Beats By Dre,
Warehouse: East, Carrier: UPS, Carrier Service: Overnight,
Package Size: 1x1, Customer Id: 2654, Customer Name: James
Buford, and Address: 123 Capehart.

Since the application is a cloud service, it does not have an
interface of its own. However, an example interface of a
consuming application is below.
Main Screen
123 Capehart
James Buford
2654
1 x 1
Overnight
UPS
East
Beat By Dre
Product Name
Warehouse
Carrier
Service
Package Size
Customer Id
Customer Name
Address
Development and TestingDevelopment
Development of the shipping SaaS system is handled using a
Scrum subset of the Agile methodology. The key behind using
the methodology is that the process is lightweight and follows
quick iterations of code delivery, called sprints. These sprints
represent a window of time in which functionality will be coded
and delivered from start to finish. A graphical representation of
the process is below. Using Scrum, the development team will
be able to increase the quality of the deliverables, better handle
(and expect) changes to scope, provide quicker, better
estimates, and hold more control over the project schedule and
state (cprime, n.d.).

There are three key processes that will be used to drive the
development process. These processes will be detailed
below.Prototype
One of the processes that we will use is prototyping. The
prototyping process includes four steps.
1 Identify Requirements: In this step of the phase the software
publishers will figure out what the software will be able to do.
Then the users are selected and they will give there insight on
what they want from the software. Then the project is sent off to
the team that is going to develop it (Stanley, n.d.).
2 Develop Prototype: In this step the team will look over all of
the requirements that were given and then put a model together
of what a finished product will look like. The initial prototype
really can be simple. For example the prototype can be drawn
on a whiteboard or may a piece of paper. It doesn’t have to be
limited to that but it can be as simple as that (Stanley, n.d.).
3 Review: After the prototype has been developed the publisher
will have a chance to see what it looks like and how the team
envisioned what was given to them. If the prototype is more
advanced then the end user will have a chance to actually use
the product and then give some suggestions on what they feel
should be change or improved. This is called beta testing
(Stanley, n.d.).
4 Revise: This is the last step of the process. This step requires
the team to go back and make the necessary updates and
revisions to the prototype based on the feedback that they
received (Stanley, n.d.).Integration Testing
Another process that can be used is the integration Testing
process. There are four steps to this process.
1 Identify Unit Interfaces: The team or developer will identify
and document the unity interfaces. The following are examples
of unit operation:
· Responding to queries for information (Software Testing
Stuff, n.d.).
· Managing all data that is entered (Software Testing Stuff,

n.d.).
· Updating, creating, and managing all data that’s entered
(Software Testing Stuff, n.d.).
· Receiving and passing information from other units (Software
Testing Stuff, n.d.).
· Sending messages to different terminals (Software Testing
Stuff, n.d.).
· Providing results (Software Testing Stuff, n.d.).
2 Reconcile Interfaces for Completeness: All of the information
that is needed for integration test template comes from all
program units that are being tested. The reconciling of
interfaces happens when one unit interfaces with another. For
example if Unit A sends data to Unit B, Unit B should tell Unit
A that it received the data (Software Testing Stuff, n.d.).
3 Create Integration Test Conditions: Usually there are a few
test conditions that are already prepared for each unit. When the
condition is created, that condition is then put in the test
template (Software Testing Stuff, n.d.).
4 Evaluate the Completeness of Integration Test Conditions:
There are a few questions that can help with the evaluation of
the completeness of integration test conditions. They are:
1. Is there an integration test developed (Software Testing
Stuff, n.d.)?
2. Are all of the modules interfaces validated so that they can be
recorded (Software Testing Stuff, n.d.)?
3. Are the software units involved into the testing (Software
Testing Stuff, n.d.)?
4. Are the business transactions being tested (Software Testing
Stuff, n.d.)?
5. Are the terminal functions being tested (Software Testing
Stuff, n.d.)?IDE
IDE stands for Integrated Development environment. For this
project the team will be using NetBeans. The NetBeans
environment will allow us to produce the code for the project.
NetBeans has a great compiler and is one of the best when it
comes to programming in the Java Language.

Testing
Testing of software needs to be performed early and often. One
of the benefits to the scrum methodology is the early and
frequent deliverables that are created during each sprint. This
project will utilize unit testing, integration testing, system
testing, and user testing. These aspects will combine to ensure
that a quality product is being delivered.
Unit testing focuses on ensuring that each small piece of code is
working. This is not a test to ensure that requirements are being
successfully met, simply that each individual piece of code does
exactly what it is supposed to do. One of the goals of unit
testing is to find errors or defects in code before it is integrated
with other parts of the program. The tests that are created for
these unit tests are to be documented well so that they will be
repeatable. As much of the testing process will be scripted and
automated to ensure that testing can be done efficiently and
frequently. Utilizing JUnit will aid in the automation of these
tests allowing for testers to write code for the tests.
Integration testing takes the different units and tests that they
properly interact and function together. Even though each unit
may have been fully tested, they may not properly interact with
the other units. This testing is designed to help find issues
integrating these units together into one larger grouping of units
and eventually full program.
The next type of testing that will be utilized is system testing.
This type of testing will test the integrated system. One of the
focuses of this testing is to ensure that the software meets the
requirements. This will be done by comparing the requirements
with what is being delivered in a measurable way. Tests will be
created that test each function and if the proper result is
achieved, the test is considered successful.
Additional details are as follows:Unit Testing
The unit testing of software is mostly done during the coding of
the application. The main goal of unit testing is to take parts of
the code and make sure that they work correctly. For example if
the team wanted to see if the login piece of the code is working

correctly they would test only that part of the code. They will
test for things such as what happens if the wrong username or
password is entered. They can also test for the correct username
and password (Guru 99, n.d.).
There are plenty of times that developers try to get by only
doing minimal unit testing. Doing this will cause a high defect
rate which can lead to costly fixes during the system,
integration and beta testing. It’s safe to that doing proper unit
testing can save time and money (Guru 99, n.d.).System Testing
System testing is when the team is able to test a fully integrated
product. Normally software is an element of a bigger system.
Ultimately, software is interfaced with many different systems.
System testing is based on a series of test. These tests are
supposed to exercise the entire system. For example with our
shipping app the team world run test to see if the full process
work completely with no errors. The also will throw some
monkey wrenches in to make sure it fails when it supposed to
fail (Guru 99, n.d.).User Testing
Usability testing is when an actual user tests the end product.
For example one of the customers and shippers who will be
working with the product uses it to see how it works. In return
the development team is able to see if the user likes it or not.
The will also give the development team a chance to fix
anything that the customers don’t like about the system within
reason. This can sometime be called Beta testing
Below are some example test cases:Test Case 1
Test Suite ID
TS001
Test Case ID
TC001
Test Case Summary
To verify that user has access

Related Requirement
RS001
Prerequisites
1. User Name
2. Password
Test Procedure
1. Enter Username
2. Enter Password
3. Click Login
Test Data
1. User Name: Luke189_Fold
2. Password: YouCantStopMe
Expected Result
1. The system should give the user access to the application if
all of the credentials checks out
Actual Result
1. Access Granted
Status
Success
Remarks
This is a sample test case.
Created By
John Lane
Date of Creation
12/14/2017
Executed By
Jane Roe
Date of Execution
02/20/2017
Test Environment
· NetBeansTest Case 2
Test Suite ID
TS002
Test Case ID
TC002
Test Case Summary

To verify that a shipment can be shipped
Related Requirement
RS002
Prerequisites
1. User Name
2. Password
3. Shipper
4. Carrier
5. Dimensions
Test Procedure
1. Enter Username
2. Enter Password
3. Click Login
4. Enter Product Name
5. Enter Warehouse
6. Enter Carrier
7. Enter Service
8. Enter Package Size
9. Enter Customer Id
10. Enter Customer Name
11. Enter Address
12. Click Ship
Test Data
3. User Name: Luke189_Fold
4. Password: YouCantStopMe
5. Product Name: Beats By Dre
6. Enter Warehouse: East
7. Enter Carrier: UPS
8. Enter Service: Overnight
9. Enter Package Size: 1x1
10. Enter Customer Id: 2654
11. Enter Customer Name: James Buford
12. Enter Address: 123 Capehart Dr.
Expected Result
The system should send a request to and receive a response if
everything checks out.

Actual Result
Response Received
Status
Success
Remarks
Created By
John Lane
Date of Creation
12/14/2017
Executed By
Jane Roe
Date of Execution
02/20/2017
Test Environment
· NetBeansTest Case 3
Test Suite ID
TS003
Test Case ID
TC003
Test Case Summary
To verify that shipping information is logged in Database
Related Requirement
RS003
Prerequisites
1. User Name
2. Password
3. Shipper
4. Carrier
5. Dimensions
Test Procedure
1. Enter Username
2. Enter Password
3. Click Login
4. Enter Product Name
5. Enter Warehouse

6. Enter Carrier
7. Enter Service
8. Enter Package Size
9. Enter Customer Id
10. Enter Customer Name
11. Enter Address
12. Click Ship
13. Login to SQL server
14. Check Database
Test Data
1. Product Name: Beats By Dre
2. Enter Warehouse: East
3. Enter Carrier: UPS
4. Enter Service: Overnight
5. Enter Package Size: 1x1
6. Enter Customer Id: 2654
7. Enter Customer Name: James Buford
8. Enter Address: 123 Capehart Dr.
Expected Result
The record with the information provided should be in the
Database
Actual Result
Record Received
Status
Success
Remarks
Created By
Terry Buford
Date of Creation
1/14/2017
Executed By
Justin Rhodes
Date of Execution
1/20/2017
Test Environment

· NetBeans
· SQL Server
Project Schedule
The core scheduling concept in an Agile Scrum methodology is
iteration-based. Units of work are prioritized and grouped
together into small subsets and added to a time box known as a
sprint. The duration of the sprints are pre-determined and set by
the project team, the scrum master, and/or the product owner. In
this perspective, scheduling of the project is relatively simple
and rigid. The product owner, knowing the duration of each
sprint, prioritizes work items that the project team will add to
the sprint. The project team works as many items as possible for
the duration of the sprint. Work items that are not completed by
the end get moved back to the backlog and the process is
repeated for each additional sprint. Multiple sprints can be in-
flight at the same time, but does not change the schedule. The
end result is a constant project schedule that is determined in
the early stages of life of the project and is strictly followed
throughout the course of the project (Project Scheduling, n.d.).
In order to reach the optimal state of the process, there are
milestones that must be met. With Agile being a quick
methodology, these milestones are granular at the unit of work
level so as not to hold up other units of work if they are not
met. The key milestones are as follows:
Requirements – The product owner must identify their statement
of need. It must be able to be broken down to a unit of work
that can fit within the defined sprint window. It must be
justifiable. The requirement is turned in to a user story, which
is a unit of work, and added to the project backlog. It will then
be officially tracked using the workflow board of choice (such
as Target Process). Of all steps within the Agile Scrum process,
this milestone does not have a strict time box assigned to it. The
product owner is not held to any time standard for completing
requirements. However, the product owner should be aware that
the unit of work will not be eligible to be pulled from the

backlog until it is completed.
Grooming – The product owner and project team must be on the
same level of understanding of the requirements for the work.
The unit of work must be able to be completed within the
designated time box of the sprint. The goal of grooming is to
iron out any gray or questionable areas of the requirements. The
product owner will assign a priority of the task. The project
team will give a basic idea of complexity and/or time required.
Grooming sessions should occur weekly and be time boxed so as
to not require excessive time (such as 1 hour sessions). Any unit
of work that does not complete the grooming process
successfully remains in the product backlog until the next
session. Completed items of work are then eligible to be added
to the next sprint.
Iteration development – Successfully groomed items are added
to the sprint iteration. The development team designs, develops,
and completes the unit of work in the time box of the sprint. If a
unit of work cannot be completed in the allotted time box of the
sprint, it must return to the product backlog. Completed items
are pushed forward for testing.
Testing – Test builds are created based on units of work that
have successfully completed all of the above milestones.
Testing of each unit of work is not statically set to a fixed
duration, but the product owner and quality assurance team must
know that the unit of work cannot be deployed to production
until completed. Units of work that to do not pass testing must
return to the product backlog for correction.
While the timeline of the project as a whole is not constrained
by duration, each sprint required to complete the project is
bound to a set of pre-defined time boxes. The scrum master will
ensure that the timeline is strictly followed. Float is only
allowable in the requirements and testing phase, as these two
phases cannot be measured and constrained. However, in order
to meet the set duration of the sprint, there is a soft-deadline for
both processes (as seen in the following timeline). A work
board (such as Target Process) will be used to track units of

work throughout the process. The following timeline will be
followed for the Shipping SaaS project. As a reminder, the
timeline is not based on the project as a whole, rather at the
granular sprint level. The timeline may be repeated as many
times as necessary in order to complete all items in the product
backlog. The timeline must have at least one sprint and
additional optional sprints may be added as well (McGevna,
2012).
The project will flow a few different paths during developments
with the longest path taking only 1 day longer than the shortest
path. This does not leave much room for error in any path and
very little time to recover if any of the shorter paths happen to
get off schedule. Each path will need to stay on schedule as
much as possible.
Timeline and Gantt
Network Diagram
Float and Slack
Activity
Predecessor
Duration Days
A
-
5
B
A
3

C
A
5
D
B
2
E
C
7
F
C
4
ES
ACT
EF
LS
DUR
LF
TF = 3
8
D
10
11
2
13
FF = 0
TF = 3
B
3

10
E
13
10
3
13
5
B
8
8
3
11
13
F
17
13
4
17
FF = 0
TF = 0
TF = 0
0
A
5
FF = 0
0
5
5
5
C
10
5

5
10
FF = 0
FF = 0
FF = 0
TF = 0
TF = 0
Risk Analysis
Like any project, this one comes with certain risks. These risks
range in their likelihood and severity. Within this process, as
said by (Pressman, 2015), “There are two distinct types of risks
for each of the categories that have been presented in Section
35.2.” These risks are Generic risks, which are risks to every
software project and Product-Specific risks, or risks which only
affect the system being built. Pressman continues to outline
many metrics associated with identifying generic risks which
this project will use. These metrics are: product size, business
impact, stakeholder characteristics, process definitions,
development environment, Technology to be built, staff size,
and experience. In the following, the analysis will be
identifying how these metrics apply to the project, as well as
their associated risks.
Overall Product Size (PS) in the software sense refers to its
scope as well as resources it will need to consume to be
completed. Given this project requires a good deal of checks
and balances regarding the security of transporting order
information over a network, it is fair to say the size of this
project large, but not huge. That is, it will take a significant
amount of resources to effectively develop a scalable ordering
API. The risks involved in a project which takes resources
depends on the resources to be used themselves, and the risks
will be identified in the components of those resources.
The business impact (BI) of this project is hard to quantify.
That said the greatest impact will most likely be scalability.
However, this brings with it many risks. One of which is how

the system deals with a single system failure. For example, in
the case of a warehouse system failure the database won’t be
able to update the warehouse, but if handled correctly, the
ordering system should still post to the database, and when
available, the warehouse can receive the order updates.
Stakeholder characteristics (SC) in this project involves
knowledgeable individuals given that they maintain the current
systems in place. For example, the database system most likely
already contains many protocols that can be modified by the
database administrator to fit the new system. Likewise, the
website ordering system probably contains a back end which
interfaces with the existing database, made by an interface
technician. These stakeholders will need to provide information
for the new system. The risk associated with this is that they
may be resistant to change, or not as knowledgeable as expected
on the in-place systems, in which case additional time will need
to be allocated or alternative solutions in the sprint should be
identified.
Process Definition (PD) The software process has been defined
to a degree acceptable to the agile methodology. That is, while
in other methodologies more information regarding the build
definitions, current requirements, life cycle details, and project
deliverables should be defined, in agile, much of this is left up
to the experts developing and their current sprint. With that
being the case, software developing experts tend to enjoy
adding in features which don’t necessarily “need” to be
implemented, but make the system perform marginally better, or
easier to use. This is called feature creep and should be
monitored. An interface engineer may “pool” the number of
connected systems for example, while this may be useful in the
case of using hundreds of systems, this system does not contain
that kind of topology; pooling introduces needless complexity.
Development environment (DE) is unknown, however given the
business impact, it is best the developers work in the buddy
system. That is, two developers work together to solve issues
and analyze code as it is being produced.

The Technology to be built (TB) includes an API giving four
systems the capability to communicate & work together in a
distributed secure network. This introduces a large amount of
complexity, as systems will need to transfer data over a wide
area network. Risks involve things like data leaks or missing
encryption, and service interruptions or complications if a
network node goes down. As such, any network interruptions or
system failures will need to have a disaster recovery plan.
The Staff size and experience (SE) of this project is yet to be
known, but given the size, requires at least one Senior C#
Network Engineer, two C# Technical Interface Developers, one
Senior Software Engineer, and one Database Administrator able
to produce protocols for accessing the database. Outsourcing
black box tests is an effective solution to this situation as well.
Ensuring staff contains the required experience and knowledge
is a major risk to the project, though very unlikely.
Schedule slippage is a common problem with many projects of
scale. Any unexpected delays, including things as simple as
illness or unexpected absence of a team member, can throw off
the entire schedule. As an effort to mitigate this risk, an extra
“slippage” day has been strategically added to several phases of
the project. By not adding a block at the end of the project we
also reduce the likelihood of procrastination as employees
subconsciously add this block to their perceived sense of
urgency.
To help avoid or plan to mitigate these risks, some of the risks
have been identified through a brainstorming technique.
Brainstorming allows for people to give their ideas towards
possible risks, the more ideas given leads to more risks being
identified. Brainstorming is a good tool to use when dealing
with formative project planning. Brainstorming can also be used
to take advantage in finding risks and risk scenarios for
projects. Although brainstorming is very simple, it can be really
effective in a group setting. The good thing about brainstorming
it can be done in a way that people won’t have to be criticized
by other or feel inhibited. The way the team will do this is each

member will try to build on the ideas that are given by
preceding comments. There will be absolutely no criticism or
disapproving allowed. The main reason for brainstorming is to
encourage as many ideas that if done correctly it can cause
other ideas to be triggered (Ritter, 2008).
The following table lists the major risks identified for the
Shipping SaaS. The table includes specific functionality risks
(red), general project risks (blue), and architectural risks
(green).
Risk Name
Risk Description
Risk Likelihood
Risk Impact
Risk Impact Description
Risk Response
Risk Response Description
Login Issues
User may not be able to access account
High
High
May lose customers
Control
Make sure that there support team can fix this problem
Package gets lost
When package is shipped it doesn’t get to its destination
High
High
Customer may not get package on time
Avoid
All packages will have tracking number to show exactly where
the package is located.
Fee
Shipper gets charged the wrong fee
Medium
Medium
The shipper may get charged more than actual

Transfer
This should be taken care of by the carrier
Labels
Labels don’t print
High
High
Without the labels the packages cannot be shipped
Control
Make sure all printers are set up correctly.
Lost Information
Orders can be deleted
Low
Medium
May not be able to go back and check orders.
Avoid
Make sure that when data is logged it’s also saved into a backup
folder.
Scope Creep
Work does not follow what was initially specified
High
High
Set the project behind schedule and/or over budget.
Avoid
Changes will need approval from project management and the
customer. Customer will be made aware of the potential
changes to schedule and budget if the requirement is changed.
Human Factor
Development team fluctuations and schedules
High
High
Push the project off schedule
Control
Project management will need to asses in a case by case manner
if people can be moved around to cover the position, or if new
people are needed.
Experience

Development team work experience
Medium
Medium
Set the project off schedule and possible quality from lack of
experience.
Control
Project management will carefully select the team and continue
to monitor making changes as needed.
Security
Inadvertent exposure or deliberate unauthorized access
Low
High
Without proper security in place, customer and/or payment
information may end up “in the wrong hands”.
Avoid
Use security roles and access restrictions with redundancy.
Reliability
Service uptime and accuracy
Medium
High
If the service is unavailable, the customer will experience
delays that may be detrimental to their own bottom line. If the
service provides incorrect results, even just once, the customer
will have little faith in the service.
Control
Hardware redundancy will allow the service to fail-over to other
hardware devices in the event of a system outage.
Performance
Service response and timing
Medium
Medium
If the service they use is slow or cannot complete the work
within the same session then it may not be beneficial for them
to make use of that service.
Control
Full testing, from unit to system/integration. Proper building of

the hardware environment also ensures that the balanced amount
of server power is available for the requests to be able to
complete quickly
References
Ambler, S. W. (n.d.). Retrieved December 01, 2017, from
http://www.agilemodeling.com/essays/agileRequirementsBestPr
actices.htm
Guru99.com. (n.d.). How to Write Test Cases: Sample Template
with Examples. Retrieved December 06, 2017, from
https://www.guru99.com/test-case.html
Hacker Noon. (n.d.). SAAS(Softare as a Service) Platform
Architecture. Retrieved from https://hackernoon.com/saas-
software-as-a-service-platform-architecture-757a432270f5
Kodumal, J. (2015, September 30). What we talk about when we
talk about API reliability. Retrieved November 22, 2017, from
http://blog.launchdarkly.com/what-we-talk-about-when-we-talk-
about-api-reliability-2/
McGevna, V. (2012, May 2). Creating an Agile Schedule with
MS Project. Retrieved December 12, 2017, from
https://www.mpug.com/articles/creating-an-agile-schedule-with-
ms-project/
Mountain Goat Software. (n.d.). Scrum. Retrieved from
http://www.mountaingoatsoftware.com/agile/scrum
Perrigon, M. (2016, August 24). Benefits of the requirements
gathering process. Retrieved November 24, 2017, from
https://cybercorpsoftware.com/blog/what-are-the-benefits-of-a-
high-quality-requirements-gathering-process/
Pressman, S. R. (2015). Software Engineering: A Practitioner's
Approach, (8th ed.). New York: McGraw-Hill Education.
Project Scheduling Best Practices in an Agile Environment.
(n.d.). Retrieved December 12, 2017, from
http://innovategov.org/2016/02/05/project-scheduling-best-
practices-in-an-agile-environment/
Ritter, D. (2008, September 17). Risk Analysis Techniques.
Retrieved December 19, 2017, from
https://certifedpmp.wordpress.com/2008/09/17/risk-analysis-

techniques/
Sims, C., & Johnson, H. L. (n.d.). Scrum: A Breathtakingly
Brief and Agile Introduction. Retrieved November 22, 2017,
from http://www.agilelearninglabs.com/resources/scrum-
introduction/
Version One. (n.d.). The Benefits of Agile Software
Development. Retrieved from
https://www.versionone.com/agile-101/agile-software-
development-benefits/
Viswanathan, B (2015, November 19) Understanding the 4
Types of Risks Involved in Project Management. Retrieved
November 22, 2017, from https://project-
management.com/understanding-the-4-types-of-risks-involved-
in-project-management/
What is Agile? What is Scrum? (n.d.). Retrieved December 06,
2017, from https://www.cprime.com/resources/what-is-agile-
what-is-scrum/
Writer, S. (2010). Top 10 Software Development Risk.
Retrieved from https://www.itproportal.com/2010/06/14/top-
ten-software-development-risks/

· Stability in the Frequency Domain1. Consider a closed-loop sys.docx

More Related Content

Similar to · Stability in the Frequency Domain1. Consider a closed-loop sys.docx (17)

More from oswald1horne84988 (20)

Recently uploaded (20)

· Stability in the Frequency Domain1. Consider a closed-loop sys.docx