Tying Process to Tools and vice-versa
timhahn 100000F0AC Visits (1421)
I have spent the day today educating myself on IBM's Service Oriented Model and Architecture (SOMA) method. Why, you may ask. Well, as I look across the Rational product portfolio, we have a bevy of product offerings that are available for teams to use. These products are jam-packed with features and capabilities. So jam-packed, in fact, that the tools can be overwhelming at times.
One way to provide focus for architects, project managers, application developers, and test teams is to have them follow a well thought out process, using tools such as the Rational tools to support their work.
So, as part of my desire to help teams a) get started and b) stay engaged and on task, I find myself interested in how best to show the Rational tools being used at various stages of a application development process such as SOMA. Teams following a SOMA method will have clearly articulated tasks to accomplish, and my hope is to show the Rational tools (a combination of Rational Team Concert, Rational modeling tools, Rational requirements tools, Rational application development IDEs, and Rational Testing tools) being used in each of these tasks.
I have seen that alignment has been done in the past between SOMA and the Rational Unified Process (RUP). This was a good start and was appropriate at the time that the work was completed. However, times have changed and both development processes and product portfolios have evolved since that work was completed several years ago. It appears that it is time to re-assess SOMA and the Rational tool-suite to show how both complement and support one another.