Blog

I’m ready for a more fun blog post. I want to write about Augmented Reality (AR). I’ve written about AR in the past. And I continue to be fascinated by it. We’re looking to develop our first AR project with an AR partner.The key is what are the killer ideas for AR? Here are some AR images (thanks to Microsoft). It’s mind boggling. And I think it lives up to its hype.

What about some ideas for AR? There are so many different areas. The above Wikipedia link gives you the breadth of industries that could benefit from AR.

Some of the ideas would require glasses like the Hololens or Magic Leap. Others would only require a cell phone. Ideas that require a glasses would need to be more focused because it will take a long time before everyone is walking around with these big glasses on their face.

Here are some of my ideas:

• Utilities: I know utilities are concerned about training the next generation engineer. A lot of the equipment and controls that utilities use are super outdated. Why not use AR to make the training and daily work more interactive and visual? Even trained engineers will need to understand and learn how to adapt to a utilities plant environment.
• Fast Food: Turnover is high. Training is a constant and costly. Could Culver’s (link) use AR to train new employees? For example, when a new person starts work, they first get a walk through by employees. This is how you make fries, make burgers, make a shake, work the cash register (this might be automated soon), etc.

Then the new employee slips on the augmented reality glasses. When they go to make fries, everything is visually laid out for them. This is where the fries go, these are the setting options, and this is the timer. It could also include safety warnings.

• • Retail: Similar to fast good, retail has high turnover. AR could help new employees identify where things are located, and how to work the cash register.
  • Manufacturing Line: AR could help manufacturers train new employees on a manufacturing line. It would label different components and processes with instructions. You could also have throughput and other stats to indicate how a line is doing in real-time. That immediate feedback is valuable.
  • Lab: This one is interesting to me. There are many medical/research labs. Many of the processes in these labs are long and can be complex. Why not use AR to label the steps and processes to help with training?
  • Sports: This idea would strap wearables to the athletes on the court, field, rink. This data (yes, using the singular version) would be sent in real-time to a gateway that would connect with a server. Then this data would be fed through the AR engine and be displayed. To make this happen athletes would also be need to wearing a sensor to identify their location in real-time on the field.

This would be a fun idea. And I’m thinking it could have applications beyond sports, perhaps in the medical field, warehouses, etc.

That’s all for now. AR the way we imagine it is almost here.

This is another post in our series around the software development life cycle. Our previous post was on quality assurance (QA). Check out our other posts in the series: The Ideation Phase, Gathering Basic Requirements for a Proposal, The Proposal, Gathering Requirements, and Creating a Backlog and Planning Sprints.

This post is the next level of testing after QA: User Testing. After we do QA, we move that code from our dev server to our UAT (User Acceptance Testing) server. This is a very common path in software development.

With UAT, the user or client tests and tries to break the software product, website or mobile app. This means going through every routine action possible, including registering a new user, logging in, editing a profile, adding a comment, making sure the different admin levels work appropriately, etc.

A lot of bugs and issues should have been caught in the QA stage. But bugs are almost always caught in the UAT stage as well. It’s an important process to have the user/client make sure everything is working properly from their perspective.

UAT stage is also a time to fix anything before the code is moved to the live production server. This is the server that hosts the live site.

If the client decides they want to change the workflow or overall user experience in the UAT stage, it’s doable, , just more expensive. This is because a major change at this stage means rewriting a lot of the code and redesigning the architecture and database. If possible, it’s best to avoid this. This is why the early design and requirements stage is so important.

But it’s not the end of the world if major changes are wanted. We use agile, so it’s much easier to adapt and change than it is with a waterfall type approach.

This is a fun ideas post around software, workflow and efficiency. The other day I was thinking more about dashboards and portals. What happened to the portals? They are popular in Asia. And now chat apps in Asia are almost the new portal. This makes a ton of sense. You don’t have to visit 10 different apps to message a friend, order a pizza, call uber, make a haircut appointment, etc. It’s all done through one app, simple and neat.

I was thinking about why there aren’t more dashboards or portals in the US. Is your phone one big portal? It has a ton of apps that allow you to access what you need. It kind of is. But none of the apps are connected, which is silly. When I make a haircut appointment why isn’t that automatically booked in my calendar?

