A Simulationist's Framework
for Business Analysis

Part 05:

What Business Analysts

Should Know About Software

R.P. Churchill

Lean Six Sigma Black Belt

www.rpchurchill.com/presentations/TWSLseries/05_Software www.rpchurchill.com | Portfolio | Presentations
30 Years of Simulation

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


  • Paper (Chemical/Process)
  • Nuclear (Power Generation)
  • Metals (Steel, Non-Ferrous)
  • HVAC (Building Control)
  • Insurance, Banking, Legal
  • Security, Inspections
  • Passenger Processing
  • Medical Facilities
  • Evacuations
  • Area Control
  • Threat Response
  • Logistics, Supply
  • Maintenance and Reliability
  • Staff Level Determination
  • Fleet Management



  • Design and Sizing
  • Operations Research
  • Real-Time Control
  • Operator Training
  • Risk Analysis
  • Economic Analysis
  • Impact Analysis
  • Process Improvement (BPR)

Architectural Considerations

  • Continuous vs. Discrete-Event
  • Interactive vs. Fire-and-Forget
  • Real-Time vs. Non-Real-Time
  • Single-Platform vs. Distributed
  • Deterministic vs. Stochastic
Computers Store Information As Ones and Zeros

These are examples from C/C++. Other numeric and data types are possible (e.g., 80-bit floats, logicals, enumerated types, tuples representing colors for pixels in images and videos, ASCII and Unicode for text characters and symbols), dates and times.

Basic types can be combined into strings, arrays, structures, records, objects, and so on, sometimes requiring you to know where the gaps are (see story 1).

Computers Can Only Do Six Things

Computing Operations

  • Move data from one place to another (Input / Output, Mem <-> CPU) (Interrupt may start new instruction stream.)
  • Add two numbers (includes subtraction)
  • Bit-twiddle (Shift, Mask, Invert, Logical ops, Status flags)


Instruction Operations (meta-operations)

  • Execute next instruction (Automatic after most instructions)
  • Jump to different instruction (goto, subroutine)
  • Terminate execution


Computers Operate at Multiple Levels (Usually)


BIOS level: Machine level instructions that know how to access some hardware and bootstrap the OS.

Operating System (OS) level: Manages processes, provides background services, facilitates access to all hardware

Application level: Does what the users want. Business Analysts are mostly concerned with applications that serve users.

Cluster level: Systems of multiple computers that perform different functions or replicate functions for scalability, operating as a unified whole.


Programming Tools Exist To Make Things Easier

Translate human-readable code into machine code.

Automate writing code.

Reduce coding errors.

Integrate reference material.

Integrate debugging and test operations.

Manage large projects.

Enhance and organize collaboration.

Manage complexity.



There Are Only A Few Main Language Constructs
  • I/O (user input, media output, file read/write, sensor read, controller write)
  • Math operations (including logical operators and assignment)
  • String operations
  • Create / Delete
  • If-Then-Else conditionals (including case / switch)
  • Counting loop
  • Test-at-the-top loop
  • Test-at-the-bottom loop
  • Jump / Goto
  • Subroutines

Comparisons of how the same basic constructs are handled in different programming languages are here and here as just two examples.

In the end the libraries and application frameworks are the bulk of what needs to be learned.

Program Layout in Memory
  • Code Segment: Holds code, some of which can be swapped in and out. (Intel processors CS register)
  • Data Segment: Holds global data, size fixed at compile time and on startup (interpreted languages may not have this). (Intel processors DS register)
  • Stack Segment: Holds execution stack with execution pointers, local variables, parameters, and function return values (Intel processors SS:SP registers)
  • Heap Segment: Holds dynamically allocated memory elements; managed via heap allocation list and garbage collection

The compiler, VM, or OS can set maximum sizes for these. Physical configuration of the processors and memory set the ultimate limits.

Details may vary between implementations

Traditional programs can mark a region of the heap and make it visible via the OS to other programs, which can then map to the absolute address. All programs need to use the same declarations for this to work (usually a shared header or include file).

Types of Languages
  • Construction language all forms of communication by which a human can specify an executable problem solution to a computer
    • Command language, a language used to control the tasks of the computer itself, such as starting other programs
    • Configuration language, a language used to write configuration files
    • Programming language, a formal language designed to communicate instructions to a machine, particularly a computer
  • Markup language, a grammar for annotating a document in a way that is syntactically distinguishable from the text, such as HTML
  • Modeling language, a formal language used to express information or knowledge, often for use in computer system design
    • Hardware description language, used to model integrated circuits
  • Page description language, describes the appearance of a printed page in a higher level than an actual output bitmap
  • Query language, a language used to make queries in databases and information systems
  • Simulation language, a language used to describe simulations
  • Specification language, a language used to describe what a system should do
  • Style sheet language, a computer language that expresses the presentation of structured documents, such as CSS
  • Transformation language, designed to transform some input text in a certain formal language into a modified output text that meets some specific goal
Generations of Languages
  • First-generation (1940s): hand-written machine code in 1s and 0s
  • Second-generation (1940s): assembly language, more human readable
  • Third-generation (early 1950s): first high-level languages (FORTRAN, COBOL, C/C++, Lisp, Pascal, Java, Javascript)
  • Fourth-generation (early 1970s): languages designed for specific purposes (SQL, R, LabView, MATLAB, Appian)
  • Fifth-generation (early 1980s): higher level of automation where the problem is defined but the solution was supposed to be figured out automatically. This never happened, which is why we still need BAs.

Most work gets done in third-generation languages.

Languages may fit into or incorporate many different paradigms.



It's All About Trade-offs



Is it more important to optimize software on speed or memory?




It depends.


It's All About Trade-offs (continued)

With power comes responsibility! Newer tools take more work out of the hands of programmers.


  • Automated memory management (garbage collection): Uses memory way less efficiently and can't control when the work is done.
  • Simplified data types: Uses memory less efficiently in exchange for simplicity.
  • Interpreted vs. compiled: Interpreted languages have to do a lot of work at runtime that can be done up front by a compiler.
  • Reduced low-level control: Can't make data items overlap in unions.
  • Detailed discussion


  • Greatly reduced errors
  • Improved productivity
  • Improved collaboration
  • Enhanced ability to manage complexity


  • Increased use of memory and computing power, sometimes by a lot
  • Loss of fine control by programmers
  • Many programmers have no idea what's going on "under the hood"
It's All About Trade-offs (continued)

List of considerations


  • execution speed
  • response time
  • memory usage
  • disk usage
  • clarity
  • modularity
  • maintainability
  • reusability
  • abstraction
  • language choice(s)
  • protocols
  • scalability
  • uptime
  • security

People and Methods

  • developers
  • managers
  • data collectors
  • analysts
  • testers
  • users
  • customers
  • speed of development
  • reduction of rework
  • popularity of languages and tools
  • industry trends
  • trends in larger society


  • capital vs. ongoing
  • fixed vs. variable
  • licensing
  • hardware
  • third-party
  • maintenance and support
  • upgradability

The ultimate optimization is to minimize the total cost of ownership over the entire life cycle.

Communication Models

There are multiple barriers to clear communication.

These can be mitigated by error-checking mechanisms — and by being clear in the first place.

The end blocks can be improved by review, mutual expertise, patience, and empathy.

The middle blocks can be improved by clearing up the communication medium.


Computers Communicate In A Similar Way


Detailed discussion.

...But You Have To Be Careful

Don't assume communications will just work. Make them robust.

Arrange for queues so failed operations can be retried until they succeed.

Log everything if appropriate. Use performance monitors.

Be aware of different data types and formats in different languages and on different machines.

Internet and other communications are often set up to deal with differences in data types, as described previously, and endianness, using XML encoding where everything is written out in text.

Other communications, involving video, audio, images, and specialized document formats, are based on published standards.

Communication for Business Analysts

Talking to customers is improved by mutual expertise, patience, and empathy.

Talking to users is improved by mutual expertise, patience, and empathy.

Talking to technical teams is improved by mutual expertise, patience, and empathy.

Talking to management is improved by mutual expertise, patience, and empathy.

Talking to external entities is improved by mutual expertise, patience, and empathy.

Documentation, review, feedback, and correction are human forms of queuing and retrying.

Non-Functional Requirements

Non-functional requirements are qualities the solution should have, and may also address working methodologies.

Wikipedia lists close to sixty possible NFRs.

All other participants and stakeholders should willingly — and proactively — drive identification and specification of NFRs, and will doubtless have their individual passions, but never be bashful about asking questions which lead to more conversation and specification.

As a BA, consider it your responsibility to drive a thorough exploration of this topic during an engagement.



User Interface / User eXperience (UI/UX)

If the Conceptual Model and Requirements are defined with sufficient clarity and thoroughness, the UI should practically write itself.

A good UI can be pretty or utilitarian, but it's more important that it:

  • Clearly displays information: Users should see and understand all the information they need, especially when it comes to actionable output.
  • Enables effective control: Users should be able to perform all necessary actions as efficiently and intuitively as possible.
  • Maintains situational awareness: Users should always be aware of what has been done and what needs to be done.
  • Prevents errors: A good UI will keep users from making errors.
  • Facilitates error recovery and correction: If errors do occur (and some are unavoidable), the UI should handle them, identify them to the user, and provide a way for the user to make corrections.


User Interface / User eXperience (UI/UX) (continued)

I've used systems that had absolutely horrible interfaces where you were never confident about what was going on.

Tax software and job search sites often maintain clear situational awareness.

Individual fields can enforce certain formats, can display allowable ranges of values, and show flags or change color when formatting or values are not acceptable.

BAs should have a solid grounding in UI elements and actions, and tools to create mock-ups, wireframes, and so on.

Question: Should there be more than one way to do things?

  • VARK method: Visual, Auditory, Read/write, Kinesthetic
  • Menu vs. Ribbon vs. Keyboard shortcut vs. graphical/mouse vs. voice
  • Accessibility by the disabled, Section 504 and 508 compliance
Enterprise Architecture The final piece of my puzzle!

You are trying to solve the problem on three layers as the same time.

I tend to conceptualize from the middle (application) layer and work out.

If the middle is solved abstractly, the other layers practically specify themselves.

Working in the different layers takes different, specialized skills. You need to be able to talk to a lot of different kinds of people.

Link to detailed discussion.


Given our discussion of...

  • Levels: BIOS - OS - Application - Cluster
  • Programming Tools: translation - scale - collaboration - complexity
  • Generations: First - Second - Third - Fourth - ?
  • Trade-offs: Automated memory management - simplified data - interpreted


...we see that the trend in software languages, tools, development practices, and management, has been in the direction of increasing abstraction in support of greater productivity and complexity.


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:


E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill