Mapping the SDLC and BABOK to A Simulationist's Framework for Business Analysis

R.P. Churchill

Learning Objectives

Important Contextual Note

The context for most business analysis work is the development and modification of software systems (and the hardware and environments needed to host them).

Watermark explicitly states that all of their practice test questions should be understood in that context.

The SDLC framework is obviously about software.

HOWEVER, I tend to think of my engagement framework in more general terms, and the phases can be worked through to create, modify, and improve any kind of system, process, or product.

Important Contextual Note 2

It is EXTREMELY important to understand the structure of an engagement before beginning one.

This involves being aware of and provisioning for every activity that needs to be completed for a successful effort.

Participants in different roles will be concerned with different things, but all must be able to work together in a shared context.

Participants never want to be surprised that something needs to be done. The design and implementation phases will generate all the surprises anyone needs. Don't let surprises happen during the engagement management process.

Working Together Means Having Conversations

• Work is rarely completed successfully on the first try.
• You should think of (any kind of) work as a conversation where the back-and-forth continues until all parties understand and agree...
• ...ideally, sometimes you need to cut things off and move forward.
• You can often revisit conversations when more is learned or conditions change.
• I represent a conversation as a loop with a standard entry and exit shown moving left to right at the bottom. This shows the normal flow of work moving forward.
• An additional entry and exit are shown at the top, moving backward from right to left. This illustrates the capability of revisiting prior work to make additions, deletions, or modifications.

Process vs. Solution vs. Engagement vs. Environment

Where Do We Start?

35 Years of Simulation

35 Years of Simulation

Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.

Here Is Our "Somewhere"

For this initial discussion, we're going to talk about the process of building a simulation of a system that already exists.

The existing system is a process consisting of multiple steps (think of a flowchart, possibly with branches), and not a single entity.

Who Is Going To Be Involved?

The process I describe can be done alone, but most work of any scale will involve groups.

Working with multiple people and groups involves communication — and empathy.

Define terms. Learn how to speak each other's language.

Understand that you won't get it right the first time. Listen, document, review, correct. Repeat this process until all parties reach agreement.

Analysis and solution happen within a managed environment of limited resources. Understand the context and how to generate the best results.

1. Figure Out What You Want the Simulation To Do

There are many reasons to write and run simulations. I listed some industries and applications on an earlier page.

Simulations have to provide some kind of value, or else there is no reason to build them.

The simulation has to be accurate enough to be meaningful. Remember that all simulations are wrong; some are useful.

The use(s) of the simulation may be expanded, limited, or otherwise modified as more is learned through the process.

2. Understand the Thing You're Going to Simulate

3. Identify What the Stakeholders, Users, and Solution Need

The organization has needs, customers have needs, users have needs, and designers and analysts have needs.

The solution may have needs of its own. We may learn about those needs at any point in the process, but the earlier we know, the easier it will likely be to make allowances.

We need to understand the difference between what the solution DOES and what the solution IS. The latter describe qualities the solution should have. For example, two solutions may generate the same answer, but the one that is simpler to use, runs faster, requires less maintenance, and is easier to modify will be preferred.

Define the criteria by which the requirements are agreed to be met.

4. Generate Possible Solutions and Pick the Best

The solution should simulate everything that the existing system does — unless all parties agree that things can be omitted or simplified.

There are many (very good) reasons to make assumptions and simplifications, but they should all be understood, agreed to, and documented. The risks and impacts should also be understood.

There are many ways to evaluate and rank solutions. They may differ based on the organization and application.

A classic way to compare solutions is by the net present value they provide after cost-benefit analyses are performed.

However, not all criteria can be reduced to monetary figures, and all organizations are not bound by the same incentives.

The full solution package should consider construction, operation, deployment, training, maintenance, and more.

5. Build and Deploy the Solution

Solutions should generally be as simple as possible — but no simpler. Remove complexity whenever possible, but retain all required functionality. Avoid adding features that aren't needed out of a sense of "completeness" or because they're "cool."

Solutions may need to be implemented in phases.

Training, documentation, and ongoing management and maintenance are part of the solution.

I generally strive to make solutions as standardized and modular as possible. That said, it takes time to learn how to do that.

Initial solutions in a problem space tend to be custom, expensive, and brittle. They become standardized, cheaper, and more robust over time. Think cars!

6. Test and Accept(?) the Solution

EVERY aspect of a solution should be tested, alone and in combination.

Testing should be planned for from the beginning (as much as possible).

Solutions should be evaluated on how they work — and how they address the stated problem.

Tests should meet defined standards that give pass/fail answers (as much as possible). Different kinds of tests are more amenable to this than others (Think TQM. What are the exceptions?).

Consider the entire solution process from the point of view of the tests it will have to pass (think Test-Driven Development - TDD).