A dashboard or portal could also be useful at home. My normal workflow at home is not to be on the phone all the time. Is that strange? For my home dashboard, I would envision a 40 inch touch screen in the kitchen that is shared by all of the family members. It would of course sync with our apps on our phones too.

That would suggest the operating system should be Android or iOS. The large home dashboard would be similar to your phone. And maybe the main difference is the visual component of the workflow, how you interact with it. Seems simple but different visuals and workflow can have a dramatic effect on people’s lives and how they interact with software and mobile apps.

What would be on this dashboard?

You can probably imagine what would be there, nothing earth shattering. I would want a family calendar that’s tied into all of our calendars, email, weather, social accounts, location of our cars, messaging apps, what else? It should be the go to place so a family can coordinate schedules and has a clue of what’s going-on with everyone in the family.

Is this really needed?

I’m not sure to be honest. I think it would be helpful, but not sure of the demand. And will technology like the Hololens replace the need for a home dashboard? I can’t imagine walking around all day with wearing it though. Over time those imagines will become smaller. I wear glasses all day so if the Hololens shrunk to normal eye glasses size, we would walk around like the bionic man and that will be awesome.

Back to the topic, it would also be helpful to connect into a voice recognition system like the Amazon Echo. Often I’d like to add an event to a calendar, like the family calendar, but I’m not near my phone or a computer. Or I am near one but too lazy to enter it. I just want to say “Hey, enter this calendar invite”.

This is why the workflow and understanding how people would actually use this dashboard is so important. The technology implementation would not be complex. The workflow would be crucial. The design would also be important.

This blog post is part of our series on Augment’s software development process. This post is on the super exciting topic of testing and quality assurance. Check out our other posts: The Ideation Phase, Gathering Basic Requirements for a Proposal, The Proposal, Gathering Requirements, and Creating a Backlog and Planning Sprints. People new to the software world do not appreciate the importance of testing. It is a huge part of any project. There are always bugs to be found and work flows to improve. We try to avoid as many as possible but bugs are inevitable.

So how do we test software? There are two main ways to test software: manual and automated. Manual testing is appropriate for new product development. At some point when a company has a more stable version of their software product (website, mobile app, product), then it could make sense to write an automated test. We generally use Selenium or Geb. They both have a nice browser automation framework.

Let’s first talk about manual testing. We do manual testing for new product development. What is manual testing? It is when a person sets up and executes a test plan to test for bugs. For example, if I enter DER@.com into an email form, the form should not be submitted and an error message should appear.

How do we do put together a manual testing plan? Generally our QA analysts (testers) take the requirements document (which we discussed in more detail in a previous post), or even something as simple as wire frames, and write test cases.

We usually use Excel to write down and track all the manual test cases. In a typical 2 week sprint there could 60-100 test cases written, tested and tracked.

What happens when a bug is found? The bug is logged into our project management software, often VSO or Jira. This bug is then tracked and added to the following sprint to be fixed. Once fixed it is retested. Once the bug has been fixed, it is marked completed in VSO or Jira.

For automated testing, it is a different process. We still have to write up a detailed test plan. But instead of having a human run through each step manually (does the email form accept the proper format) a script (code) is written to have a software robot run through the entire script.

It is actually cool to watch because the script takes over the browser and starts going through the different steps, typing in text, navigating to different pages. It is like someone took over your browser and that is because someone did, the robot software script.

To write these scripts we rely on browser automation frameworks like Selenium and Geb. These frameworks have tools that make it easier to command the software robot to do certain actions (like click on this product link) in the browser. And this can be done across many different browsers (Chrome, Safari, IE [Edge], Firefox).

At what point does it make sense to move from manual to automated testing? Generally if you are going to do the test over and over again, it makes sense to automate. You could add the number of hours spent doing the manual test each year and compare that to the cost of developing an automated test. Over the years, if you are testing weekly, then it probably makes sense to automate the test. Even monthly testing could be enough to justify automating the testing.

After we test the software developed in a sprint then we move that code over to the user testing server. There the user/client would go through their own testing and provide feedback on any issues or bugs they found. These bugs are incorporated and fixed in the following sprint.

Microsoft will soon release the software development kit for the Hololens. Is this for real? It seems almost too good to be true. I cannot wait to get my hands on the development kit to determine its capabilities.I’ve seen the demos and videos. If it works as prescribed, this could change a lot of things, media consumption, training and education, communication, design.

