One of the biggest challenges in any system design effort is to produce a viable system design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.
In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:
Author: Tim Bryce
“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended. Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.
Author: David Wright
The short answer: "Because it requires work."
The long answer: People tend to resist gazing into the crystal ball and prefer to react to life as it passes them by. Some people believe planning in today's ever changing world is a waste of time, that you must be more "agile" and accommodate changes as they occur. As anyone who has designed and built anything of substance knows, this is utterly ridiculous. We would not have the many great skyscrapers, bridges, dams, highways, ships, planes, and other sophisticated equipment without the efforts of architects and engineers. Without such planning, our country would look essentially no different than how the pioneers first discovered the continent. Although we must certainly be flexible in our plans, and we will inevitably make some mistakes along the way, little progress would be made if we did not try to plan a course of action and control our destiny.
People often take planning for granted, that someone else will be making plans for us, such as government officials, our corporate management, or even the elders of our families. Consequently we become rather lax about looking into the future. Nor is there any encouragement by anyone to plan our affairs, such as a tax break. Whereas other countries offer incentives to save money for the future, such as Japan, America does not. Therefore, planning is a rather personal activity; we either see the virtue in doing so or we do not.
As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.
So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.
The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.
In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices
Standardization offers the benefits of uniformity, predictability, interchangeability, and harmony. If this is not of interest to you, than there is little point in trying to participate in a standards program. But if you do wish to participate, understand there is more to implementing standards than to just say "that's just how it is going to be done." There has to be some sound rationale for their governance. In addition, you must address the enforcement issue. Standards will be adhered to by the degree of discipline instilled in the staff; If well disciplined, your chances for success are good, but if discipline is lax, automation is required to assure standards are being followed.
Did you know that you could make a positive impact in people’s lives by working as a Business Analyst (BA)? By describing data flows, writing use cases, creating diagrams, re-engineering current processes or mapping the system’s data outputs and inputs, you could make a change in somebody’s life. As impossible as it sounds, it is happening on a daily basis. Throughout the US the Business Analysts in the Healthcare industry work hand in hand with the Healthcare professionals in the hospitals, the insurance companies, the government, as well as regulatory and non-profit agencies and organizations to make the US Healthcare better.
According to the MS Encarta Dictionary, healthcare is defined as the “activities to maintain health; the provision of medical and related services, aimed at maintaining good health, especially through the prevention and treatment of disease.” The healthcare industry also includes the people performing these activities, their skills, and the tools and systems they use daily. The modern health care depends on an ever growing interdisciplinary team of professionals; and this includes the Business Analysts.
The Business Analysts in the Healthcare Industry are exploring many business processes, multiple use cases and alternative flows at every point of contact where the patient interfaces with the healthcare professionals. At the same time there are various software and hardware systems interacting with each other and a multitude of standards regulating every aspect of the data exchange. When you add the different vendors, the variety may become overwhelming.
I was recently asked by an "Agile" proponent if I thought our "PRIDE" methodologies were too rigid for today's fast-paced Information Technology world, that perhaps it was too bureaucratic. First, I pointed out that "PRIDE" was more of a way of thinking as opposed to anything else. You can remove all of the documentation associated with the methodologies, including the forms, and still produce a system for example. This took him aback somewhat as he had thought of "PRIDE" as an inflexible paper mill...
Discusses the implementation of a robust Systems Design Methodology.
The pointy haired manager in Scott Adams' "Dilbert" cartoon has become an icon for management incompetence. Although Adams' character may seem like an extreme, we have all encountered various examples of the Peter Principle whereby people have risen above their level of competency. We see this not only in our companies, but also in the nonprofit organizations we are involved in. Basically, these are some very nice people who simply haven't a clue as to what they are doing and stumble through each day making bad decisions which drives their subordinates to madness.
brought to you by enabling practitioners & organizations to achieve their goals using: