USA: +1(669)289-8683 
Sign in
This week, you will be expected to produce some type of prototype for the application. Prototypes help demonstrate progress to the stakeholders, and they also help you measure your team’s progress against the design and the project plan. Although a lot of coding work must be done on these projects that is not visible to anyone outside of the project, it is also important to be able to show something visual to less technical people because that is how they view the application.
For this assignment, the group will continue its work on the project and provide a progress report. Your group will also demonstrate your progress on the coding efforts with a prototype and code.
Assignment Details:
- Project Status Report: Prepare a summary document that includes the following:
Summary of work completed
This summary should identify specific tasks in the project plan.
Include identification of specific work completed by each individual on the team.
This summary should address technical coding progress to assist in the review of the code.Discuss issues encountered in the work and how your team has decided to address the issues. These could be technical coding and implementation issues or other issues that impeded progress.
Summarize progress against the schedule and how the team has decided to work through delays (if any) so that the project would remain on track for timely completion.
Challenge Topic: Prepare a planned-versus-actual view of the project time line, and discuss the primary problems that caused the variance. - Functional Prototype: Prepare a functional prototype of your application that meets the following requirements:
The prototype should demonstrate the overall design of the project from a user interface (UI) perspective. The major functionality of the application should be apparent in the prototype. Functionality is not required at this point, but the UI should have a sufficient level of design completed to support the functionality in the design document.
The prototype should demonstrate the overall design from a code perspective. Class definitions, including properties, constructors, accessors, and methods should be defined and either implemented or stubbed. Navigation through the application should be functional. Code should be well-commented and notes should identify areas that still need to be completed. - Zip the entire project and the Project Status Report together in a file named “SWE482_GP2.ZIP.”
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.
Typical course of events
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.
Typical course of events
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.
Typical course of events
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: 1×1, 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 Testing
Development
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
· NetBeans
Test 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: 1×1
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
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
· NetBeans
Test 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: 1×1
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
This is a sample test case.
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
LFTF = 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
5FF = 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
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
Sims, C., & Johnson, H. L. (n.d.). Scrum: A Breathtakingly Brief and Agile Introduction. Retrieved November 22, 2017, from
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/
