© Ria Mobile Solutions 2012
All Rights Reserved

RIAMS Customer Guide Book

Introduction

Welcome to the RIAMS customer guide book!

While reading process guides is one our team’s favorite tasks, we realize there are many activities you would rather be doing. We’ve tried to keep it short for that reason, covering project discovery, app building and billing and we can promise it will help us save time down the road. If you have any feedback, please send it to info@riamobilesolutions.com, we definitely value the input as it helps us improve our process.

At the beginning of any client engagement, we like to answer three questions:

  1. What are your goals and end results?
  2. How does achieving those results provide your business value?
  3. How does our role and services help achieve those results?

Whatever our role with your company might be, from providing advising to building apps, we want to ensure our work directly contributes to you achieving your goals. These three questions provide the foundation for delivering successful projects and building great relationships and is ultimately what this guide is used to discover.

Overview

1. Getting Started - Discovery

  1. Kickoff Meeting – Project Value
  2. User Stories – What the app does
  3. Wireframes
  4. Collaboration and Communication
  5. Infrastructure – Hosting and Costs
  6. Non Functional Requirements – What the app needs to run

2. Building the App - Development

  1. Defining Milestones
  2. Deliver Working Software in short cycles
  3. Progress Updates
  4. Managing Change
  5. Bugs
  6. Existing Systems Integration

4. Billing

  1. Billing Approaches
  2. Cost Management and Estimation
  3. Vendor Choice

Getting Started – Discovery

Discovery is all about understanding how our products, services, or advising align with your goals. This phase sets the tempo for the entire project and helps both teams focus on solving the right problem.

The Kickoff Meeting – Project Value

Before a project starts, we will schedule a meeting (in person if possible) to introduce our team, talk about our process and define the projects value.

Understanding your projects value lets our team make educated decisions as we move through app development. In short, we want to ensure that the code and features we are creating directly impact the value your project needs to deliver. Writing down the soft and hard benefits provides our teams with a shared understanding of what the project should accomplish.

For example, imagine you want to extend your invoicing system to mobile users. The project value might be defined as:

“By creating invoices at the point of sale, we reduce data entry mistakes by 50% and deliver feedback to our customers instantly, improving long term customer relations. Over 5 years, we believe point of sale invoicing could reduce the company costs by $50,000”

This statement helps accomplish a number of things.

  1. We better understand how our product and service costs benefit your company. (We understand that direct dollar cost / benefit cannot always be defined, however even soft benefits point us in the right direction).
  2. Future requirements, enhancements, bug fixes and feature development can all be put into context of the value they provide. In short, we ask our team if the current work they are doing helps accomplish the stated goal.

Defining User Stories

User stories (Functional requirements) describe what the product should do in the hands of your end users.

Non-functional stories describe what the product needs to work (ex: servers, software updates, version requirements), quality of service levels, etc and will be described later.

Appendix A describes how to write quality user stories and provides examples.

After our initial meeting, we will schedule time to flush out the product requirements and write the user stories.

Our team commits to actively maintaining the stories for the duration of a project. This helps ensure the stories represent the shared knowledge between our teams of how the product will function. These stories are used for acceptance testing and defining future enhancements and bugs.

Here are a few important points about story creation:

  1. This is a paid phase, on average lasting for two to five days, depending on project complexity. Larger projects may have a longer time period allotted for story writing.
  2. If your organization has already defined a clear set of user stories, we can move past this phase after verifying the stories provide sufficient detail to move on with development.
  3. In large projects (one or more estimated months), it may not be feasible to write every user story up front and we recognize that user stories will change. In this case, we break the project into large milestone stories, focusing on writing user stories for the current milestone story. We repeat the requirements gathering at the beginning of each milestone.

Wireframes

Wireframes are the app blueprints that help visualize how the application will function. We have found that wireframes greatly reduce any confusion around the user stories.

