Dr. Dobb's Journal - February 2009 - (Page 46)

Disciplined Agility to your analysis, then it really doesn’t matter which one you start with. If you have the people and funding available to you, then you might want to experiment with several packages in parallel, but this runs the risk of increasing the overall project time due to the additional reviews that you’ll need to choose the “perfect” package. Prove It With Working Software In the Unified Process, the primary goal of the Elaboration phase is to prove that the architecture works by having a small team, typically the people who form the core of the development team, build an end-to-end skeleton of the system. You do this by implementing just enough functionality described by the technically most difficult requirements. When it comes to package implementations, the goal is to install the package and do just enough of the technically difficult integration work so as to determine if the package will work within your environ- ment as promised. The skeleton that you build during Elaboration will be fleshed out during Construction. To keep this as agile as possible, remember to do just enough work—Elaboration should take a couple of weeks, not a couple of months or years. If integrating with your existing accounting system is critical, then do just enough work to connect with that system and share important data. Although you may eventually need to share 2000 data elements with that system, you can likely prove that the package integrates well with the system by sharing only 50 elements for now. Don’t worry, you’ll do the work to handle the other 1200 during the Construction phase (with an iterative approach you’ll also discover that you didn’t need as much as you originally thought). Remember that you only need a good gut feel as to whether the package will work, not a detailed comprehensively documented assessment, so strive to only do just enough work during Elaboration. The 50 data elements that you choose will often be driven by their semantics—pick the elements that are crucial to your success as an organization. If the package doesn’t support your data semantics, if you can’t translate between the semantics supported by the package and what you desire, or if you’re unwilling to change the way that you work to support the package then you’ve discovered that the package doesn’t really meet your needs. When this is the case, you’ll need to work with the package that is the next best option on your list, if one is still available. If not then that’s an indication that you either need to give up on the idea or build the system yourself. An important architectural issue that you need to address during Elaboration is to validate the effectiveness of the modification strategies for the package. Do you modify the package’s behavior through configuration files or tables? Do you update specific portions of the source code? Can you update the database schema to add your own data elements? How are vendor updates handled? You’ll have hopefully identified these strategies through your initial analysis during the Inception phase, but now is the time to prove how well the strategies actually work. Agile In the Small Once you’ve made it into the Construction phase you’re very clearly in agile territory. You will prioritize the work that needs to occur to modify the package, each iteration producing working software that implements the highest priority functionality. Because it’s a package the “new working functionality” produced, each iteration is actually existing package functionality that’s been modified to meet your organization’s needs. This may imply actual changes to the package or increased integration with your existing legacy systems—accessing the remaining data elements from your accounting system may occur several hundred times each iteration until the work is complete. Recognize that you’re on a very slippery slope when it comes to package modification because with an iterative approach it’s easy to do “just one more iteration” to get it right. The point is that your product owner must heed Capers Jones’ good advice—if you need 46 Dr. Dobb’s Journal l www.ddj.com l February 2009 http://www.rallydev.com http://www.rallydev.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - February 2009

Dr. Dobb's Journal - February 2009 Contents Friday Night Fish Fry Alia Vox Developer Diaries Conversations Computing in the Clouds Software Development in the Cloud Videos and Oracle Forms 10g Parallel LINQ Decoupling C Header Files Effective Concurrency Disciplined Agility Swaine’s Flames

Dr. Dobb's Journal - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.