Software as a tangible asset is misunderstood by many. Unlike a car or a toaster that people can touch, hear, smell and feel; software is a component in a rather complex system. Although one might look at a car, toaster or any other fixed asset as something that gets stamped out of a factory. There are many similarities in the traditional manufacturing process; and the software development and release process. Let’s use cars as an example. Like software, cars evolve. Look at the evolution of the Ford Mustang for instance.
The “Pony Car” as it was later coined was something that nearly everyone felt attracted to. The Mustang was advertised as “the car to be designed by you”. Given this premise, the Mustang was bound to evolve. As demographics change and the car buying tastes of Fors’s customers evolve, the Mustang was designed from the beginning to evolve as well.
From its beginning in the latter half of 1964 up to today, the Ford Mustang has evolved as has the 60 million or so baby boomers that have grown up right along with it. The 1964 was available in only two models: the coupe and convertible. These were the glory years, with the introduction of the Fastback and GT models in 1965, the Shelby GT-350 and Mach 1 in 1966, and the GT/CS California Special in 1968. In 1969 the Mustang became bigger and heavier.
Ensuing generations of Mustangs have either added to the legend or diminished it. The bad years are considered to be from 1974 until the early 1980s whereby Mustang’s sporty image fell victim to the fuel crisis of late 1973 and increased safety standards. The Mustang made a come back in the 1990s when it began to go back to its sporty and horsepower packed roots. The evolution continued in 2005 when Ford re-invented the classic Pony Car styling with a Mustang that harkened back to their late 1960’s success.
The development of software is an evolutionary process. What starts off as an interesting software idea or web-application can morph into something that takes on a life of its own. There are countless examples in the enterprise software world of products that have grown so large that the cost of maintaining these systems often times outweighs the benefits of using them.
Large enterprise class software systems also evolve as technology improves and customers’ needs change. Like a manufacturing company, software companies must manage growth as well as demographic, economic and geopolitical changes through a defined development process.
Since the beginning of 2007, Exuma has undergone a transition away from Software as an Art to Software as a Discipline. What I mean by this is that we searched for and have adopted a software development process that will allow us to be flexible enough to meet customer needs, but be rigid enough to improve quality. These standards are collectively known as the Agile Software Process.
Fundamentally, Agile affords us the ability to build and test in quality by focusing on a finite number of enhancements and bug fixes in short cycles. These cycles, known as sprints allow software development teams to prioritize bug fixes and enhancements; collectively known as “backlog” into a manageable list that can be developed, tested and deployed in a short period of time. Sprints can be broken up into 1 to 4 week segments, whereby the team will focus on a manageable number of backlog items without interruption from other department. Figure 1 (click here) outlines the basic Sprint cycle.
A team of developers and QA personnel are assigned to a sprint cycle. One of the team members is designated as the sprint leader. The rest of the development and QA staff provide support for the rest of the company including, Support Services, Client (Training) Services, etc.
The non-sprint team members are the only ones permitted to contact the sprint team lead. This keeps the level of distractions coming into development at a minimum. Developers outside of the sprint team will provide “support†for the rest of the company on programming issues.
Once the sprint team completes its changes and tests its individual components the software gets “built”, meaning the entire product suite, including various interfaces, get compiled into a machine readable language that can be used by an end user. Builds are typically done at least once per week and as often as once every 24 hours.
Once the software is built the quality assurance (QA) team begins their series of tests. Programmers typically test their code on a functional level within the module that they are working in. QA does what is called System and Regression Testing.
System testing is a process whereby a series of functions are performed to test their effect on the entire system. To use a DockMaster, rather than just testing if the decimal time function works correctly in time clock entry, a system test may include creating a work order, entering time from time clock, entering time from time card, entering time at the WO and then billing the work order. Once billed the system tester may look at the accounting or journal transactions to make sure they are accurate.
Regression Testing is when test results from the latest release are compared to the results of a previous release. Using our example below, the QA person may run the exact same test on a previous release and then compare the time entries and journal information. These tests are typically automated using test scripts.
A sprint cycles does not necessarily correlate to a release cycle. For instance, there may be 2 or more sprint cycles before a release is produced. For instance, if a sprint is broken down into a one week cycle, a software company may have the following builds:
4.2.62C – Release candidate
4.2.63A
4.2.63B
4.2.63C
4.2.63D – Release candidate
Although there were four builds in 4.2.63, only 4.2.63D was a release candidate and pushed to system testing, then general release once it passes.
By getting the entire company to adhere to this new development methodology we have realized the following benefits:
1. Higher quality which leads to fewer bugs and support calls
2. Better documentation which reduces ambiguity in the product
3. Quicker time to market for new features and enhancements
For further reading on the subject check out:
Controlled-Chaos Software Development
DSDM Consortium
Introduction to Best Software Writing