Organizing Development

The Software Development Life Cycle
An example diagram.

Every piece of software, whether it's a website, a videogame, or your email application, has a development process. There are many different roles played by various team members. At each step in the process of building and maintaining software there are different needs and goals. It's important for all team members to understand the process they are using to build software or else problems will arise.

The Software Development Life Cycle

The Software Development Life Cycle (SDLC) is a term used to refer to the process by which any given piece of software is built. The specific steps in the cycle will vary depending on project and team, but the base goal remains the same: Guide the team in the evolutionary process of building and maintaining their software product. Again, this could be a website of any kind, a mobile application, or a research tool for a small group of scientists.

At a high level, you can generally break down most SDLCs into four steps: Require, Design, Implement, Evolve. It's important to recognize the software development process as an iterative one. The entire SDLC is a big loop, and within each step are smaller loops that iterate until completion. It is at the more detailed levels of the process where the variation between teams and projects becomes dramatic.

Require

All software has a set of "requirements," which is a list of things the application must be able to do. These requirements come from a variety of sources. A business opportunity might lead to a set of requirements defining a new feature that could open a new market. A staff member may suggest changes to a backroom tool that would make the job much more efficient. Customers may submit feature requests and suggestions via online contact forms.

Each organization has some process by which they distill requests and ideas into prioritized lists of things to accomplish, and then they set about defining what those things truly mean in terms of work. Often different team members are involved at different levels during this process, and this is often the step in the SDLC where the most input from people outside the product development team is needed.

Some parts of many Require phases are:

• Feature Requesting/Evaluation - Features are received and evaluated for relative value and opportunity.
• Requirements Gathering - Requirements are listed and described for features that will be seriously considered for development.
• Prioritization - Features are ranked according to their priority for development, which is often determined by evaluating the relative value against the relative effort needed to create a given feature.
• Estimating Effort - The work involved in creating a feature is estimated at a high level, and possibly for each major area of effort (visual design, code, and QA).

Design

In building websites and web software, design encompasses several areas of activity. The goal of the Design phase is to think through the "How?" questions of the task at hand. This includes thinking through the technical functions of the feature as well as thinking through the visual presentation of the feature within the project. The design phase also often involves thinking about other elements of new feature development, such as what new content will be needed to support the feature (both content in the feature itself and any help documentation required to allow users to properly experience the new feature). Another area where design plays a role is in Quality Assurance (QA). The QA Team will often be tasked with designing test suites and planning how to approach building in automated testing and how to manage testing of releases during this phase.

Some parts of many Design phases are:

• Wireframes - Low effort sketches of possible interfaces created to assist in discussions of what functionality is needed and where.
• Comps - High resolution concept art ("compositions") showing in great detail what a given screen or step in a technical process might look like.
• Information Architecture - Detailed outline of the information presented on the site and where each piece of info lives.
• Technical Specifications - Detailed descriptions of how features should be built, including technical requirements for how code for a given feature should be added to the project.
• Data Models - Descriptions of major data attributes to help guide discussions around information architecture and presentation.
• Test Plans/Scripts - Descriptions of every action, layout, and element that will be tested by the QA team, either through automated or manual testing.

Implement

Once it is known what will be done and how it will be accomplished, the next phase of work is to build out the new features. This involves many different groups as work moves along to be ready for a production deployment or official release. The design work created in the previous step is all made real in working code, media files, and content.

In addition to the buildout of the working software, there is usually a set of checks that must be passed before something gets deployed to a customer-facing release. The QA team will likely set up both automated and manual testing to insure a bug-free release. Other approvals may also be required for release.

Some parts of many Implement phases on a web-based project are:

• Media Creation - Media must be created to serve the needs of the site, including images, videos, audio files, etc. Many of these items must be created at multiple sizes/qualities/crops.
• Coding - The software required to run the logical parts of the website or application must be created using a programming language such as Python or Javascript.
• Markup - HTML and XML files and templates that must be created in order to display information to the end user.
• Styling - Cascading Style Sheets (CSS) describe the visual look and feel of all the elements in the HTML, giving the website an appealing look and feel.
• Acceptance Testing - As features are completed, stakeholders approve them to make sure they meet user expectations.

Evolve

Most successful software enjoys a long lifespan and sees many updates. This process is ingrained in software development, and is incredibly evident in web-based projects. In general, features are built to the "minimum viable" level -- meaning, they are built with the smallest number of features that offer a specific value. Once a project is delivering it's core value with a minimal number of features, the product usually matures into something more complete. But for each new feature that comes along, most projects take the approach of baby steps and many "iterations".

The idea of "iterations" and "iterative development" is very popular, and with good reason. This is the practice of building some piece of software, then taking a critical look at it to determine where it could be improved, and finally making changes to improve the experience. Software is experience based, and our reaction to experiences evolves over time. Software must evolve with its users and the rest of the world.

Some parts of many Evolve phases:

• Maintenance - Rapid bugfix and deployment cycles to address small issues and to fix broken features.
• User Testing - Observing real users interacting with the product in order to determine where there are inefficiencies and bad experiences.
• Multi-Variate Testing - Testing alternate content, layouts and event functionality on real users interacting with the product online.
• Research - As new developments support new ideas for technical or visual design, it's important to keep up and make strategic decisions about how they can be used to improve the product.
• Planning - Creation of a product roadmap, especially with regards to near-term development work.

The Speed of Software Life

On the web, new versions of a site can be delivered as fast as they can be coded up, and it's even possible to offer new features to some portion of users so that ideas can be tested and improved before being released to the general population. Many major websites "deploy" -- publish a new version -- of their project multiple times per day.

Many companies may break out this base SDLC to several groups and have multiple streams of development running on their projects. Various decisions in how projects are put together can support many complex versions of the simplified SDLC presented here. 

It's crucial to understand that building a website or application is a large project, and it requires some planning and pacing to carry through with everything. It's very easy at times to focus on what we can do as solo artists, but small groups can build very large projects with a little organization and persistence. The point is not to "get it right" the first time, but to establish a sustainable cycle that gives teams the space to "get it right" most of the time, and "recover fast" when they don't.