Requires Free Membership to View
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.
This was first published in November 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation