Software Design and Development
While there are thousands of software packages and mobile apps on the market, sometimes there is enough of a feature gap between what is available and what you want that it's worthwhile to decide to build vs. buy.
When you decide to build instead of buy, you may be overwhelmed by the decisions you're suddenly forced to make:
- Who's going to use the application?
- What technology/technologies should we use?
- Is our data going to be correct and safe?
- Who is going to help if something breaks or we need changes made?
A major part of the development process is to set up a system that will grow with your company's needs over time. Deciding what to put into "version 1" requires a balance between time, resources, and priorities. We can help you make these decisions. Using a "blue sky" mentality works great for identifying what you might want to do, but you have to come down from the clouds eventually to decide what's the most important feature set to build.
The Development Process
In software development, there are two main methodologies prevalent in the industry today. The first is called waterfall development. This is the traditional development model that proceeds sequentially through these phases:
- Requirements Gathering
A second model that is often used is the agile development model. This model lends itself well to internal or ongoing projects where new requirements are obtained on an ongoing basis and the project leadership makes decisions on how much development will be done. During each development cycle (known as a sprint) requirements (known as user stories) are prioritized for completion during that sprint. Development, testing, and deployment of these stories are done either within the sprint or as a "deployment sprint" following the development sprint. The cycle is then repeated with a new batch of requirements.
Since the requirements are not known upfront, determining the total cost of the project is impossible, which leads to complaints that the process is not predictable from a budget point of view. However, this is where project managers can control the spend by limiting the number of developers or hours being spent in a sprint.
NCS is experienced with both methodologies if your company has an existing development team that we'd be interfacing with. For projects that are exclusively NCS-run, we generally use the agile model but we do it conscious of the fact that budgets are not unlimited. We will work with you to plan out each sprint and help create estimates so you know up front what you're spending.
Some developers only want to focus on the newest "bleeding-edge" technologies and deride any applications that are older. This is very common in web-based development when new technologies are being released every month. Just because something newer has been released does not invalidate the investment in the previous technology. In many cases, there is not enough money to replace an entire legacy system. Instead, it's better to build interfaces to link with the older system while you make small steps towards replacing it.
While we prefer to work in the Microsoft environment using Visual Studio development tools, we also have experience with non-Microsoft technologies and client-side frameworks. We make frequent use of both open source and commercial components when they can solve a problem more efficiently than a custom solution.
Besides the technology, we can also help you determine what type of system to build. While web-based applications are common now, your situation might lend itself better to an actual application installed on your machine. You may want to have a mobile solution, but unless you need the capabilities of the mobile device, a mobile-optimized web solution would provide for easier maintenance. There are ways to share features between different application formats to help use your investment in more than one way.
Managing a project's scope and complexity is at least as important as the actual development work. Being open-minded about what you COULD do is important, but sorting out the must-have's from the nice-to-have's is an important step. We have an internal tool that helps us manage the user stories our clients come up with, but if you have an internal project management group, we can adapt to work with whatever structure you have. Ongoing project management documents, including time tracking, status reports, and other documents are all part of what we can provide to you and your company.