Going with my premise above, one of the major steps in the application lifecycle is the actual delivery of the...
application. This is where the SDLC comes into play. SDLCs are all about the process you will use to deliver an application. Most SDLCs provide a formal set of phases and tasks within each phase to deliver a working piece of application software. In most cases the SDLC is based on a formal software development methodology.
In the best case scenario, a development shop will only have to deal with a couple of distinct SDLCs: one for when they acquire packaged apps and one for when they deliver custom applications. In some cases the actual nature of the application will require a specific SDLC.
When purchasing a package, I recommend using more of a waterfall SDLC as you need to define your requirements to accurately assess the package fit. On a related topic, if the package requires more than 20% customization from its "out of the box" functionality, you should consider a different package or reassess the build versus buy decision.
When you are going to build a custom application you should base your SDLC on an agile approach. This will allow you to start fast, deliver incrementally and react to changing business needs as you go.
Thus, your ALM process should cover all applications in your portfolio with different SDLCs for specific application deployment needs.
Dig Deeper on Topics Archive
Related Q&A from Mike Jones
The world of ALM tooling is always changing to overcome new challenges and better meet the needs of today’s application lifecycle. Here expert Mike ... Continue Reading
Modeling tools are a vital part of the ALM process, but how they integrate with each other varies greatly depending on the tool. Continue Reading
Application security testing tools can sometimes be considered part of the ALM tool set, and sometimes they fall under the category of the security ... Continue Reading