In this post I’m going to come up with an idea of how to use the Hololens and dissect it. There are thousands of good ideas. The consumer facing ideas seem more obvious to me. The whole family could just watch Netflix on their Hololens. Will everyone just walk around with these huge glasses on their face? And what is going on with Magic Leap?

Back to my idea for the Hololens. I would like to focus on the construction industry. I’m not sure if this would be a good fit or not. But here are some thoughts on whether this would work or not. The idea is for construction workers to wear a Hololens in order to see real-time designs and stats. Is there an ROI?

• How well can you see with the Hololens? Would it limit construction workers field of vision?
• Could the Hololens overlay 3d renderings of the building on the actual construction site? This would be amazing. I feel to make this happen beacons would have to be set up to provide context and boundaries. That way the Hololens can orient itself and properly lay down the 3d rendering.
• This could also be used by architects of course to show clients their vision. Maybe that’s an even better idea.
• Bring up blueprints on the Hololens.
• Real-time stats on equipment and tools in front of you. Is that helpful?
• Advice, let others see what you’re doing and ask for real-time advice. Could they draw on your screen to give you tips for how the particular construction product will fit?
• Have a manual in front of you for new equipment/tools.
• Provide a tape measure. How would this work? Could you point with your fingers what you wanted to measure? I’m not sure if the Hololens will have the depth perception of Google Tango or the Kinect.
• Real-time video feed from a drone.
• Real-time vital sign stats of yourself and your crew.

Those are my initial ideas. Nothing ground breaking there. Maybe most of the use cases will be in entertainment and media. The porn industry will have a field day with this.

I also think hospital workers could benefit from this. Although the lack of eye contact could be an issue. What about software developers? How could the Hololens work for them? Will it display existing screens or can you create new screens from scratch? Could developers have five screens up? Could another developer just jump on your Hololens and see what you’re doing, like skype on steroids?

I have a lot of questions about the Hololens. How many hours of development will it take to develop a useful application? What’s useful? Something similar to the quality that Microsoft shows on their Hololens website. What will be the price of the Hololens over the long term? The initial SDK is $3,000, not cheap. But I imagine the retail price will hopefully be under $1,000.

It’s exciting times for augmented reality. I want my world to be augmented, sometimes.

This is the fifth in a series of posts on our software development process. Check out our previous posts: The Ideation Phase, Gathering Basic Requirements for a Proposal, The Proposal, and Gathering Requirements. This post is on the very beginning of the development work when we start working on the project.We call it building project backlog and sprints. This phase involves building the requirements and database architecture and estimating the next few sprints.

In the previous post in the series, Gathering Requirements, we talked about gathering the detailed requirements for the project. With those requirements we start to schedule the upcoming sprints. Often the sprints are defined using screens. Using our music platform example, we could have these screens:

• Home page
• Musician Profile page
• User Profile page
• Musician Admin page
• About Us page
• Concert Details page

There could be many pages. These pages are defined when we gather requirements.

We start by selecting the first page we want to start working on. In our example, let’s start with the Musician Profile page. This page will also have a sister screen, the Musician Admin page.

In the requirements document we detail out exactly what features and functionality the Musician Profile page will have. This includes the general layout and where each detail will appear on the screen. Depending on the project, the requirements document could be very detailed even specifying the date format for their concerts.

The software requirements will also include the database architecture for this screen and the overall database architecture. Some projects require detailing most of the database before building the screens and functionality. This is because you want to understand how every feature/function will be connected.

Once the screen design is roughed out and the requirements written, we send this to our awesome developers in India. They hammer out the backend and frontend coding.

While the developers in India are coding, we continue to build a backlog of sprints. We do this by deciding which screens we want to develop next. Then we layout the requirements for that screen. Sometimes the requirements are not as detailed. It depends on the project. Often we find that more detailed requirements cost more and take more time upfront, but save money and time with the actual coding. And all parties are more likely to be on the same page with detailed requirements.

These requirements include the database architecture, wire frames, functionality (e.g., allow user to share a song) and design guidance. We talked about this more in the Gathering Requirements post.

The past, current and future sprints are tracked in a project management tool. We often use Jira and Visual Studio Online (VSO).

