Entries for 'speeditonline'

As part of the Unified Modeling Language, Activity diagrams are often utilized for many software projects. However, a few questions about Activity diagrams linger in the minds of many Business Analysts, such as: Who is really using them? What kind of projects are they being used on? Why are people not using them? How are people using them? Are they providing any benefit?
 

For projects that may well be delivered by Service Oriented Architecture (possibly using Service Oriented Analysis), I would suggest that you may need to consider different or additional ways of documenting your requirements and specifications. The reason for this is that the way you shape your requirements needs to encompass both the holistic nature of SOA, as well as the new terminology and delivery mechanisms.

Business Analysis is a term that covers a wide range of different disciplines, which has grown in scope over the past 10-15 years. BAs can become involved in a variety of different activities, depending on the organisation and the particular project that they are working on – these can range from very technical to very business focused activities.  So if you're working as a Business Analyst, or working with a Business Analyst, what can you expect?
 

Contrary to what you might think, the problem that rulebook management addresses is a relatively simple one. Its solution is relatively simple too. The reason people have a hard time seeing that is because the problem is so big. It’s all around us, everywhere we look – a whole host of trees blinding us to the forest.

“I may not know much about art, but I know what I like”. This famous punch line to a Monty Python sketch about a fictional conversation between a disgruntled Pope and innovative Michelangelo (who wanted extra disciples, multiple messiahs and a kangaroo in his first draft of the Last Supper), can also be seen to satirize our own modern fixation with creativity, feedback and the idea that ‘the customer is always right’.

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

 Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.  Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
 

If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own.  Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.
 

What we have witnessed in the last 25 years is a series of programmes of change failing to achieve their intended outcomes. Customer Care, ISO 9000, TQM, ABC, BPR. All the research and experience show that the latest panacea does no better than its predecessors. Over and over again improvement programmes are thwarted by commonly-known but illusive forces. The problem is labeled as ‘organization culture’, which typically leads to rationalizations like ‘change takes time’, or ‘each programme is an element in the total change programme’.

Rationalizations prevent learning.

This article provides the business analyst an analogy on how process owners manage value chains by monitoring leading and lagging metrics. The article highlights the need for business analysts to provide process owners with these metrics. These metrics provide indications of positive and negative process and business risks. Examples of the traditional risk response types of accept, avoid, mitigate, transfer, exploit, enhance, and share are provided.

The benefits of Agile methods are becoming more obvious and compelling. While the most popular practices were developed and proven in small team environments, the interest and need for using Agile in the enterprise is growing rapidly. That's largely because Agile provides quantifiable, "step-change" improvements in the "big three" software development measures - quality, productivity and morale. Confirming Agile's benefits, hundreds of large enterprises, many with more than 1,000 software developers, are adopting the methodology.

Regarding software architecture, it's interesting to note that it is the "lighter-weight" Agile methods, specifically Scrum and XP, that are seeing the broadest adoption in the enterprise.

Decision tables have long been a successful technique for representing structured logic. Being visual, they circumvent the need for unnatural formal language or grammar. We use them not only to communicate that logic, but also to automate it. They are especially useful for validating the logic’s completeness and consistency.  Yet, this article advocates that this is not enough.
 

Data models and class diagrams are generally created to serve design purposes. If they include verbs at all, they are not vetted against business rules or other forms of operational business communication. Verbalization depends on well-constructed sentences, which in turn puts a premium on verbs. Fact models provide the basis for consistent and unambiguous verbalization, as well as for the design of IT artifacts. It is time to recognize full-fledged human communication as the starting point for anything written about business operations, including but not limited to, business rules and IT requirements.

In virtually every industry in which business analysts find themselves, employers are trying to do more with less. Normally, this means budget and personnel cuts, which are forcing many analysts to also do the work of project managers, prototype designers, and other roles—and often with a smaller budget for software and other analysis tools. In this environment, it may seem challenging for analysts to find ways to cut back even more, but proactively doing so will benefit not only your employer but your projects and your career. Here are a few ideas to research and pitch to your manager for cutting costs as you go about your daily work.