With software going big and complex and customers becoming more demanding than ever before, there is a need to ensure speed, consistency, accuracy, security, quality, and reliability. How long will the software companies keep developing software for only manufacturing, finance, sales, HR, and other functions of organizations? Is it not high time we started looking at automating the software development assembly line? I know that we don’t use the term ‘assembly line’ to describe the software development process ? SDLC (Software Development Life Cycle) is a generally accepted term in the industry. Perhaps this is the reason why not much importance is given to automating the SDLC processes by the IT process owners or the Software Engineering Process Groups (popularly known as SEPG) in IT services companies. Perhaps we now have to start referring to SDLC as Software Assembly Line and treat it as such.

Over the years, many models of SDLC have been evolved, starting with the linear or waterfall model to more recent agile models. Agile development also has many flavors like SCRUM, Extreme Programming, TDD (Test Driven Development), and so on. Iterative, Spiral, Incremental, Prototype, Joint Application Development (JAD), and Fountain Model are some of the other commonly used SDLC models. Not to mention the other ‘technology specific’ models introduced by Technology vendors like RUP, MSF, and ASAP, which I will not get into. If we consider the Waterfall and Agile models as the extremes – the former being extremely rigid and the latter being extremely flexible – all other models fall somewhere in between.

While each model has its own strengths and weaknesses and benefits and pitfalls, a closer examination indicates a few essentials in the SDLC and its many variations. The essentials are Planning, Analysis, Design, Development, Testing, and Deployment. The variations depend on the weightage or importance given to the essentials, whether they are done in a sequence or in parallel or iterations, the processes ? the ways the essentials are carried out and the role of various participants and stakeholders.

So, what does it take to create a software assembly line from the existing SDLC? No, I am not suggesting another new model. Follow the model(s) you are most comfortable with and apply these 3 key mantras – reuse, automate, and integrate.

Reuse
What can we reuse in software development? Many of you will immediately think of ‘code libraries that we developed in earlier projects’. You are absolutely right; but not completely right. Reuse does not pertain only to coding. Remember, regardless of the SDLC model you choose, coding is only one of the essentials in the SDLC. Okay, so what else can we reuse? Everything; let me go ahead and list some of them:

• Planning – estimation techniques, project plans, schedules, work breakdown, and so on.
• Analysis – Use cases, diagrams and pictorial representations, questionnaire templates, data collection sheets, and so on.
• Design – Architectures, design standards, DB designs, DB structures and objects, UI designs and templates, business classes, and so on.
• Development – Reusable component libraries, ‘how to’ code snippets, validation classes, generic application blocks, and so on.
• Testing – Test cases and scenarios, Test plans, and so on.
• Deployment – installation procedures, deployment kits, deployment guidelines, and so on.

Notice the use of ‘and so on’ in each of the samples above. It is important to identify the ‘and so ons’ in detail for your organization for each activity.

Reuse by chance or convenience can be dangerous. You don’t want to reuse something that failed earlier like a bad design or buggy component library. It is therefore important to plan the reuse. To do that, separate the ‘best’ from the ‘rest’ and the ‘showcases’ from the ‘no-cases’. Knowledge repository or a knowledge management system therefore becomes a necessity.

To facilitate a wider acceptance of reuse and to get the highest productivity through assembly line specialization, it is also very important to segregate the generics from the specifics. The generics can be reused while the specifics cannot. Any new project will have three kinds of tasks – the complex, common, and the repetitive ones. Plan the project in such a way that the complex tasks are done by the experts, common tasks are picked up from the reusable library (or created for the first time and added to the reusable library), and the repetitive tasks are done by the assembly line software developer.

Automate
Perhaps the major contributor to speeding up the SDLC is automation. As with ‘reuse’, ‘automation’ can also be done in each of the essentials in the SDLC. Project planning tools have been in existence for a long time and are widely used in software projects too.

There are many design tools that not only create good looking designs, but also generate code stubs to kick start the development. A design tool that seamlessly works with the development tool would be ideal for speeding up the SDLC.

Gone are the days where a text editor was used for programming; IDE (Integrated Development Environment) is now a bare minimum to start with. IDE gives the developers a common platform to develop, build, debug, and compile code. Sophisticated IDEs also have ‘intellisense’ or keyword lookups as you type to assist the developer in writing code faster. They also generate sections of code as needed.

What were until recently considered to be manual tasks – like code review and testing – can also be automated. As a project or company grows, managing code standards throughout the team becomes virtually impossible. A code auditing tool becomes especially useful in such a situation. It helps eradicate bugs, ensure consistency, and maintain clean, large, and complex source code. What’s more – the process of identifying warnings and errors hardly takes few minutes. There are tools to compute the code metrics like coupling, depth of inheritance, and overall maintainability. ‘Refactoring’ tools help in cleaning up the code and making it more efficient.

Compilation and build processes should be tightly integrated with the version control systems. In addition to facilitating the check-in and check-out processes, the version control and configuration tools can also be tuned to be the gatekeepers of clean code. A check-in can be blocked if it breaks the build. Continuous integration and automated builds save the headaches of integration issues and build version issues.

Deployment automation is provided as a feature in some of the sophisticated IDEs. ‘One click’ deployment ensures that the developers don’t have to worry about spending many days and nights creating deployment packs and procedures.

Integrate
It is very important to integrate the ‘reuse’ and ‘automation’ tools wherever possible. Higher levels of integration ensure higher productivity. The SDLC tools should facilitate the developer to use the right reusable artifact. Software engineers should get a seamless view between the plan, analysis, design, development, testing, and deployment.

• Integrate the project management and project documentation tool with the IDE
• Integrate the design processes and reusable artifacts as templates inside IDE
• Have code snippets embedded into the IDE
• Create project templates, form templates, class templates, and so on
• Embed your coding standards into the code review tool
• Compilation of a unit should also run the code review tool and give recommendations
• Build should succeed only if the code review and automated unit testing pass

There are many more areas of integration of ‘reuse’, ‘automation’, and the SDLC processes. Looking for more areas of ‘reuse’, ‘automation’, and ‘integration’ is a continuous and never ending process. It is high time we start building and using software for software development life cycle.

I conclude with this simple formula: Rapid Application Development (RAD) = Reuse + Automate + Integrate (R+A+I).

The author is Mahesh S. Prabhu, Microsoft Technology Practice Head of ITC Infotech