Wednesday, June 19, 2002

RUP Forum: Feedback For Business Analysts I've just recently subscribed to this forum and there is a really interesting thread on how Business Analysts get feedback on the job they are doing (lots of reviews). It has morphed into a discussion about the skill sets that Business Analysts (BAs) need. Very interesting. For instance, on the subject of whether or not domain expertise is necessary for BAs... "Strictly speaking, these are unnecessary. The analyst should ideally have unlimited access to domain experts, and should be able to elicit any information needed. However, there are a few caveats. Domain experts tend to be busy, their time is valuable. Some employers try and short-cut the knowledge transfer by demanding that the BA already has domain expertise. This approach can lead to problems, e.g. where opinions differ, but the differences aren't detected. Where the BA doesn't know the domain, there is a risk of incomplete comprehension." The very uninteresting and ridiculous part of the RUP Forum is that there is no way to view the forum postings in real time. How stupid. The only way to get realtime updates is to subscribe to the forum, then you see them by email. What you can see from the website is only the latest (and not most up to date) compilation of postings month-to-date. This would be more of a drag if the discussion on what I need to do my current job wasn't so timely. comment []  4:09:03 PM

ModelingStyle.info: UML Use Case Diagramming Guidelines There are lots of good new and reminder points on these pages: "Place Your Primary Use Cases [and Actors] In The Top-Left Corner Of The Diagram." "Imply Timing Considerations By Stacking Use Cases." "Although actors interact with your system by definition they are outside your scope of control, something that you can communicate by drawing them on the outside edges of a use-case diagram." "Actors Model Roles, Not Positions. A common mistake that people new to use case modeling will make is to use the names of positions that people hold instead of the roles that the people fulfill when they are naming their actors. A good indication that you are modeling positions instead of roles is a use case diagram depicting several actors with similar names that have associations to the same use case(s)." "Use <> to Indicate System Actors." There refer to actors that are systems, such as when some output from a use case is benefiting a system outside of your scope, like the HR system. "Actors Don’t Interact With One Another. Although actors may in fact interact with one another in the real world this information isn’t something that is depicted on use case diagrams – you’ll never draw an association line between two actors (generalization relationships, which are allowed between actors, do not imply interaction)." "...if your system needs to support such an event you need a way to model that. In Figure 2 you see that an actor called Time initiates the Submit Taxes use case because it is something that occurs on a periodic basis (typically monthly)." "Avoid Arrowheads On Actor-Use Case Relationships. the problem is that many people confuse these arrowheads to imply information/data flow, as you would see in a data flow diagram (Gane and Sarson 1979; Ambler 1998), instead of initial invocation." This 'initial invocation' things was news to me (although I'm by no means an expert). "Indicate Release Scope with a System Boundary Box." This is pretty key to indicating to viewers of your diagrams the release sequence of the application. comment []  2:36:47 PM

Welcome to the OCL Center "The Object Constraint Language (OCL) is a notational language for analysis and design of software systems. It is a subset of the industry standard Unified Modeling Language that allows software developers to write constraints and queries over object models. These constraints are particularly useful, as they allow a developer to create a highly specific set of rules that governs the aspect of an individual object. As many software projects today require unique and complex rules that are written specifically for business models, OCL is fast becoming an integral facet of object development." OCL is something that might be used to augment how requirements are specified in Use Cases and SRS'. Don't know anything about it and probably should. comment []  2:14:01 PM

Scott Ambler: Agile Analysis Modeling: Rethinking The Role of Business Analyst "Fundamentally the role of business analysts was always to improve the communication between developers and project stakeholders. In many “traditional” organizations that meant that business analysts formed a bridge between the two groups, a definite improvement in many situations, although at the same time erected barriers. Now is the time to take the next step, to become more agile and have business analysts become the communication mentors/coaches on project teams. [Emphasis added by VO]" In our newly formed Analyst Group, we've been talking much more about the "traditional" role, so it's interesting at this point to hear about taking it to a next level. Mentors in helping developers and business experts communicate. Not just playing the role of the communicator. He also talks about the ideal situation of having co-located development teams and stakeholders... "In this situation an agile business analyst should be just another one of the developers on the team, likely leading requirements and analysis modeling efforts as needed. They would actively work to facilitate communication within the team, mentoring developers in business analyst skills and perhaps even mentor project stakeholders in development skills." comment []  1:39:06 PM

ModelingStyle.info "The focus of this web site is style. That's it. It presents guidelines to improve the quality and readability of your software diagrams, making them easier to understand and to work with. Included are guidelines for applying various modeling notations effectively, such as when to apply aggregation between two classes instead of association, but excluded are design patterns such as Strategy or Facade. Note that the primary focus of this site, at least at first, will be the UML, the industry standard for modeling systems using object-oriented and component-based systems." This looks like an interesting site, especially if you are looking to do or improve your software diagrams. I will be going through this site a lot, since I'm very interested in being able to draw models, in UML, of system requirements and processes. comment []  9:59:11 AM