Thoughts on the code from the frontal lobe
My take on software engineering. Y'know?
Wednesday 4 June 2008, 7:50 PM
Finding the rationale behind IBM Rational: notes from the classrooms
To kick off my learning objectives while attending the IBM's 2008 Rational Software Developer Conference, I decided to approach the session offerings in the same fashion as I would if I were going to develop a system. As such, I started my day by attending the Requirements and Analysis (RA01) session.
After all, shouldn’t all system development start with requirements analysis?
From this session, I gathered that IBM engineers are pretty much focused on addressing many of the requirement analysis issues that have been haunting me. One challenge that I have been contending with in my recent experience is how to best convey system requirements to my customer.
Reconciling this issue has been rather challenging as customers don’t generally want to spend the time to review the massive amount of text (i.e. “The system shall…”) that is found in the typical requirements document. Likewise, customers don’t generally understand UML so simply showing them UML diagrams may not necessarily solve the problem either.
To assist with these issues, the IBM engineers suggested several options including incorporating Storyboards, Simulations, and Model Business Processes which can all be integrated into your IBM' Rational RequisitePro requirement management tool.
Speaking of RequisitePro, IBM also mentioned that a new beta release of RequisitePro will be available shortly. Along with ReqWeb enhancements and the integration of an open source reporting option, in this release, we are going to be blessed with enhanced security at the package and view levels.
Having worked as a government contractor in cleared environments for years, this enhancement has numerous beneficial implications. As you might imagine, being able to create views for various levels of sensitive compartmental information securely can provide requirement analysis opportunities for engineers according to varies rules, roles and clearance levels. To date, in my experience, if an engineer does not have the all clearance credentials at the highest level of the system, the engineer is forbidden to work on any component of the system.
Other interesting requirement related news coming from this session was that the IBM engineers are committed to supporting and continuing the development of their recently acquired Telelogic DOORS. In fact, along with the Rational RequisitePro, IBM engineers are working toward the eventual integration of DOORS into the Jazz collaboration platform. This is good news because when it comes to requirement analysis “One size does not fit all.” The rationale behind Rational’s commitment is that DOORS is well suited for large scale projects with government compliance while RequisitePro maintains its lead with IT compliance. Good news for all, don’t you think?
Moving on with my sessions, I decided to broaden my base knowledge in Use Cases by attending the Use Case for Complex Applications and Systems-of-Systems (BPM02) course. As I’ve worked on extremely complex signal processing programs, I was eager to gain insight into how to develop more effective Use Cases.
First, the IBM instructor outlined the huge distinction between a Process and Use Case. I’m sure I’ve confused these technical terms before. It was noted that Process is not a cause and effect relationship; moreover, it is a fallacy (post hoc ergo propter hoc) to assume that it does. The example of this fallacy given was the common notion that lightning causes thunder. This notion is in fact incorrect as, although thunder may be correlated to lightning, thunder is actually caused by the movement of air due to the temperature differences causing vibrations in the air, hence causing the noise. Consequently, the IBM instructor simply defined a “Process” as a set of actions.
Image source: Morguefile
On the other hand, a Use Case was described as a complete usage of a system. The purpose of the Use Case is to represent the real goals of the user. The simple example given was a “Drive to work” Use Case. Driving to work can be decomposed into operations such as “Start your car”, “Step on the gas”, “Turn the steering wheel” etc. however, the complete usage and real goal of the user is to drive to work.
All the activities that are performed to achieve the real goal of the user are actually Operations of the “Drive to work” Use Case. These Operations, however, can become Use Cases for Systems-of-Systems or lower level Use Cases. This process of decomposing was defined as Recursive Modeling.
So how far do you decompose? Well, until you have an independent unit that you can build from. For me, the Base Case in Recursive Programming comes to mind. Of course, I was always told that using recursion was a bad; nevertheless, I suspect recursion has its place here.
After all, shouldn’t all system development start with requirements analysis?
From this session, I gathered that IBM engineers are pretty much focused on addressing many of the requirement analysis issues that have been haunting me. One challenge that I have been contending with in my recent experience is how to best convey system requirements to my customer.
Reconciling this issue has been rather challenging as customers don’t generally want to spend the time to review the massive amount of text (i.e. “The system shall…”) that is found in the typical requirements document. Likewise, customers don’t generally understand UML so simply showing them UML diagrams may not necessarily solve the problem either.
To assist with these issues, the IBM engineers suggested several options including incorporating Storyboards, Simulations, and Model Business Processes which can all be integrated into your IBM' Rational RequisitePro requirement management tool.
Speaking of RequisitePro, IBM also mentioned that a new beta release of RequisitePro will be available shortly. Along with ReqWeb enhancements and the integration of an open source reporting option, in this release, we are going to be blessed with enhanced security at the package and view levels.
Having worked as a government contractor in cleared environments for years, this enhancement has numerous beneficial implications. As you might imagine, being able to create views for various levels of sensitive compartmental information securely can provide requirement analysis opportunities for engineers according to varies rules, roles and clearance levels. To date, in my experience, if an engineer does not have the all clearance credentials at the highest level of the system, the engineer is forbidden to work on any component of the system.
Other interesting requirement related news coming from this session was that the IBM engineers are committed to supporting and continuing the development of their recently acquired Telelogic DOORS. In fact, along with the Rational RequisitePro, IBM engineers are working toward the eventual integration of DOORS into the Jazz collaboration platform. This is good news because when it comes to requirement analysis “One size does not fit all.” The rationale behind Rational’s commitment is that DOORS is well suited for large scale projects with government compliance while RequisitePro maintains its lead with IT compliance. Good news for all, don’t you think?
Moving on with my sessions, I decided to broaden my base knowledge in Use Cases by attending the Use Case for Complex Applications and Systems-of-Systems (BPM02) course. As I’ve worked on extremely complex signal processing programs, I was eager to gain insight into how to develop more effective Use Cases.
First, the IBM instructor outlined the huge distinction between a Process and Use Case. I’m sure I’ve confused these technical terms before. It was noted that Process is not a cause and effect relationship; moreover, it is a fallacy (post hoc ergo propter hoc) to assume that it does. The example of this fallacy given was the common notion that lightning causes thunder. This notion is in fact incorrect as, although thunder may be correlated to lightning, thunder is actually caused by the movement of air due to the temperature differences causing vibrations in the air, hence causing the noise. Consequently, the IBM instructor simply defined a “Process” as a set of actions.
Image source: Morguefile
On the other hand, a Use Case was described as a complete usage of a system. The purpose of the Use Case is to represent the real goals of the user. The simple example given was a “Drive to work” Use Case. Driving to work can be decomposed into operations such as “Start your car”, “Step on the gas”, “Turn the steering wheel” etc. however, the complete usage and real goal of the user is to drive to work.
All the activities that are performed to achieve the real goal of the user are actually Operations of the “Drive to work” Use Case. These Operations, however, can become Use Cases for Systems-of-Systems or lower level Use Cases. This process of decomposing was defined as Recursive Modeling.
So how far do you decompose? Well, until you have an independent unit that you can build from. For me, the Base Case in Recursive Programming comes to mind. Of course, I was always told that using recursion was a bad; nevertheless, I suspect recursion has its place here.
