Minimize IT Risk

iTKO LISA Journal

Subscribe to iTKO LISA Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get iTKO LISA Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

iTKO LISA Journal Authors: Elizabeth White, Salvatore Genovese, Pat Romanski, Maureen O'Gara, Andreas Grabner

Related Topics: iTKO LISA Journal, SOA Best Practices Digest, SOA & WOA Magazine, SOA in the Cloud Expo

iTKO LISA Journal: RSS Feed Item

Agile SOA Across the Lifecycle with LISA - Part Three: Application Lifecycle Management

This is the third of a six part series of posts on how SOA is becoming merged with the Agile life cycle. Here we will at look at Application Lifecycle Management (ALM). As Forrester???s Cary Schwaber writes, the newest ALM platforms will improve the development process by providing common services to practitioner tools.  This current generation of ALM software is doing even more to tie requirements, test cases, bug tracking and issue resolution together in one application suite. You can see a simple illustration of this cycle of sharing Tests as collaborative assets below. The process of converting business requirements into software is being automated through ALM tools, by tracking completion of coding and storing source code, execution of test cases to ensure functionality, and documenting product bugs and enhancements for development to prioritize.  Automated testing has been traditionally plugged only into the ???test execution??? phase of ALM. This provided statistics on code coverage or relaying the success or failure of a build. However, stronger testing can add value at every stage of the lifecycle managed in ALM tools. For instance, developers can check in tests alongside their source code in the ALM???s repository, as simplistic ???happy path??? tests that demonstrate the intended functionality of the delivered component. Then, QA teams can be alerted to these new assets, and run and iterate on those tests to prove out a larger set of possible activities. Still another team can use all the tests from Dev and QA in the process of integration and deployment, tying multiple tests together to ensure that the overall regression and functional coverage is high with less effort. Finally, as the business team and Support teams get involved, they can run, modify and check in tests to the platform to signify issues or define requirements for the next phases of the ALM lifecycle. When shared in this way, tests become collaborative assets for SOA, and increase the agility and speed of each iteration cycle, while better ensuring the success of end-to-end business processes. This practice can be employed with any testing tool, whether you are coding JUnit or using a more automated, no-code testing tool. The advantage of using a no-code testing environment, that automates the execution of tests without requiring coding skills, is it allows non-developers to get involved in the cycle above. Of course, our LISA provides a very robust way for developers, QA/QE, business analyst and support participants to get involved in the Agile SOA lifecycle. LISA tests are easily stored and shared within ALM repositories as XML files, and they are executable from the command line or JUnit of a build script, as a double-click from the ALM interface, or automated as part of a check-in or validation cycle for each deliverable. The LISA test then passes back the results to fail the build or update the status in the ALM system. Integration of LISA to ALM and related SCM (Source Code Management) and RM (Requirements Management) tools from vendors such as MKS, Borland, Rational/IBM, Compuware, and others, allows tests to help teams achieve the predictable delivery timelines and quality they expect, while using they process tools they are most comfortable with. As shown in the above example, everyone should be involved in contributing and executing tests as each iteration at the component level is introduced, and these tests are rolled up into a broader workflow and business process. An Agile organization allows both developers and non-developers, in multiple teams, to collaborate on contributing testing components into the application long before the end of development. This ensures continuous testing at each iteration cycle and a more reliable course correction and release process. For instance an Insurance company may have a requirement to match the Zip code with a certain type of auto policy coverage. The developer creates a component and checks it in, along with a simple test case that shows a few matches of Zip and coverage. The QA team can then iterate on that test with a dataset of all needed Zip/coverage matches, and make that test a requirement for each successive build. If the developer later updates the component and the required LISA test doesn???t pass, it reports it to the ALM system with the root cause analysis, and the build is failed and communicated back to the relevant teams for correction, according to the issue resolution rules of the ALM system. For more on ALM, we recently found a nice report at BusinessWeek???s technology Research Library on Application Life-Cycle Management. In our next post, we will look at IT operations, monitoring and performance. You can download this complete series at our ITKO LISA resources page. 

Read the original blog entry...