Creating a wireframe involves defining a layout and adding in features, elements for copy, navigation and functional notes on how the site or application will operate. These mockups are an artifact of story creation and will be stored along with the user stories.

Here are a few important points on wireframes:

  1. Wireframes may not be necessary on smaller applications. Instead we move directly to visual design.
  2. Visual Design is how the app will actually look. Wireframes are sketches to visualize different functional features defined in the stories.
  3. Visual design takes place at the beginning of the development phase, after user stories and wireframes have been approved.

A wireframe may look similar to this.

Collaboration and Communication

Infrastructure – Hosting and Costs

Where your application will be hosted after going live is an important decision to make during the planning phases. Depending on the complexity of the application, one hosting location may not be as well suited as another.

If your company already has internal, or cloud based hosting, we will work with that system if the technology allows for it. If not, we make the following recommendations based on technology used.

Technology Hosting Provider Cost
WordPress Marketing Site http://wpengine.com/ Monthly: $29 - $250 +
SaaS Application http://www.windowsazure.com/ Varies on Load – Min: $200
Linux Apps http://www.windowsazure.com/ Varies on Load – Min: $200

Pricing will increase significantly as expected and real loads increase on your application. It is important to note, that during a development phase you will generally be running two of the same hosting providers, one for testing and one for deploying live release code.

Non Functional Requirements

Along with infrastructure and hosting for your application, there are a number of other non-functional requirements we want to be aware of. Non-functional requirements are any items the application needs to run, outside of the how the application will be used.

In Appendix B, we include a helpful list of questions to better understand your non-functional requirements based on the type of app (mobile, web, etc).


Building the App – Development

Building the app is an exciting stage where user stories are transformed into a working product. Our team is a big believer in delivering app changes as quickly as possible to our clients. Delivery working code frequently helps our teams discover problems before the end of a project and manage change.

Defining Milestones

Project complexity drives the number of milestones in a project. A simple app, with a short estimated timeframe for delivery may have no milestones, other than complete the defined user stores, fix bugs and handoff code. When the complexity increases, we break down the milestones based on the most valuable feature sets. Again, we want to deliver the features that will provide your business the most value first.

Milestones serve a number of purposes to our team.

  1. They represent no more than a month of feature development. (We will deliver working software frequently during that month for testing). Our teams agree on the user stories to be completed for each milestone.
  2. Fixed bid estimates can be made for each milestone. This allows you to control costs and for us to make bids that accurately reflect what we can accomplish during that timeframe. (More about this in the billing section)
  3. Timeframe are generally 15 days of feature development and 5 days of testing and bug fixing.

Please note that our team makes a commitment to always work on your next milestone if you were satisfied with the previous work. You are always free to take what we’ve created and hand it off to a different development team at the end of a milestone. We frame our contractual obligation to a set of user stories for a given milestone.

Delivering Working Software in Short Cycles

User stories attempt to identify what features provide the most value to you and your customers. As we deliver working software for you to test, stories will change as our shared understanding and expectations of the end product evolve.

Our team has embraced that this change is inevitable and healthy for the product. The most critical issue is to capture that change early and make sure it is reflected in user stories and milestones.

We accomplish this by pushing working user stories to a development server (for web & web mobile apps) weekly (or more frequently if changes are small). For mobile Android applications, we deliver a weekly APK file to install and test with.

Your team can then provide feedback and bug tracking through the UserVoice account we setup.

Toward the end of the current milestone, we will schedule time with you to review what bugs and enhancements may have been entered into the UserVoice. Enhancements, or new stories, can then be incorporated into the project.

It is important to note that app cost can still be managed by removing undeveloped downstream features and incorporating the more valuable new stories. What stories we add or remove will be agreed on by both of our teams prior to making changes.

Progress Updates

Along with the working software, weekly we will provide you with the following updates through an email.

  1. User stories completed and in progress for the current milestone.
  2. Bugs and enhancements that need to be addressed in UserVoice.
  3. Any other outstanding issues.