Here is an example of VSO.

You can see I did a beautiful job crossing off our client’s name.

Notice on the left hand side the past Sprints 1-9. These are completed sprints. We’re currently in sprint 10. The length of these sprints varies but they are usually 2 weeks, some as long as 4 weeks. At the end of each sprint there is a deliverable to show the client.

Within each sprint are tasks. These are often related to certain pages within the software application. You can see a number of tasks for Sprint 10 in the middle of the page VSO example page.

During each sprint our project manager works with the developers and QA to assign tasks. Tasks are assigned through VSO in this project. Once a task is completed, it’s tested, and then moved to “completed” status. After that the updated pages are moved to the UAT server for further testing by our client. If there are bugs found, they are added to the next Sprint, fixed, tested and sent back to the UAT server for client testing.

This is the process throughout the entire project. It’s critical to have a robust system in place. But all projects start with the end in mind. Define the vision. Take that vision and write detailed requirements. Then take those requirements, define the sprints and execute the development. Then test and test to make sure the bugs are removed.

Thanks for making it this far. We’d love to hear about your processes.

Can we teach a software robot to build a simple data driven website using machine learning? That would be cool. This is an exploratory post. Most of our daily work is blocking and tackling, managing projects, writing code, writing user requirements, understanding a client’s strategy.

It is fun to take a break and talk about the future.

How could we program a software robot to build a site? And what does that even mean? Sometimes machine learning seems more like intelligent design than actual learning. Unless you are talking about identifying cats. That example is pretty clear.

In this post let’s start with the end in mind. What goals do we have with a software robot that can create websites on the fly?

First let’s start with the type of product we want the software robot to create. And then we’ll look at what parts have to be learned and automated.

End Deliverable: For this post, the client wants to build a site where users can sign up, fill out a form and submit it. On the admin side, the admin wants to have different security roles and be able to manage the users and forms submitted. This type of data driven web app is needed all the time. Register a user, submit data, and manage the data.

So we could build this from scratch. We would work with the client to write out the requirements. Then we would design the database. Then we would send the requirements to our developer to code.

So what parts should the software robot develop? And what does it mean to learn? Can we throw in nuances that the software robot will have to accommodate?

Could the software robot architect and develop the entire site? When I think through scenarios often it seems like I am thinking about creating a template. Where does the learning happen?

Our machine learning program could have a user interface. This is where the analyst would fill out information about the app including the database requirements, navigation and design. The software robot needs some direction. It can read the analyst’s mind, yet.

Let’s start with the database in this post. In later posts we will address the controller and view.

The requirements written by the business analyst could require the application to have the following entities involved: user; form; admin.

The user would have the following fields: userid, name; email address.

The form would have the following fields: Question #1; Question #2; comments, userid.

The admin would have the following fields: Name; email address.

So where is the learning? As the analyst is filling out the user interface screen, it would list that the user would have these fields. The analyst could fill out a form with this information. That would become a table. The software robot could auto suggest ideas, like should this user have a userid field? Or would the email be enough?

On the user interface it would list the table, which would change as the fields change. Then the analyst would work on the next table, the form. Once again the analyst would fill out the fields, or questions in this case. It would automatically add a unique identifier. Then it would auto suggest if it should connect to the customer table.

The same could be done with the admin link. Because it is the admin table, the software robot would auto suggest if there should be different security roles: super admin; admin; employee? It could support an infinite number of admin roles.

So now there are three tables on the user interface. In an MVC architecture this would be the model part where the classes define the database. The software robot would then take these tables and design them in the application automatically.

Would this be something unique? What is the main value the software robot is providing? It seems the learning would be making auto suggestions for how to design the database. In theory we could feed the software robot thousands of examples of how databases are connected. But how would we actually teach it to know how to design the database? Is that impossible?

Next, if we decide to take this further, we can talk about the view and controller part of the application and how that process can also be automated.

At Augment, our main wheelhouse is software development, but another service we provide is helping people or companies get their technology into a real-life usable form. We love driving the process of getting from research to application. This post is on how we would approach taking an innovative health data analysis technology and turning it into a product. We’ll talk about several different aspects of the process, what questions we would ask and how we would help.For an example we’ll use an interesting technology in the healthcare space from the University of Michigan.

