Posts Tagged ‘Modeling’

h1

Perfect Questions?

November 29, 2010

During a recent discussion I was having with a colleague who is an Agile Coach and Business Analyst, I asked her what the BA community was interested in regarding the practice of business analysis. Her answer surprised me. She said what many BAs want is the perfect list of questions to ask their clients. The perfect list of questions? Really? Who has that? For all situations?

Instead of the perfect list, how about a relevant list? How could that be created? What if you had a guide that could help you see what to ask? You do. Read More…

Advertisements
h1

Simplify the UML?

November 18, 2010

I am continually amazed at the serendipity of events that occurs everyday. A short time ago I was having lunch with an industry insider when he mentioned the beginnings of a movement to simplify the UML. Having read the 700+ page UML specification a number of times (Sadistic, isn’t it?) it immediately struck me as a good idea. While software modeling is an “acknowledged” technique, it still is not a “standard” practice on most software projects. From the common, repeating questions that I have been asked over the years, many people still struggle with how to do it well. Modeling has a way to go to become truly mainstream. So a simpler UML sounded like a fine idea. But…Read More.

h1

The UML’s Double-Edged Sword

July 9, 2010

The sword is one of the most ubiquitous crafted weapons across civilizations worldwide. They come in many different shapes, sizes, and materials. An attribute that they all have in common is a sharp edge. Some multiply their offensive capability by being sharpened on both edges, i.e., the double-edged sword. These are more deadly because they can “cut both ways”. Who would have expected that the innocent use case would introduce a double-edged sword into the UML? Read more at DevX.com…

h1

Come One, Come All!

June 1, 2010

If you’d like to enjoy some fun in the sun AND learn about pragmatic modeling techniques (those two things always go together, right?), then you are in luck. For the 11th year in a row, I have the privilege to be speaking at the IBM Rational Innovate 2010 conference (previously know as the Rational Software Development Conference and the Rational Users Conference).
On Wed. June 9th, 2010 I’ll be presenting “Practical Visual Modeling – Lessons From the Trenches”. Beginning and experienced modelers often wonder why modeling isn’t working well for them. This is because there are many snares and traps to fall into. This presentation, based on lessons learned from real-world projects, approaches visual modeling pragmatically. Visual modeling essentials are discussed augmented with practical, experiential advice, best practices, and heuristics for modelers. Common project failure points, SOA, agility, how to avoid typical modeling pitfalls, and simple risk-based planning techniques are just some of the topics covered.
We will discuss:
• Where the most costly and common project mistakes are made
• What parts of the UML to use and which to ignore
• Business modeling and system modeling via use cases and how to use them
• Avoiding common modeling pitfalls during analysis and design
• Project planning, prioritization, and risk
• Career shortening red flags that indicate when you should get out of Dodge.
• Numerous practical modeling techniques and practices.
So if you are going to be in the Orlando area for the conference, please drop into my session, say hello, sit back, and have some fun!

h1

What’s Really Going On With Modeling?

April 27, 2010

UML has been on the market well over a decade.  Visual modeling in general has been around much longer.   Some contend that modeling is now mainstream and pervasive in software development.  Is it really?  What do you say?

This survey asks 3 simple questions that will provide important insights. I will post the results for you when the survey is complete.  Tell us what you have seen.

h1

Fun With Frames and the User Experience Model

April 12, 2010

Development teams don’t necessarily receive “requirements” from their stakeholders as use cases, textual requirements, user stories, or even “drive-by requirements” (where the stakeholder throws a yellow sticky note – that contains their latest requirement – over your cubicle wall as they walk down the hallway). And sometimes the end users (an important stakeholder) are so focused around the user interface of the system, that suggesting changes to their user interface is the only way they know how to express their needs.

The advice you commonly hear regarding using the UML© for user interface modeling ranges from “don’t do it” to (at best) “create a User Experience (UX) model”. The UX model as traditionally described is good for simple situations, but with the advent of more modern, complex UI presentation options, the traditional UX model’s utility begins to reach its limit quickly.

I was pleased to find an elegant answer available in a little used area of the UML© that does not get delved into deeply very often…Read more

h1

A Fool With a Tool…

February 25, 2010

So often, the development teams I coach on modeling ask “What free UML tools are out there?” As you probably know, there are quite a few now. But the problem with asking that question is these teams often have already purchased a modeling tool! Why don’t they ask earlier?

Many times the people who will be the end users of the tools are not (or just marginally) involved in tool selection. Some process or tool group is often commissioned to survey available tools, assess their applicability, and recommend what should be purchased. The tools are purchased, deployed, and then the end users find out that the tools don’t quite fit the manner in which the team actually works. This is a classic problem with a “tools first” approach to process improvement. Tools must support the way you work, not force you to work their way.

I was a member of such a tool committee at a company that was consensus driven in the extreme. We were directed to gather every possible stakeholders’ ideas on what criteria should be used to evaluate the tools. We ended up with a matrix of 123 different criteria. Did the people who would actually use the tools regularly use 123 different tool capabilities? Of course not. When the actual decision was made, after struggling through weeks of gathering, clarification and prioritization of all these decision criteria, the final decision came down to only 3 core criteria. It would have been a more pragmatic activity and much time would have been saved if we had known those 3 key criteria at the start.

But if modeling is new to your environment how would you know what you need? You may not have yet established how you are going to work with modeling. How about trying your new modeling practice with some of the open source (often free) tools? In this way you can easily and inexpensively discover what you really need in a tool for the level of modeling you intend to do. Not everyone does full Model-Driven Development. You may need only some simple diagramming capability. Maybe you won’t need that expensive gold-plated modeling tool. Every development team / organization is different. You may discover that a more modest tool may be sufficient to support your way of working.

If you want to read a nice survey of open source modeling tools read more at http://bit.ly/ll4UY.