Software Process

What is Software Process?

Software Process is essentially the steps you take to turn an idea into working software that people can use.  There are as many different software processes as there are organizations producing software.  Remember, "No one size fits all!"

Below are some of the common steps in any software process.  We generally think of software development as everything required to get the software ready for deployment, and then operations takes over.  Again, many variations exist, but the concept of DevOps (Development + Operations) sprung from the need to get better coordination between what is often two separate parts of an organization with often very different goals.

There are many books written on software process (and DevOps) with many competing theories about how to produce software best.   It would be virtually impossible to list all of the books or try to capture all of the different methods in one place.  But there are certain common elements that are impossible to avoid.  Below is a short list.  Each part of the software process has its own unique challenges, and failures can occur in any one of them, so it's important to have strong teams in each area and good checks to make sure each step is done well.

Requirements

Requirements definition and documentation probably has the widest range of possible methods of all of the different parts of the software process.  Everything from "the requirements are in the Coder's head" to mathematical formulas using discreet math or pseudocode can be used for requirements.  Neither of these extremes work very well for most organizations, however, so usually the requirements are documented in writing and pictures and sometimes flowcharts with varying levels of organization and rigor.  Whatever the system, however, getting the requirements right and being willing to adjust the requirements based on evidence from the real world is a key to a successful software product.  This actually applies to any product, not just software.  But software, because it is so extremely flexible, seems to present a bigger challenge in defining requirements than many other types of products.

Architecture

Architecture defines how the system will be organized from the highest level.  This is like the blueprints of a house.  It is the plan for the system.  One must spend time planning out a software system before embarking on implementing it.  What technologies will we use?  How do the various components work together?  What is the network topology?   The software architecture needs to answer all of these questions and more.  For simple systems, the architecture will be simple.  For complex systems or systems expected to carry a heavy load of users, the architecture will need to be planned, modified, and maintained over the lifespan of the system so that decisions of changes to the system are informed by the current situation.

Design

Software Design is the plan for a smaller piece of the software.  Design is probably the most overlooked part of software development, which is why so much code is disorganized and often difficult to maintain.  Disorganized code often leads to a large number of bugs, so spending a few minutes up front on design can save you many hours of hell chasing down bugs later.

UX/UI

Another oft-overlooked part of the process is UX/UI.  UX refers to the user experience.  What are the steps that a user will follow to achieve a particular result using the software.  Successful UX will lead to intuitive software that allows users to interact with the product without difficulty.  UI is the User Interface, which often requires someone with more of a graphics background than your average coder might have, so that the software created is pleasing to the eye and easy on the soul.  Often, the same person is both the UI and the UX expert that can both design the layout of the user interface and ensure that it is intuitive and easy to use based on principles that only these artistic gurus know.

Implementation

Implementation is the actual coding required to make the software work.  This is extremely complex work not only because of the challenges of Boolean logic but also because today's Coders have to be familiar with vast libraries of software development tools that are used to produce the desired outcome.  It takes years to build up the requisite knowledge to become a good programmer.  And it takes patience to try and try again until you get it right.  Good coders are worth their weight in gold (and their salaries reflect it).

Testing

Testing is also an often overlooked function in new software organizations.  The Coders write the code, and of course it will work!  Incorrect.  Because every step of the software process is so difficult, and there are so many ways  of introducing defects (bugs) in the system, there is an extreme need for testers in any software organization.  Some people claim that fully 1/3 of the entire schedule from coding start to successful production deployment will be the testing and bugfixing phase.  Organizations that do not build enough time for testing and bugfixing into the schedule will release late.  That's just the reality of software.  There will always be bugs.  You just have to get them down to the level that you can live with them in your software.  And that requires testing, fixing, testing, fixing, and more testing.  Count on at least six rounds of testing end to end with bugfixing in between when planning your software schedules.

Deployment

Deployment is another critical phase in the software process where many things can go wrong.  Generally, your production environment does not match 100% percent your test environments.  And your test environments might not match one another.  There is rigor required in maintaining the environments, configuring them to the needs of the organization, making sure the code that is intended for a particular release is deployed to the right environment, and ensuring there is traceability and backup plans should something go wrong.  This is where strict discipline is required in order to keep track of the thousands of details that must be managed in order to have successful releases.  Organizations that start out with less rigor in this area will often develop rigor over time because when mistakes are made users complain, and every software organization wants happy users.

Maintenance

Some organizations will have the same developers who create the software maintain the software.  Most organizations, however, have a separate team of people who are dedicated to maintaining the software in production.  As issues are reported by users, the team collects and prioritizes the fixes.  Sometimes lengthy investigations are required.  Because the engineers who maintain the code did not write the code, it is sometimes difficult to implement a fix.  Other times, the maintenance team may send the bugfixes to the team who developed the software in the first place, if they are unable to fix the code themselves.  The cost of software maintenance must be considered when planning out any software system.

Decommissioning

At some point, the software will no longer be needed.  Sometimes a software product's lifespan is short.  Other times it exists for many years.  But at some point the software will either be decommissioned or be rewritten and replaced.  Whatever the case, there should be a plan for this as well when software products are defined and planned.

Summary

We're just scratching the surface of software process topics here.  My goal is not to write another book about software process but rather to highlight some critical concepts that can be further explored.  Consider this an overview for those people or organizations just getting started with new software development.

<< Previous   |   Next>>