Technology As Innovator

Apart from motivationally writing for the web, I have been invited to universities as a motivational speaker to talk about the IT industry and IT occupations with IT students.

What question do you think is most frequently asked?

What programming languages and tools are currently used in your company?

It is not a surprising one because the same question has been asked much more frequently on technical forums and newsgroup and has caused so much debates on T-tool vs. U-tool and more heatedly, X-language vs. Y-language.

And my answer is

“It is nice that you are preparing the knowledge and skills that you think your potential employers will seek. However, skills and experience in a particular programming language is not the only technical skill employers seek in candidates. They’re also looking into the foundation technical knowledge, such as but not limited to: Object Orientation, Design skills, Software Methodologies, Data Structures and Algorithms, Database Design, Architecture, Computing Theory, that empower your programming skills. You may do programming with, let’s say, Java relatively well in some situations without the above knowledge, but if you are thrown into a more complex project to build a huge product, the risk is high.

One example. You spend two to four years in college polishing your skills in X language that you predict will (still) be hot in a few years when you graduate. When you do graduate and apply for jobs, if they say “Sorry, X is old. We’re needing Y people”, what will you do? Spend the same amount of time learning Y? No, it’s not the way it should work. Foundation knowledge is the root, languages and tools are leaves. Equip yourself with the foundation, and when technology changes (is IT a slow changing area that does not change every 6 month or so?), you can adapt more easily.

When you have mastered the foundation knowledge, and possessed significant experience in using programming languages, which IDE is not a bug big issue.

Besides, about recruitment, technical skills are not the only evaluation criterion. Think about soft skills and attitude too.”

I was thinking about my profession

The number of Business Analysts and System Analysts required in software companies is not that many compared to developers; in some smaller companies with less formal process definition, some developers take the Analyst role. If the need for Analysts were higher, this question could have been asked: “What modeling languages and tools are currently used in your company?”

The answer is simple: Unified Modeling Language. UML itself has been a well-established language for modeling. More of a reason why it has become so popular is due to the promotion of UML by RUP.

But once again, UML is a language. The case is not much different from that of programming languages. Knowing UML is not enough to perform all tasks Analysts do, Business Process Modeling for instance - and a new standardized set of notations named BPMN (Business Process Modeling Notation) is being proposed.

Underlying UML skills are Modeling skills. Modeling languages are used to present information in a more visual (and structural?) way. You need to know what model or diagram should be used to present what kind of information at what time in what situation to whom.

Model is one kind of information. In order to develop solid Modeling skills, Information Processing skills and Data Analysis skills need to be developed first or in parallel.

With all those skills at hand, you will be able to guess how shapes are categorized and may quickly locate the right notations you need in Modeling tools, no matter if it’s Rational Rose or Visio or Enterprise Architect or so on.

After you have created a good piece of model, you may want to present it to customers or other teams in your project. Presentation skills may help.

Side discussion: Model vs. Diagram

Throughout this article, I have used Models consistently, without mentioning diagrams. The may raise question since “UML diagram” is a very common terminology. The reason is because Analysts produce visualizations which are not diagrams too. Organization charts, map, prototype are just a few to name. ‘Model’ covers all of these, of course including diagrams. Also, one trivia is that the word may remind the fact that information systems actually model the real world.

Conclusion

So to conclude, foundation knowledge is required in any profession. Technology and tools change so quickly, but concepts do not as quickly. Build your internal strength should be the higher priority.

1. Include

a.k.a Uses

When to use

When several Use Cases need to complete the same sequence of actions.

Example: To be able to Manage Contents, or Manage Photos, actor must Login to the system. The Login should be a separate Use Case; other Use Cases includes Use Case Login.

Advantages

• Re-usability: Document once and reuse
• Consistent behaviors across the system

Notes

A Use Case that includes other Use Cases is not complete if the Use Cases that are included cannot be executed.

Notation

Dashed arrow from the including Use Cases to the included Use Case, with the label «include»

2. Extend

When to use

When an extending Use Case continues the behavior of a base Use Case. The extending Use Case adds more action sequences into the base Use Case’s sequence.

When the sequence of actions in one alternative flow of a Use Case is too complicated, it should be put in a separate Use Case extending the existing Use Case.

How it works

The flow executes the extending Use Case actions when 2 conditions are satisfied:

1. Appropriate Extension Point in base Use Case is reached
2. Extension condition is fulfilled

When the extending Use Case activity sequence is completed, the base Use Case continues.

Advantages

Cohesion: Avoid over-complexity of one Use Case

Notes

The base Use Case is complete without the extending Use Case.

The extending Use Case can only be executed from an Extension Point in base Use Case.

Notation

Dashed arrow from the extending Use Cases to the extended Use Case, with the label «extend»

3. Generalization

a.k.a Use Case Inheritance

When to use

The inheriting Use Case replaces a portion of actions, conditions and rules of the inherited Use Case. The actions to be replaced are rewritten; actions not rewritten are executed as in inherited Use Case.

Advantages

Re-usability of actions that do not require re-writing.

Notation

Solid line ending in a hollow triangle from the inheriting Use Cases to the inherited Use Case.

Illustration

Manage Websites and Manage Contents are abstract Use Cases

Relationship between Manage Websites and Manage Enterprise Websites is Generalization: Manage Enterprise Websites inherits Manage Websites

Relationship between Manage Blogs and Manage Blog Contents is Include: Manage Blogs includes Manage Blog Contents

Relationship between Login and Manage Forgotten Passwords is Extend: Manage Forgotten Passwords extends Login

Problem defined

Managing thousands of artifacts within the requirement phase alone in a project is not an easy task.

Solution

Automation have been provided by these popular software packs

• Documenting Use Cases and documents: Microsoft Word already gives all we need.
• Artifact Repository: Thousands of ways and tools satisfy this purpose. I’d suggest Microsoft SourceSafe and Microsoft SharePoint server.
• Diagram authoring: Rational Rose and Microsoft Visio do better.
• Version control: Many CVS tools are already out there.
• Project Planning: Microsoft Project rocks! Agile’s Product Backlog is also a good tool.

Single Solution

Single solution that addresses most, if not all, issues - a professional Requirement Management Tool that enables the following factors

• Traceability: The efforts spent in wiki(traceability) are greatly reduced. Hence, productivity and team moral are boost.
• Consistency: In a team of nearly twenty people, it might come out that different artifacts owned by different authors vary slightly in styles, indents, numbering. A tool helps to reduce this factor.
• Requirement linking: Reference to other documents, dependencies, extensions are handled in the form of URL links.
• Use Case-to-diagram generation: Many tools allow users to create flow charts from Use Cases

TopTeam Analyst

I recommend this tool: TopTeam Analyst

Demo screenshots

Vendor: technosolutions

TopTeam Analyst is wiki(RUP)-compliant

There are many more requirement management tools, but the reason I am attracted by TopTeam Analyst is that the product is compliant with standards from Rational Unified Process, which I’m am currently working with.