Remember, the market provides the most important — and stringent — test of all. The best solution doesn't always win.

Let's Summarize:

1. Define the problem
2. Figure out what's going on now
3. Identify what everyone needs
4. Propose, develop, and select a design
5. Build the solution
6. Test it

Do That Work in a Project Management Wrapper

• Provision and launch project
• Define the problem
• Plan and monitor the work.
• Determine what to simplify or omit, and the effects of doing so
• Figure out what's going on now
• Data sources, collecting, and conditioning
• Identify what everyone needs
• Propose, develop, and select a design
• Build the solution
• Test it
• Close project

The Engagement Framework:

• Project Planning
• Intended Use
• Assumptions, Capabilities, Limitations, and Risks and Impacts
• Conceptual Model (As-Is State)
• Data Sources, Collection, and Conditioning
• Requirements (To-Be State: Abstract)
• Functional (What it Does)
• Non-Functional (What it Is, plus Maintenance and Governance)
• Design (To-Be State: Detailed)
• Implementation
• Test
• Operation, Usability, and Outputs (Verification)
• Outputs and Fitness for Purpose (Validation)
• Acceptance (Accreditation)
• Project Close

The Framework: Simplified

•   Intended Use
•   Conceptual Model (As-Is State)
•   Data Sources, Collection, and Conditioning
•   Requirements (To-Be State: Abstract)
• Functional (What it Does)
• Non-Functional (What it Is, plus Maintenance and Governance)
•   Design (To-Be State: Detailed)
•   Implementation
•   Test
• Operation, Usability, and Outputs (Verification)
• Outputs and Fitness for Purpose (Validation)

Customer Feedback Cycle

Review every phase with the customer until they agree it's correct, especially for the Conceptual Model (As-Is State).

Needs discovered later could require the creation or modification of earlier elements.

This framework is usable for both Waterfall and Scrum, and really for any management style.

Link to detailed discussion.

Context of Your Effort

The framework phases all happen, the question is when. In Waterfall the phases proceed in order. In Scrum you might have many offset phases working though parallel pipelines. In a hybrid situation you might do the implementations by priority in the context of an overarching design.

Link to detailed discussion.

Context of Your Effort (continued)

Building a simulation or tool is often embedded into a larger analytical effort. Existing system: Create Conceptual Model based on what's already there. New System: Conceptual Model process is really part of the Design exploration. These processes are iterative.

Link to detailed discussion.

Extended Life Cycle

Phases May Involve Multiple Sub-Levels

This can be represented in many ways. Which one do you prefer?

Phases May Involve Multiple Sub-Levels (cont'd)

Software Development Life Cycle (SDLC) Phases

SDLC Phases vs. Bob's Framework Phases

The SDLC phases are a little jumbled, in my estimation.

But if you consider the iteration between phases, and the fact that nothing ever really happens in a formal, fixed order, you can see that all the pieces are there.

SDLC Simulation Activities vs. SDLC Phases

BABOK Chapter 3: Business Analysis Planning and Monitoring

Tasks Mapped to Bob's Framework Phases

BABOK Chapter 4: Elicitation and Collaboration

Tasks Mapped to Bob's Framework Phases

BABOK Chapter 5: Requirements Life Cycle Management

Tasks Mapped to Bob's Framework Phases

BABOK Chapter 6: Strategy Analysis

Tasks Mapped to Bob's Framework Phases

BABOK Chapter 7: Requirements Analysis and Design Definition

Tasks Mapped to Bob's Framework Phases

BABOK Chapter 8: Solution Evaluation

Tasks Mapped to Bob's Framework Phases

Requirements Traceability Matrix

• Best represented by a relational data structure but any method will work.
• Needs discovered later could require the creation of earlier elements.
• Methodological requirements (at bottom) can each be thought of as a kind of non-functional requirement that doesn't need to be mapped.

Requirements Traceability Matrix cont'd

• When the BABOK talks about traceability, and when the SDLC talks about architecture, it refers to the relationship of the design elements with each other.
• I show this hierarchy vertically, such that every element matches up in the design phase.

Project Planning

The business analysis process is embedded within the project management process.

Project management creates the environment and manages the resources. Business analysis solves the problem.

Link to detailed discussion.

Making Sure The Analysis Is Thorough

• Consider all elements from all angles.
• UML is a formal example. The BABOK is more diffuse.
• Simulation is great for understanding because the results show if everything's included.
• Formal mathematical proofs of correctness and optimality exist for some problems.
• Customer review and realized results are the best proof for most BA engagements.

There Are No Silver Bullets Or Final Answers

Facts and Fallacies of Software Engineering describes 50 years of incremental advance.

This presentation and other information can be found at my website:

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill