Application Basics

Description

This section discusses the generally understood phases or stages of application development. With current trends towards Agile development, it is critical to understand that these phases are not intended as a prescriptive plan, nor is there any discussion of how long each should last. It is possible to spend months at a time on each phase, and it is possible to perform each phase in the course of a day. However, there remains a rough ordering of:

  • Understanding intended outcome

  • Analyzing and designing the “solution” that can support the outcome

  • Building the solution

  • Evaluating whether the solution supports the intended outcome (usually termed “testing”)

  • Delivering or transitioning the solution into a state where it is delivering the intended outcome

This set of activities is sometimes called the “Software Development Lifecycle” (SDLC). These activities are supported by increasingly automated approaches which are documented in succeeding sections.

Documenting System Intent

The application or digital product development process starts with a concept of intended outcome.

In order to design and build a digital product, the Digital Practitioner needs to express what theory needs the product to do. The conceptual tool used to do this has historically been termed the Requirement. The literal word “Requirement” has fallen out of favor with the rise of Agile [Patton 2014], and has a number of synonyms and variations:

  • Use-case

  • User story

  • Non-functional requirement

  • Epic

  • Architectural epic

  • Architectural requirement

While these may differ in terms of focus and scope, the basic concept is the same – the requirement, however named, expresses some outcome, intent, or constraint the system must fulfill. This intent calls for work to be performed.

Requirements management is classically taught using the “shall” format. For example, the system shall provide …​, the system shall be capable of …​, etc.

More recently, Agile-aligned teams sometimes prefer user story mapping [Patton 2014]. Mike Cohn provides an example: “As a shopper, I can select how I want items shipped based on the actual costs of shipping to my address so that I can make the best decision.” Cohn 2009.

The basic format is:

As a <type of user>, I want <goal>, so that <some value>.

The story concept is flexible and can be aggregated and decomposed in various ways, as we will discuss in Product Management. Our interest here is in the basic stimulus for the application development work it represents.

Analysis and Design

The analysis and design of software-based systems itself employs a variety of techniques. Starting from the documented system intent, in general, the thought process will seek to answer questions such as:

  • Is it possible to support the intended outcome with a digital system?

  • What are the major data concepts and processing activities the proposed digital system will need to support?

  • What are the general attributes or major classifications of such a potential solution? Will it be a transactional system, an analytic system?

  • How do these major concepts decompose into finer-grained concepts, and how are these finer-grained concepts translated into executable artifacts such as source code and computable data structures?

A variety of tools and approaches may be used in analysis and design. Sometimes, the analysis and design is entirely internal to the person building the system. Sometimes, it may be sketched on paper or a whiteboard. There are a wide variety of more formalized approaches (process models, data models, systems models) used as these systems and organizations scale up; these will be discussed in future Competency Areas.

Construction

When an apparently feasible approach is determined, construction may commence. How formalized “apparently feasible” is depends greatly on the organization and scale of the system. “You start coding and I will go find out what the users want” is an old joke in IT development. It represents a long-standing pair of questions: Are we ready to start building? Are we engaged in excessive analysis – sometimes called “analysis paralysis”? Actually writing source code and executing it, preferably with knowledgeable stakeholders evaluating the results, provides unambiguous confirmation of whether a given approach is feasible.

Actual construction techniques will typically center around the creation of text files in specialized computing languages such as C++, Javascript, Java, Ruby on Rails, or Python®. These languages are the fundamental mechanisms for accessing the core digital infrastructure services of compute, transmission, and storage discussed previously. There is a vast variety of instructional material available on the syntax and appropriate techniques for using such languages.

Testing

Evaluating whether a developed system fulfills the intended outcome is generally called testing. There is a wide variety of testing types, such as:

  • Functional testing (does the system, or specific component of it, deliver the intended outcomes as specified in requirements?)

  • Integration testing (if the system is modularized, can modules interoperate as needed to fulfill the intended outcomes?)

  • Usability testing (can operators navigate the system intuitively, given training that makes economic sense? are there risks of operator error presented by system design choices?)

  • Performance testing (does the system scale to necessary volumes and speeds?)

  • Security testing (does the system resist unauthorized attempts to access or change it?)

Although testing is logically distinct from construction, in modern practices they are tightly integrated and automated, as will be discussed in Test Automation and Test-Driven Development.

Delivery

Finally, the system completes construction and testing activities – it must be made available (delivered or transitioned) into a state where it can fulfill its intended outcomes. This is sometimes called the state of “production”, discussed in Environments. Delivery may take two forms:

  • Moving installable “packages” of software to a location where users can install them directly on devices of their choice; this includes delivery media such as DVDs as well as network-accessible locations

  • Installing the software so that its benefits – its intended outcomes – are available “as a service” via networks; outcomes may be delivered via the interface of an application or “app” on a mobile phone or personal computer, a web page, an API, or other behavior of devices responding to the programmed application (e.g., IoT)

Delivery is increasingly automated, as will be covered in the section on DevOps technical practices.

Evidence of Notability

The basic concepts of the “software lifecycle” as expressed here are broadly discussed in software engineering; for example, IEEE 2014, ACM/IEEE-CS 2015, and Sommerville 2001.

Limitations

Application construction, including programming source code, is not necessary (in general) when consuming SaaS. Many companies prefer to avoid development as much as possible, relying on commercially available services. Such companies still may be pursuing a digital strategy in important regards.

Related Topics