They have a predictive analytics method to better forecast who with Hepatitis C will develop chronic liver disease. That sounds useful to me.

So let’s pretend the researcher came to us interested in commercializing this technology, turning it into a marketable product. There are a lot of steps involved for taking a technology to the market. Although it’s a major part of commercialization, in this post we will not address the marketing and sales component.

Background on Technology:
What data inputs are needed for this chronic liver disease model? How do you get access to these inputs? It’s possible that some of the needed inputs may be confidential. That is fine. We do not need to know the exact details. But I am guessing the weightings are more confidential than the actual inputs like age, sex, income, history of alcohol, blood tests, glucose levels. I am just guessing these could be some of the inputs.

What algorithms are used to predict incidence of Hepatitis C? Is it a combination of several or a custom made one? We do not need to know the details for IP reasons, but it is helpful to understand how this works.

How long does it take to gather the input data and run the analysis? Are there issues with standardizing the data?

Do you have published papers on this technology?

Do you have IP protection, international and domestic?

What do clinicians use now to understand the potential for chronic liver disease?

What’s the value created by this? Is it obvious, measurable? How much would customers pay for something like this?

Previous Clinical Trials:
Have you done clinical studies? Who was the PI? How much did it cost per person to run the trial? Where did the funding come from? This helps give us a sense of the cost of future studies. It can also help us understand how connect the PI is who did the study.

What was the size of the trial?

What were the false negatives/positives for the studies?

What was the make-up of the participants? Sex, age, ethnicity? Does the algorithm work across all of these levels? Does it work better in one group over the other?

Regulatory:
What’s the regulatory pathway for a product like this? This is a difficult question to answer early-on. If they know the answer, then they have thought through the entire process. Understanding the regulatory pathway can take a lot of time and money.

Do you have an FDA strategist?

Have you talked to the FDA? What did they say?

Software product design:
What features are crucial for phase 1, 2 and 3?

Who will use the product? Will it be used by clinicians, nurses, analytic professionals? This answer will help to determine the design and complexity of the product. If it will only be used by analytic professions who are familiar with analytic packages and programming, then the product can include more ways to customize and be a little more crude overall. If it will be used by doctors, then it has to be very user friendly and clear. And provide less options for customizations.

What do you want the product to tell the user? What is the end point? Does it give a range of probabilities? Or just say Yes or No?

What administration controls will be necessary? What can the administrator, often the user, change? Can they tweak the algorithm? They should be able to update the patient profile.

Go to market strategy:
Who could be potential distribution partners? These partners could also help fund the development.

Team/Partners:
How would you find a potential partner and how will this technology help them? Could they make or save money? Or could it help them sell an existing product they sell? Maybe a Pharma company that sells a Hepatitis C drug could use this as a tool to show that their drug is needed. A partner could also be a firm that wants to get into this area. That would be harder to find because you have to know someone is wanting to dive into the Hepatitis C area. Unless you have inside knowledge you would have to get lucky finding someone. Would the Hepatitis C association know of anyone who could be interested? Or would they be interested? Typically associations do not invest in for profit companies but some do.

In the future we will take a deeper dive into each of these areas. There are many follow-on questions for each of those listed here. If a client needs help with this process we would love to be a part of it. And of course we would always be available for the software component as well.

This is the fourth in a series of posts on our project process. Check out our previous posts: The Ideation Phase, Gathering Basic Requirements for a Proposal, and The Proposal. We will continue with the music platform example used in this series. Although in this post we pull in examples from other applications. Maybe we should have actually built the music platform for this blog post. That is a good idea for another series.Once the proposal is accepted by the client, it is time to gather detailed requirements. This is one of the most important stages of the development process. If you do not have quality requirements, it is very difficult to get a quality software product. Of course requirements change throughout the project (that’s why the world has shifted to AGILE) but overall the requirements need to be specific and clear.

With detailed requirements, the likelihood of success is much greater. We hear about software disasters. One of the main reasons is poorly written requirements. It is not exactly exciting and thrilling work, but it is essential.

With these requirements we then write stories. These stories are used by our developers in India to starting writing code for the different pages/functionality.

Being able to write detailed requirements is an art and a science. The requirements can be written by an analyst, who is often the database designer as well. The analyst and database designer roles are often be split too.

