SDLC, Process, and Methodologies

In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here. Over the years, though, people have leapt onto the bandwagons of numerous new software approaches. They all have merits, they all have limitations, and they all need to be applied to appropriate problems.

Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.

A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.

What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

Since when were Business Analysts a one stop shop for all project needs? We are expected to be Superheros; well-rounded BAs as well as Change Managers, Test Analysts, Project Managers and Implementation Managers. The boundaries of these other disciplines is often unclear so this article seeks to explore the activities that fall into business analysis and those that should be undertaken within the other disciplines.

It appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design. Information Driven Design begins with a simple concept...

While others are moving forward introducing new banking products, the Americans find themselves in the role of constantly fighting fires. You cannot move forward until you put your house in order by bringing standard practices and discipline into your work effort. This is what happens when you treat system design as an art form, as opposed to a science.

This article extends design thinking into a process and method that uses a range of common Business Analysis techniques to drive engagement through collaboration. It provides more structure to either side of the creative process to one better frame the domain of concern, and secondly after creativity has produced ideas, to prototype, refine, test and learn. The article also positions this process as a better way to arrive at a business case or pre-project phase, since it provides enormous insights through an engaging discovery process; something that would never occur within a traditional environment into investigation investment feasibility.

In a recent Information Technology discussion group I am involved with, someone posed the question, "What is complexity?" I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design...

 They took a software approach for designing MIDAS as opposed to a system approach. For example, they probably created a data base quickly, then tried to figure how to get data in and out of it. I would suspect the program source code was well written, probably using "Agile" techniques, but the fact remains none of it was designed to work in a concerted manner.

Based on requirements, ASE decomposes a system into its sub-systems (business processes), the procedural work flow for each, and determine what programs are necessary to implement the computer procedures (software specs). To do this, we determined there were three basic types of sub-systems...

...the fact remains, you cannot build anything of substance, be it a system or otherwise, without a methodology. The question then becomes, how to construct a methodology suitable for your company or a given project. To this end, I offer this tutorial on designing methodologies.

People ask me why I seem to be “black and white” on so many issues. Two reasons come to mind: first, I learned early in school that you do not get credit for making a mistake. If this has changed, please let me know. Second, the nature of my work in the information systems world has taught me there are right ways of doing things, as wel...

The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.

This is a complete example of a Business/Systems Analysis Model using UML and including: Use Cases, Activity Diagrams, Context Diagram, and more.

I have had business friends over the years ask me why it seems so difficult and time consuming to upgrade their corporate systems to take advantage of the latest computer technology. In their minds, their systems are relatively simple; the concepts of such things as accounts receivable, accounts payable, inventory, manufacturing, etc. are relatively straight forward. Yet, companies incur millions of dollars in keeping them up-to-date. The question is, "Why?"