– A methodology used to develop, maintain, and replace information systems.I’ve seen many managers, developers, testers, and product managers that have caught the SDLC buzz word fever. They’ve either latched onto the newest, latest, coolest, methodology, or they read in a book that you can’t succeed without one, or (most likely) their manager said that they need to have one. However they get to this state of mind, they usually follow the same course of action.
How the situation becomes problematic:
The Analyst goes to bookstore and buys a book
Reads the first few chapters of said book. Sometimes even makes it all the way through
Goes to the next team meeting, and declares that they are implementing an SDLC.
(Meetings are called with subjects that mysteriously match the book’s chapter headings!!)
The rest of the team has no idea what is going on, but they are following their enlightened SDLC leader blindly. It still seems like they’re writing and testing code, so at a granular level, most everything seems to be the same
…… The Project Continues …..
Utter chaos ensues, the product is late, the quality suffers, and it is deemed that SDLC’s are worthless.
Team reverts to prior process, and ships with previous efficiency, tracking, quality issues, and deadlines slip.
While that may sound bad, they still productionize the code as a key test of success or failure.
So where does the value from using a methodology come from?
Well, it might come down to one thing: ‘Change Management’.
If there was only one programmer, and he knew the customers, wrote the requirements, wrote the code, tested the code, fixed the code so it was bug free, packaged the product, and shipped it, there would be no need for an SDLC.
OK, now back to the real world. Requirements change. Team members quit. Testers miss bugs. Developers write more bugs when they fix the bugs QA already found. Customers can’t point out what they exactly want. The list goes on and on. This is where having a defined methodology helps. It gets your entire team on one page. When someone falters, everyone knows, and everyone understands the impact of what that means and can adapt. It is not a blame issue, but one of good communication. When you have a team driving toward a common goal, working in a common way, helping each other succeed, then you have a team with a shared vision. A team with a shared vision can do amazing things. They can have requirements change at the last minute, and everyone knows where to help, who is impacted, and how to react. The same scenario goes into effect when someone on your team leaves. Normally, the team is lost for a bit. Some piece of critical information or a critical process lived only in that person’s head, and now that they are gone, the team is lost. Again, common steps, common process, common knowledge, shared vision, and teamwork. All of this leads a team to be adaptable to change, and having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software.
“Having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software”
Then how does all of this apply to me? I’ve been through a handful of projects, and I’ve learned the most important lesson about SDLC
All of those books look really good in print, but they are all based on best-case scenarios and case studies. The key is to learn as much as possible, study many methodologies, and adapt a methodology to your team.
Our Company has a personal methodology that we follow, with parts taken from a few different communities, but with each new team and each new project, the process is adapted.
“The value of a process is to help organize your team, not to organize your team according to the process”
There is always pain, resistance, and adaptation when implementing change, but it should be for the betterment of the team, not because you are trying to fit the team to something from a book.
Following is the general methodology that I have seen successful in the past. It is a combination of a traditional waterfall development cycle, but focuses on short term, iterative deliverables during the development cycle.
Establish high-level requirements.
These need to be detailed enough that the technical design can be built from these requirements. This deliverable essentially drives the vision for the release. A release roadmap is also required, so that the development team can understand what the future product plans are, with as much clarity as possible.
Define the detailed requirements.
This task takes the high level release requirements, and drills down to a sufficient level of detail required for the development team. As each detailed requirement document is completed, it is sent for peer review and acceptance by a representative from development, quality assurance, architecture, product management, and development management. This task happens in parallel with the technical design.
Define the technical design (Architecture).
Based on the high level requirements, establish a product architecture taking all three releases requirements into account. The architecture deliverables for version 1 should be at sufficient detail for the development team to use, and mock architectures should be vetted in order to validate feasibility for the version 2 and version 3 requirements. This task happens in parallel with defining the detailed requirements.
The development team executes the detailed requirements and the technical architecture. This process is somewhat agile in nature, since features can be started once the specification for that component is complete, rather than waiting on an entire requirements package.
The QA team validates the software created by the development team meets the defined requirements. Test cases are created for each completed requirements document, following its peer review acceptance. For a test engineer, the requirements should read like a contract, validating that development met their end of the contract. As is typical during a development cycle, requirements will change. These will be handled as requirements addendums or modifications.
Release to Manufacturing.
This is the final step in the process. Once a product is ready to be delivered to market, this step represents the processes preparing for general availability. Depending on the organization, the timing for this process is generally organizationally dependent.
references taken from : www.ittoolbox.com