There are several key items to focus on when creating the requirements. We’ll go into several of them here in more detail.

User Profile Page

This is the section where you can go into the details of how the page will look and operate, including the design, layout and functionality. How will you edit it? What links will be included?

There are hundreds of potential decisions to make about this page. Making decisions about the look and feel of the page is UI/UX. There are consultants who focus just on helping you design the best possible page and provide a great user experience.

Here’s an example of Kaskade’s profile page on Soundcloud.com.

Here are some questions you could ask about this page:

• For design, should the main profile picture be taller or shorter? Should the “All” link be underlined or just a different color like orange.
• For layout, where should the stats go? Right now they’re over on the right hand side near the top. Should they instead go farther down the page?
• For functionality, should you be able to play the tracks from this page, or when you click on the Play button it would open up a new window? Should you be able to comment inside the Track? What social networks should the user be able to share with? How do we make it easy for someone to share a track (design/layout question)?

There are countless questions to ask.
Often the best way to tackle these questions is to find 3-5 web examples that you want to copy. Copying is fine. Works of art and design are derivatives from prior art and design. You just want to make sure you add your own flair and ideas so it is not an exact copy.

After you get some ideas of the design/layout/functionality, then we write some initial requirements that include wire frames.

Wire Frames:

Blow is an image of some basic wire frames. Wireframes help to understand where content will end up on each page. It does not have to be beautiful, just practical at this point. From this you can understand where dynamic content will end up and where links to other pages will go.

After the wire frames, ideally you would design some basic screen shots. These can be done quite quickly by a designer. Here’s an example:

This is the public facing user profile page. The requirements could also make mention that two levels of administration pages will also be needed. Administration pages for the user to make edits and for the company admin will be necessary. Each of those pages will have their own requirements documents.

Navigation:

Detailed requirements also include a detailed navigation diagram. This chart shows the links to other pages on whatever page you are documenting. It also shows what potential actions occur regarding each link.

Here is an example.

This is a basic example for a logon page. It walks the user and developer through the steps of how the pages are connected.

Database Design:

The requirements document for each page will also have the database design. Following is an example for the above logon page. It is a simple example.

The database is designed based on how the page is designed. If you need certain information about a musician, then that information has to be stored in the database. It all works together.

User Stories:

The last main part of the requirements is writing the user stories. This can be a ton of detail or not as much. We have found that the more time you spend upfront writing and designing the project the more time and money you save in the long run. And with the AGILE methodology you can always make changes in the middle of the project. That is not an issue, but it does cost a little time and money.

Here is an example of the written part of the logon story. The entire document was four pages. This is just one section.

1. Special Considerations
   1. If Cap lock is on, the page should show a message “Cap lock is on”.
   2. The password fields should have a mask “********”
   3. Passwords expire every 90 days. If a password is > 90 days old then the Change Password page is called. (today – User.LastpasswordChangeDate => 90 days)
   4. Username is locked after 5 failed logon attempts (User.UnsuccessFullogonAttempts = 5).
      1. If User.UnsuccessfulLLogonAttempts = 5, the application should display a message “Your account is locked due to too many unsuccessful logon attempts, Please contact the system admin to unlock the account”.
   5. If the user logon is successful the application must set User.UnsuccessfulLLogonAttempts to 0 (zero).
      1. If the user logon attempt failed due to an entered password that doesn’t match the User.Password value, the application should increment the User.UnsuccessfulLLogonAttempts by one to an upper limit of 5.

Writing detailed requirements like this can be tedious. But it also ensures a solid software product at the end of the project.

Thanks to Bill Montei of K2M for his great contributions to this post. This post is about a project we are developing with K2M Insurance Management (“K2M”). They have been awesome to work with. We wanted to share how this project came together.

K2M is a startup company that is revolutionizing how to manage captive insurance companies. Their founders have years of experience in the industry, and as part of their brand, wanted to create a completely new policy and claims management system.

There were many synergies between K2M and Augment; we feel fortunate enough to have been selected. The timeframe was very short; before the ink was dry, it was off to the races.

This post will focus on our process of taking K2M’s vision and making it a reality. Each item is numbered, but of course many of these elements have been and are occurring simultaneously. It is like orchestrating a wonderful overture.

Technologies Used:

