Project: PowerPad2
Date: December 22, 2014
Contents
Project Outline
Development Methodology
Requirements
Design
Development and Testing
Project Schedule
Risk Analysis
References
Project Outline
The project outline is call a PowerPad2 computing deviceweb-base that scans proof of delivery (POD), packages being picked up, retrieving a signature from a customer, using a stylus. This device will be an upgrade from the old PowerPad2. This PowerPad2 software will be enhance to add additional software, like e-notes: this will allow the driver to capture holiday close information if the company is taking additional days off. Included from the enhancement is a delivery and pick up manifest visible on the powerpad2 for the driver. The powerpad2 will also keep records of any signature retrieve and sent to the main database at the main location. More enhancements is allowing the driver to release without a signature for the customer, and identify if theirs is no release. Each day from the night before, a genesis pickup database will record all pickups and transfer the information into the powerpad2 the next morning in a form of a manifest, stop per stop.
We will also speed up the scanning process on each barcode, from 10 seconds to 2 seconds once it reads each barcode. This powerpad2 will cost more to develop since it is an upgrade and weighs less than the powerpad1. As before this design will improve productivity in the field, at the location, reduce hours from each driver’s route; improve the sorting inside the building station. Also the information sent to dispatch will be faster and able to locate any driver’s location in the field.
Before the PowerPad1 and II, the company was using a super tracker, a small infra-red scanner, only for scanning barcodes, losing data and not capturing the signature correctly. This software is more sufficient and better efficient for the drivers and the company that will use it.
Some issues that may occur during this project
If the main database server fails to receive the information, all the customer signatures will not be uploaded and the service agents have to re-load and up-load the information the next day.
The device will be costly
The database has to work to perfection to receive tons of information from these devices.
If the database is hacked it would cause a lot of problems hence it has to be secure.
The customer signature may not be captured correctly.
Development Methodology
In this project we will be using the agile methodology for the development of this device. This development is incremental and iterative and we can improve our software product, if any of the requirements change or enhance during the process. This method has meetings that depict the performance of the team members after regular intervals. This method reduces cost and time consumption such that the regular increments allow us to analyze if we are working in the right orientation and we don’t have to start all over again.
Developers have a framework or processes to follow, the agile methodology can help the organization reduce risk. The benefits of the agile scrum method are feedback from stakeholders, quicker releases due to the fast development cycles. This agile methodology can give the organization a competitive advantage. Once we patent the software sooner we will hold the rights to the patented software. The agile methodology can improve the product quality. Conducting both formal and informal interviews with stakeholders for this project is very important. Highly skilled senior level technicians has to work together or collaborate on a single code, also errors checking are performed quicker and more accurate.
Below is a diagram of the agile development process:
Requirements
The team will use two approaches to gather the requirements for the PowerPad2 software project. The interview and survey approaches will be used for this project, the requirements gathering for the agile development method can occur at different stages. It can occur before the creation of the product back log document. One of the senior staff members like a scrum master can conduct both formal and informal interviews with all the stakeholders to gather higher level requirements called user stories. The user stories are then documented in the product back log document. The requirements gathering can also occur during other phases like during the sprint retrospective and iteration phases.
Continual feedback during all of the phases from all stakeholders will be required for this project. The three most important things to address when gathering requirements for a software development project are eliciting, collecting and developing requirements. Eliciting is determining the source of requirements. A requirement elicitation is a task that helps a customer to define what is required (“Requirements Elicitation Methods”, n.d).
The team travelled to the user location and asked only opened ended questions, this was chosen because we will be able to get more of positive answers than negative.
The requirements process for this project we will gather requirements, document the requirements, check for any errors or competence, refine or remove any bad requirements. We will also validate the requirements, and manage the requirements for the PowerPad2. Some of the high level requirements gathered that the application must allow the user to change from alpha to numeric, connect to a wireless network, allow the user to collect a proof of delivery signature, any graphics must be displayed to the user, send updates to the main database once a signature has been received. A technical team will be ready for any issues 24 hours a day, along with a 1800-666-5151 number. The final high level requirement will be the timing of the barcode scanning, from 25 seconds to 10 seconds a scan. The elicitation process used for this project is the interview and survey process. We will use brainstorming as another technique to define the requirements. All of the developers involved in this project will contributed their ideas, and select the best ideas for the PowerPad2.
Requirements Analysis
Interviews: we will visit and contact delivery stations and company warehouses for wireless availability for the product.
Questionnaires: all of the questions can be asked using a questionnaire online or in a printed form, or these questions can be asked in a live meeting. Another way could be made consisting of all the interview questions.
Brainstorming
We will conduct meetings of all the department heads of this project and we will also involve some stake holders who would give us random ideas on any aspect that is relevant to the execution of this project. This activity would be a refreshing exercise for all the minds involved in this project and also this will provide us with many ideas and we can choose the best ones at the end and also link these aspects. In the end of the meeting we will have a mission statement and know the orientation of our work and how it will progress ahead.
Observations
It will be the analyst’s job to see how things are progressing and what can be the future of the product. We would need to keep a track of all the activities and observe. We will identify the weak factors of the organization and team members. The factors identified to be incompetent would be analyzed and correction will be made by the team members or any department.
Some of the functional and non-functional requirements of the PowerPad2 project requirements we will first point out some key functional requirements and non-functional key requirements:
Functional Requirements
All users associated will need a employee ID number to login
Capture a signature from the powerpad2
Customer sign for the package and the driver obtain the signature
The driver compare the address on package with the manifest
Received the data
Send data to the main database
Scan the package information
Dispatch receive information
Non-Functional Requirements
The device should be efficient
The device should have a display with a light
The device weight is light to handle
A keyboard on the device
The screen is larger to read the information
A touch input
Font size are readable
This device should be affordabl
Elicitation Requirements
The elicitation requirement method process is to gather the requirements: mind mapping, interviews, stakeholders and more. Below are some processes of the elicitation process:
Customers and sponsors that pays for the final system
Have a focus group for the methodology
Outputs from the elicitation process, that is organized by the use cases, prototypes and domain constraints
Make sure each rationale for each requirements that’s recorded
Use case scenarios and mind mapping these are good visual for the customer
Most of the requirements are non-functional like: usability, performances, operational, security, and maintainability and support requirements. The functional requirements will be the scope of the work and the functional requirements for the PowerPad2 (Programmer’s Life, 2009).
Some of the possible measurements and criteria for the PowerPad2 just to name a few:
Ratio of any successes to failures
The time spent on errors
Have to have time to complete the task
The percentage of the task completed
Task completed per unit
Keep up with the percentage of errors
How many commands used
The time spent using help
Amount of runs of successes and of failures
Number of good and bad failures that’s recalled by the user
How many times the users need a work around from a problem
How many times the users is frustrated or satisfied (Tyldesley, 1988)
Design
The handheld computer device has a communication area for network connections, WLAN radio, an antenna and operating channels this will help receiving and sending data to the main base system. The mobile architecture application includes three major components:
Existing system
Middleware application
Handheld application
Send information
Received delivery and pick up information
Dispatch information and send to the main database
The middleware application is needed to provide the data transformation and the central point of communication for the system.
PowerPad2 class diagram
Image of a handheld computer device Retrieved from
References
Software Development Plan for PowerPad in Nexus Retrieved from
Agile Methodology Retrieved from
Agile Images Retrieved from
Mullaney, J. 2014, A template for software requirements gathering techniques Retrieved from
User & System Requirements for Successful Software Development, 2014 Retrieved from
Programmers Life, 2009 Retrieved from
Mullaney, J. 2006-2008 A template for software requirements gathering techniques Retrieved from
Tyldesley, 1988,Kotonya and Somerville, 1998 Thinking about requirements and describing them Retrieved from
Handheld Computers, 2014 Retrieved from
Mobile Application Architecture Retrieved from
Booker, G, Network Design Intro Retrieved from
Kaleel, S., B. and Harishankar, S. 2013, Applying Agile Methodology in Mobile Software Engineering: Android Application Development and it’s Challenges Retrieved from
Agile Methodology 2013 Retrieved from
Hower, R. 1996-2014 SoftwareQATest.com Retrieved from
(July 10, 2014), Agile Methodology Retrieved from
Agile Methodology.(n.d). Retrieved from Retrieved on 11/28/14
The Agile development life cycle.(n.d). Retrieved from
on 11/28/14
Requirements elicitation Methods.(n.d). Retrieved from 11/26/14
Enhancing security of Windows CE device.(n.d).
Retrieved from Retrieved on 12/1/14
Software development process.(n.d).Retrieved from on 12/8/14
Software development process. (n.d).Retrieved from on 12/8/14
Usmani, F.(2012) Developing a Risk management Plan Retrieved from 10/22/14
Mathis, M.(n.d). Work Breakdown Structure: Purpose, Process and Pitfalls. Retrievedfrom on 10/22/14