Making a description over how a software application is developed is not an easy task. There are many ways to do it, and none of them guarantees a predictable outcome. A development process describes activities and artefacts; used tools make it visual; a strategy is a point of view; and needed resources gives a static picture. Nothing is sufficient on its own, each plays a different part in the challenging work of application development.

A process model serves different purposes for different stakeholders. Software that is developed for desktop and mobile apps need a different model than web apps. The process model can be viewed as a map over spent and remaining work. The problem is that a project is in multiple activities most of the time and it's therefore a blunt instrument for management to measure progress. The other purpose is to tell a development story, which activities to emphasise and which to not pay any attention to. This is really about having a development strategy and should be talked about as such. Process models are also used by the consultancy industry as a marketing ploy to convince potential customers. One should also not forget that for every commercial product that is released, there is at least one that is only used for internal support, and they may be built differently.

One problem with having a defined process for software development is that it in many cases describes abstract activities. Design, coding, testing, and User documentation are usually empty boxes that need to be filled with human ambition and talents to have any meaning. Without tangible results in the form of documents, code modules and test cases, process descriptions lean on abstract activities that have no clear pass criteria or how they ought to be executed. Most process descriptions are therefore supported by document templates and checklists, which tend to use the same abstract language and ideas as the activities they are supposed to support. When process models and document templates can't be firmly tied to a single problem domain, they become abstract to suit everyone. In search for the holy grail – to find a stable foundation for problem learning and solution – new paths are explored that are either based on sequences or the iteration of activities. What is thought of as a "stable foundation" is really a development strategy that may not suit every type of product. Fast iterations, larger increments, or a Big Bang have all disadvantages when it comes to learning and building a solution. Developer experience and discipline will decide if and how a process is used in the end.

A foundation that rests on tools and technologies avoid abstraction problems; it will however only work for a specific type of products or problems. Which tools to use and how to use them is largely decided by the strategy; it is also a question for training and evolving skills. A different strategy will have a different set of tools and a different process model. For a process to work, Users must be able to go from a process activity to a tool with ease. How the tool is used may be decided by the activity.

In the rCoach One case, the process to build a completely new product does not rest on a series of rigid steps. There is no formal description of relationships between activities and sequences; activities can be executed in whole or partly, once or repeatedly when needed. New issues that are discovered during the release phase impact source code, documentation, test, and perhaps the User Interface, all at once. Minor issues are usually corrected in minutes or hours, while more serious issues can take several days or even weeks.

A new product is focused on a few, well-designed services from the start. An operating system must deliver hundreds of ideas, while an application like rCoach One is based on fewer than twenty services. The first release of a product is always special; the idea phase of a non-existing product can easily suffocate a project as it is filled with enthusiasm and excitement. A product that reaches maturity enters a new phase; new releases aim for fewer than five services that are either reworked or completely new. As much as 80% of the work is directed at bug corrections and the redesign of existing services. Bad design stares Users in the face every day. The overall strategy for rCoach One is to make product releases that are incremental, without having a fixed timeframe, which is perhaps only something a micro ISV can afford. A feeble attempt to describe the software development process for rCoach One may look something like this.

The Requirements Specification is central for all new releases. It evolves with made releases, but it also evolves during a single release. A Specification revision is "frozen" when it is stored in the Data Repository. During a single release, several revisions are stored in the Repository. The Spec fuels all succeeding activities. There is no formal Review of the Spec, Review Comments are written on a "frozen" Spec and stored in the Data Repository. It is the responsibility of the Spec Author to update comments and set their status.

Code and classes use the terminology and services described in the Spec. The Documentation Compiler tool (DocC) in the Xcode IDE is used to document application programming interfaces (APIs) and supporting articles; all API documentation is part of regular coding activities and is incorporated in Xcode's documentation environment. The documentation is built every time the product is built. Unit tests use the XCTest framework, and are written as soon as a service is developed. Quality goals decide the test coverage span each type of software should have. Key algorithms and key services call for a higher test coverage. User Interface tests may for practical reasons and available resources be postponed until most of the software has been developed.

User documentation is written as html pages while developer documentation uses DocC's markup. Build instructions, release history and key algorithms are documented as articles that are compiled by DocC and easily accessible through the API documentation. Besides the API documentation, no formal design documentation is written with the exception of cheat sheets that are documented as PDFs or rich text documents. All documentation is treated as code when it comes to version control.

The Test Protocol is one of two mandatory documents that is written and updated for every release. It consists of a single page for each Release Candidate (RC), containing a short summary of results from made Unit tests, User Interface tests, and informal end-to-end tests. Detailed results produced by the Xcode testing tool are not documented in the Test Protocol. The protocol documents build version, testing equipment (Operating System and hardware), the individuals conducting the tests, and when testing was completed. The Test Protocol serves as a historical document over all Release Candidates, and is great to have.

The product is built as a debug version while development activities continue. Source code and documentation is added and committed to the version control system (Git) when needed. There are three mandatory branches that are maintained: a branch for development, the master branch, and a release branch. There are separate release branches for every major and minor release, for example 1.0, 1.1, and 1.2. Bug releases (1.2.1) continue on an existing release branch. Web contents have no release branch. When Unit testing and User Interface testing have reached an acceptable level, the product is built as a Release Candidate (RC). This phase can last up to three weeks or longer, depending on the severity of discovered faults during end-to-end testing. Release Candidates are open for private Beta testing. A Release Candidate is set in status General Availability (GA) when released permanently.

There are provisioning activities in the form of mail templates, sales and marketing materials that need to be developed and updated, but this is strictly outside the process model for product development. In the choice between process models and tools, the later win always. Process models are the poor man's choice in software development.