 Defining a Software Development LifeCycle (SDLC) can raise many behavioral or “people” related challenges. Any effort to specify how people should work is bound to meet with extensive resistance and even hostility on the part of the developers who must adhere to the development process. Yet it is essential that the successful CM Practitioner create a release process that is repeatable and predictable. Tremendous losses can occur if a major company has production applications that cannot be quickly fixed because they do not have the exact sources and build dependencies safeguarded and available. In this article, we would like to look at how to create a useful SDLC that specifies the workflow necessary to support the Software Development Process, especially Release Management.
Driving Out Fear…
Deming wisely pointed out that quality organizations need to create an environment that allows people to work without fear. Many employees are driven to “do nothing,” because taking action too often results in penalties as a result of making mistakes or failing to successfully complete a challenging task. Many people do not like having their work scrutinized and evaluated by others who are in a position of power. Defining a Software Development Life Cycle can inadvertently result in a similar sense of fear on the part of developers who sense that their autonomy and control of their environment may be at risk. This situation can lead to significant resistance on the part of workers, whose cooperation is essential to improving the software development process.
Becoming a Good Salesman
The successful CM Practitioner is able to present the Process and Technology of Software Configuration and Release management in a compelling way. Selling the establishment of an effective SDLC is an essential task for any process improvement specialist. The CM Practitioner owns, at minimum, the Release Management part of the SDLC. We can also add value by employing our skills at establishing the overall development process in a compelling and useful way. This can only be achieved by establishing fair and reasonable goals. Too many SDLC efforts fail because they are either so bureaucratic that they simply sit on the shelf or they are so high level that they don’t add any value to the members of the organization who are responsible for following the SDLC on a daily basis.
How detailed should an SDLC be? A useable SDLC should be detailed enough that a new employee would gain a substantial amount of information on how to get his/her job done successfully. The SDLC specifies the required tasks, roles & responsibilities and milestones that are required in order to successfully deploy a release. This information can be obtained by interviewing managers, employees, observation and reviewing the relevant literature for good ideas on best practices and industry specific standards. For example, most Global manufacturing firms are expected to be ISO 9000 compliant. There are a number of best practices that can of value to any SDLC that can be learned from reviewing the Software specific ISO 9000-3. This author works in a large scale financial services firm where there would be little or no interest in adopting ISO 9000 as a model. However, creating an inventory of release components (we call this release mapping) is a best practice that is described in the ISO literature. These ideas must be practical and useful in order for them to accepted by software development professionals.
Developers and Managers Must Have a Voice
It is a very good practice to ask development managers for input on what they do well and what they believe that they could improve. It has been mentioned previously, that the difference between how developers and managers answer this question can be most illuminating and diagnostic.
Let’s work through an example… The manager may say, “everything always takes so long” and the developer may present the view that, “we never get time to test our code.” These two views are really two sides of the same coin! This difference in perspectives may illustrate poor communication between the manager and the development staff.
How Can an SDLC be Used to Address This Kind of Problem?
Defining an explicit testing phase in the SDLC can be a good start, but this is often bypassed when deadlines are tight. However, an SDLC that defines that test cases should be given to the developers up front instead of at the end of the testing process, can be a practical change to the SDLC that gives the developers valuable information (that closely resembles user requirements). The key to getting this step accepted by all concerned is to keep the test case description detail to a minimum(e.g. state what will be tested and what the expected results should be). We postpone the specification of a detailed test script (how to do the test) to a later step (e.g. after detailed design and analysis). Granted, in many cases the detailed test script will never get done and that is unfortunate. But getting the test case information to the developer, upfront, helps provide useful information and visibility into the effort that is required to deliver the release.
This author has seen this approach work well in a fast paced financial services environment, especially if users or their representatives are involved (as part of a cross functional team). In one case, the user stopped the development effort because they suddenly realized that what they had asked for was not what they wanted!
A useable SDLC lays out the steps in the development process in a practical and helpful way. Obviously, it should also improve the overall communication of the group by specifying what information needs to be shared and when. Figure 1 shows a suggested process whereby the development manager must request a Version Label from the buildmeister if he/she is ready to deliver the release. The version label is locked BEFORE the independent release build is done (which prevents everyone from moving the label to later versions of the code). The Development manager must advise the buildmeister if additional changes are needed. Once the release is in production, the Version Label is permanently locked. Since the buildmeister rebuilt the code based upon what he can see via the locked version label, we are certain that we can rebuild any release in production. Many CM tools provide this capability, but few groups define an effective way to use their tool!
Set High-level Goals
It is often a good idea to set strict high level goals, but allow developers a lot of flexibility in meeting them. For example, we define three essential goals:
- All source code must be safeguarded.
- All build (e.g. compile) and runtime dependencies must also be safeguarded.
- Any release that is in production must be able to be rebuilt with the EXACT sources
at any time.
We tell developers that they can either adopt our best practices (that are widely used throughout the firm) or they can suggest their own. Since all of our best practices come from the development community, we are using peer pressure to gain compliance. This effort is often described as going around the company stealing everyone’s best ideas and giving them to everyone else. In effect, the CM Practitioner is somewhat neutral. He/she simply ascertains and reports on the best practices that are in use throughout the firm.
Handling Exceptions
The biggest challenge to any SDLC is handling the inevitable emergency situations that require emergency action. We plan for bypassing the process. At the end of the day, we are in business to make money. Sometimes this means that we need to cut corners. But bypassing our standard procedures requires approval from a senior manager. Most developers do not want to be in a position where they are asking to bypass the standard procedures on a regular basis. Failing to anticipate and manage emergencies can lead to management deciding that an SDLC is too inflexible and impedes running the essential business of the firm.
Compliance and Monitoring
Using the computer to generate surveillance reports works well in many IT environments. It is also culturally appropriate. Reports can indicate “Aging Checkouts” (files that were checked out for modification, but have not been checked back into for some specified time period (e.g. 30 – 60 days). Use of Version Labeling to track production releases and security reports on who has made changes (in the source code repository) can also be very helpful.
An SDLC specifies what tasks should be completed, by whom and in what order. It should include some clear tests (e.g. aforementioned independent build) to confirm that the process is being followed. Defining an SDLC should be done with many of the behavioral and “people” issues considered. An SDLC that is JDE (Just Detailed Enough!), practical and perceived as fair is much more likely to be useable and helpful in defining and improving the Software Development Process.
Trackback(0)
Comments 
Write comment
 |
Behaviorally Speaking 
TrackBack URI for this entry
Subscribe to this comment's feed