Meetings, either by phone or in person will be scheduled as needed to address any outstanding items.


Billing

How much is this going to cost our company?

Managing cost is one of the primary concerns for our clients. Often times, large projects need approval from a board, upper management or other stakeholders in the company. We have found the some projects can be accurately estimated with a fixed bid cost and others cannot. Before we explain how we determine the billing method, it is important to understand the three different ways we can bill.

Billing Methods

  1. Fixed Bid- Our team takes a look at your requirements and provides a fixed cost for a project.
  2. Day Rate– Your team can hire our team to work at a fixed daily cost. This billing method is used for engagements where we provide training, analysis, or short duration development work for an existing team.
  3. Hybrid– A cross between a fixed bid and day rate. Typically we use this for complex projects with long time horizons. Our team looks at your current requirements (stories) and then provides a quote for how many of those stories we can finish during a specific time period.

For example, we might say for $5,000 we will complete story A, B and C over the next month. We continue this process until your end goal is reached, or you wish to end the work.

Determining the Billing Method

There are two factors we use to determine the billing method.

  1. Complexity – what is the high level estimate for number of features and implementation time?
  2. Product Vision – does your team already have a detailed spec or are you working off a higher level vision?

Let’s take a look at a few examples.

  1. Client Awants an Android tablet application to track tasks. They approach us with 10 detailed stories, describing how to input a new task, view tasks and send tasks to other tablet users. Part of the spec describes the Android version (4.1) they want to target, expected time lines and expectations. We estimate the timeframe to be around a month of work.
  2. Client Balso wants a task tracking application and has developed detailed a spec, however they have 50 feature stories across ten pages that need to be developed.
  3. Client Chas a vision for developing an online community that will eventually be used to drive sales through an ecommerce application. Releasing this application to the community will drive future changes, so requirements for the project are changing frequently to meet the new understanding of the market.

With Client A, the risk of changes is low and our company can provide a fixed bid we feel confident in. Client B also has detailed user stories, however the complexity of the project (time and features) is much higher. We know in this scenario that changes will occur in the project and we need to select a billing approach that reflects that change. In the Client C’s case, there is a long term vision for the product and it is highly complex. New requirements can be driven by each successive release of the software.

Depending on how solid those short term requirements are, we would choose between a Hybrid or Day Rate approach.

As a general rule of thumb, our team uses a hybrid approach for projects with estimated time horizons longer than a month.

So, how much is this going to cost our company?

We definitely understand your need to control costs. With the Hybrid approach, this can be more problematic than a fixed bid. When using the Hybrid method, we will provide an estimate on the price range for the project. This range is subject to change as the project evolves and is highly dependent on the project complexity.

Our team believes strongly in choosing the correct billing strategy based on the clients long term requirements and value proposition. Choosing a fixed bid approach, where complexity is high, results in bids where so much risk is baked into the price that the total cost often exceeds the value that you are going to derive from the project.

For some, this approach will not be a good fit for their project. We are happy to put you in contact with other development shops that may provide a better overall solution to your problem.


Appendix A – User Stories

