A Simulationist's Framework
for Business Analysis

Part 05:

What Business Analysts

Should Know About Software

R.P. Churchill

CBAP, PMP, CSPO, CSM, CSD
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

Industries

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

Applications

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

Question:

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

Answer:

It depends.

It's All About Trade-offs (continued)

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

Examples

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

Benefits

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

Costs

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

Computing

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

Cost

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.

Trends

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.