K2M wanted to use .NET. Following are the technologies used for this project.

• ASP.NET MVC 5.2.3
• Kendo UI 2015.2.805.545
• Entity Framework 6.0
• Bootstrap v3.3.4
• jQuery 2.1.4
• Ajax/Java Script
• KnockOut JS
• Elmah Error Log
• Auto Mapper
• VS2013
• SQL Server 2012
• Dependency Injection

1. Requirements

The K2M process began with a discussion of the overall requirements, including as much detail as possible. As a whole, the requirements document the ‘vision’ for the system, and, when incorporated into a phased plan, allow for better coordination and deployment of resources. Each phase then has a number of detailed requirements, taken from the original requirements document, which are then described in documents called stories. The stories are minutely detailed, beginning with the overall functionality, the user interface design, down to each database element. The level of detail helps to avoid issues later on in the development process, and though, being AGILE, things change all the time. The stories establish a baseline from the original vision. The stories, then, are consolidated into time-boxed periods of time called ‘sprints’, within which the development, testing, and user acceptance must be executed so that at the end of the sprint, there is production-ready functionality.

Here is an example of a user story for the About Us page. At this stage the graphics are very simple. We are using the About Us page as an example since it’s the simplest page. Most of the User Stories are several pages long, sometimes up to thirty or even forty!

As we talked about in our previous blogs, we recommend this phase of the project be done onshore, which avoids a lot of communication gaps that can occur when done from far away. Augment is fortunate to have very talented folks work for us. One such individual is our Business Analyst and Database designer who is superb at capturing and translating the user’s requirements into a design that is scalable but includes an efficient database foundation upon which the entire project would be built.

2. Database Design

A big part of the requirements is designing the database. We have stellar database designers to handle this. This stage is critical, because a poor design may prevent additions or edits down the road. We often come across clients whose database design boxes them in. Their growing business is now unable to be supported by the database that was put together on the fly early on. Spending time at the front end of the project too often is cut short by the desire to get going quickly.

This phase goes hand in hand with the requirements phase, and thus we recommend that this be kept onshore as well. Once the core database model has been developed it can be handed off.

Here is an example of the database design for one part of the platform:

3. Architecture

We used an MVC (model view controller) architecture for this K2M project. Rather than go into all the details that involve MVC (that would be an entire book), here is a brief glimpse of the methodology.

This phase should also be executed onshore, since it is a fundamental and crucial piece of the build. In each of the onshore exercises, the objective is to ensure that the product is on solid ground. On all our projects, our in-house Architect usually builds the foundational architecture of our software projects. He also memorializes the coding standards to be used and routinely reviews all code that is written.

4. Project Management: Visual Studio Online

As we have talked about in the past, we use an AGILE development methodology. This includes daily standup meetings and 2 week sprints.

For this K2M project, we used Visual Studio Online. We have also used Jira and Basecamp to manage other projects.

Using the Agile methodology, we were able to quickly start the software development of the product. The initial four weeks of the project was spent building enough backlog of stories for the development team. Once the backlog was built up, the sprints could be planned and development and quality assurance (“QA”) could start. Development and QA is where we utilize offshore help the most. Hiring programmers onshore is often a challenge and costly. With our development team in India, we can quickly adjust the size of the project team to ensure sufficient capacity to maximize the deliverables for each project.

Another often overlooked area is QA. On this project we included QA personnel from the beginning of the project. As the requirements are developed, the QA plans are also being written. This ensures an intimate understanding of the product by the QA personnel. As we said earlier, the goal of each sprint is to deliver a usable (production-ready) piece of the software. Significant bugs/issues that are discovered during the sprint are usually built into the next sprint to be corrected.

Our project management and process is what makes our software development offshoring model work so well. We are in constant communication with both our clients and our developers in India. While we try not to disturb the work of our development team, it is critical to not have unaddressed issues. If issues are left unaddressed, problems invariably seep in.

5. Team Structure

For this K2M project, we have three onshore team members, including our technical project manager, software architect and database architect. At our India office, we have five team members, including a front web designer, two .NET developers, one QA member and one team lead.

The team has performed incredibly well over the course of the project, achieving far more functionality with very few issues than was ever thought possible by either our client, or us. And the blend of both onshore and offshore resources makes the pricing just right!