The template for our user stories is based on articles from Joel Splosky at Fog Creek Software. The blog post on specs can be found here (http://www.joelonsoftware.com/articles/fog0000000036.html)

This story below covers the login in process for a user in a SaaS application. This particular story is heavily security related and makes notes of particular technical implications. The story from the perspective of a user named Mike who owns the SaaS application.

Admin Login

Actor Mike – Administrator
Modified 11/8/2012

Scenarios

Mike is the owner of a SAAS application and acts as an administrator for managing tenants. Mike needs a way to access the main dashboard of the application, by entering his email and password. Successful login will provide Mike’s application in the browser with an authenticator token that is used to ensure Mike is the currently logged in user.

Scenario 1: Mike navigates to http://owner.appname/admin and is presented with the login screen. He enters the correct username (email) and password and hits submit. The application authenticates Mike and presents the dashboard screen. The authenticator token is stored in a cookie. (TODO: or somewhere in client side memory)

Scenario 2: Mike enters the incorrect username (email) and password and hits submit. An error overlay is displayed, describing that the username or password is incorrect with a link to retrieve the password (TODO: need to investigate the security here). The error message does not indicate if the username or password was incorrect to prevent interrogatory adversaries from finding out valid usernames.

Technical Specs

  1. SSL will be enabled during login to protect against packet sniffing
  2. Hashed password will be stored with salt. Each user password has a different salt to reduce rainbow attacks
  3. Hashing reduces risk of password disclosure, not replay attacks, MITM, brute force
  4. Remembering authentication will only be done server side with a cookie to reference the session
  5. Cookies should have secure and HTTP only flags set when sent to browser (HTTP flags to reduce xss risk, secure flag to ensure cookie is only sent by HTTPS). JavaScript is not able to access httpOnly flagged cookies.
  6. Authenticator tokens will be limited to 30 minutes

Non Goals

  1. Disabling autocomplete for browsers

Open Issues

  1. Authentication tokens need to protect against SSL attacks

Appendix B - Non-Functional Requirements

General

  1. What is your applications name?
  2. Who is your target audience for this app?
  3. Are there similar / competing apps in this space?
  4. Do you have any favorite applications where the design or user experience appeals to you or your company?
    We like to view apps you or your company enjoy using to get a sense for what type of design and user experiences may fit well in your new app.
  5. Do you have any estimates on expected usage for the first day of release?
    For example, you have an existing customer base that you’ve been marketing to for release of your Android app and expect 1,000 installs the first day. This helps provide realistic testing scenarios.
  6. What type of usage growth do you estimate for you app?
  7. Do you have any existing API that we will need to integrate? Is it complete and documented?
  8. Do you have an existing data that needs to be included in the application? What formats?
  9. Do you have an existing database that needs to be included? What type and version?
  10. Do have an internal development team we need to hand off code or provide training for?

Android Mobile & Tablet App

  1. What devices and OS versions are needed for acceptance testing?
    For example, Samsung Galaxy SIII and XOOM tablet with Android 3.0 to 4.1. Checkout the Android dashboard for more guidance on most used current distributions. http://developer.android.com/about/dashboards/index.html
  2. Do you want to support landscape and portrait modes?
  3. How will you backup and protect the Android release key?
    Android requires a release key to push apps to the Play Store. After your first release, this key must be backed up and protected, or you will not be able to update your application.
  4. Does the application require to be always connected online, or will it include offline usage with data sync?
    Android applications often require syncing data from a central server to the device. This can take two forms. The simplest is that the application can make straight service calls to an API to get its data, however this user experience is not the best. The app must always be online and is less responsive. The second option, the app syncs its data from the server when the app has online access and uses what data it has when offline. Offline access is a better user experience, however it is more complex in how we manage data concurrency with your server.
  5. What native features of Android might we be interacting with? For example, NFC, push notifications, etc.
  6. What category in the Play Store would your app fall under?
    Under Applications in the app store there are a number of categories, including Business, Education, Finance, Social, Tools, Sports, etc. Checkout the listing of app categories here: https://play.google.com/store/apps/category/APPLICATION?hl=en

Web App

  1. What browsers do you want to support for your app?
    This can be very dependent on the vertical industry you are in. For example, we’ve worked with large hospitals in the past that required supporting older versions of IE. The general set of browsers we support as of 11/2012 is IE8, Chrome 12+ and FireFox 16+.

References

Wireframes - http://www.onextrapixel.com/2009/07/15/the-importance-of-wireframes-in-web-design-and-9-tools-to-create-wireframes/

Function Specs - http://www.joelonsoftware.com/articles/fog0000000036.html