December 19, 2025 • 18 mins
An extensive overview of systems analysis and design, primarily focusing on the tenth edition of a textbook on the subject, likely by Kendall and Kendall. The content comprehensively covers the phases of the systems development life cycle (SDLC), including project management techniques such as feasibility analysis, PERT diagrams, and various conversion strategies. Significant attention is given to information gathering methods like interviewing, questionnaires, and observation (STROBE), as well as modern development approaches like agile modeling, prototyping, DevOps, and Unified Modeling Language (UML) for object-oriented systems. The text also details key design principles, including the creation of effective output and input (forms, displays, and web design), methods for database design (E-R diagrams, normalization, data warehouses), and strategies for ensuring data quality and system security through techniques like validation and structured walkthroughs.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Systems-Analysis-Design-Kenneth-Kendall/dp/1292281456?&linkCode=ll1&tag=cvthunderx-20&linkId=1de719c650fd6717d99fed1e8d05e362&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Systems-Analysis-Design-Kenneth-Kendall/dp/1292281456?&linkCode=ll1&tag=cvthunderx-20&linkId=1de719c650fd6717d99fed1e8d05e362&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Okay, let's unpack this. We live in a world where
everything I mean, from the smallest startup process right up
to huge global supply chains, it all runs on these
complex digital systems, and for business professionals, that complexity can
feel well, pretty overwhelming, sometimes.
Speaker 2 (00:19):
Information overload, definitely, it's real.
Speaker 1 (00:21):
Yeah, And what we really need is a kind of
systematic shortcut, almost like a blueprint, right to understand how
these critical digital things are dreamed up, built and managed effectively.
Speaker 2 (00:33):
And that's exactly our mission today. We're doing a deep
dive into systems analysis and design, or SAD as it's
often called. We're pulling together insights from some really comprehensive
sources you shared. We want to unpack the core processes,
the tools analysts use, and also those big shifts you know,
from the old traditional ways to more agile user focus
methods we see now.
Speaker 1 (00:53):
So at its heart systems analysis and design, it's the
process analysts use to figure out what the organization actually
needs exactly.
Speaker 2 (01:00):
It's about systematically looking at how data flows in, how
it gets processed, where it gets stored, and what useful
information actually comes out the other end. The aim is
always improvement.
Speaker 1 (01:12):
Analyzing designing, implementing better systems.
Speaker 2 (01:16):
Better computerized systems. Yeah, and to really guide that whole process,
we kind of have to start with the let's call
it the foundational map for the industry.
Speaker 1 (01:24):
Which is the classic system development life cycle STLC.
Speaker 2 (01:27):
That's the one. Now it's often adapted or even replaced
by newer approaches today, but it's seven phases still give
us that basic structure for thinking about any major project.
Speaker 1 (01:39):
It's basically the waterfall approach, right, you finish one step before.
Speaker 2 (01:42):
You move on, pretty much sequential.
Speaker 1 (01:45):
So Phase one is that critical starting point identifying problems, opportunities,
and objectives.
Speaker 2 (01:50):
Yeah.
Speaker 1 (01:51):
You just can't afford to skip this, can you, Because
building the perfect solution to the wrong problem, well that's
just wasted effort.
Speaker 2 (01:58):
Huge waste yearsotentially. So once you've nabled the problem, you
move to phase two analyzing system needs. That's all about
gathering the nitty gritty requirements. Then phase three designing the
recommended system. This is the logical design part. It's not
just database structures, but really critical things like user procedures,
how people will actually do their jobs with it, and
(02:20):
the human computer interaction.
Speaker 1 (02:22):
HgI, how the person actually interfaces with the screen, the keyboard.
Speaker 2 (02:26):
Everything exactly, how it feels to use, and.
Speaker 1 (02:28):
Comes the heavy lifting phases four and five. Right.
Speaker 2 (02:31):
Phase four developing and documenting the software, coding basically and
writing it all down. Phase five is testing and maintaining
the system, finding the bugs.
Speaker 1 (02:43):
And then finally getting it out there six and.
Speaker 2 (02:45):
Seven implementing the system in phase six and crucially evaluating
its success after launch in phase seven. Did it actually work?
Did it solve the problem we identified back in phase one?
Speaker 1 (02:57):
And you mentioned this sequence, this phase definition, it's really
important when you look at costs over time.
Speaker 2 (03:02):
Oh, absolutely crucial, especially when you look at the project's
long term cost curve. A huge mistake people make is
underestimating the financial hit on the back end.
Speaker 1 (03:11):
You mean after it's launched.
Speaker 2 (03:12):
Yeah, the sources are really clear on this. The resources
consumed time, money, They increase dramatically over the system's life,
particularly maintenance.
Speaker 1 (03:21):
So testing catches initial bugs, but what drives those big
cost spikes later on?
Speaker 2 (03:27):
Major changes? Think about it. The business evolves, technology shifts,
new regulations come in, the system needs significant updates years
down the line. Wow, And if that initial analysis and
documentation back in phrases one, two, three, if that was sloppy,
fixing or changing that system later can be exponentially more expensive.
(03:47):
Good upfront analysis is like it's your insurance policy against
those future cost blowouts.
Speaker 1 (03:52):
Wow. Okay, So given that huge potential future cost, it
makes sense that before you even start that whole cycle
you need to check if it's even worth doing the
feasibility study Exactly.
Speaker 2 (04:02):
Any serious project needs to pass muster in three key areas.
It's like a quick checklist respecting your time and resources. First,
technical feasibility is it possible?
Speaker 1 (04:10):
Can we actually build this with the tech we have
or the tech we can realistically.
Speaker 2 (04:14):
Get precisely hardware software expertise? Is it doable? Second economic
feasibility the classic cost benefit analysis.
Speaker 1 (04:24):
Do the long term gains actually outweigh the short term
development costs? And here we need to look beyond just
the obvious stuff.
Speaker 2 (04:31):
You mean tangible versus intangible benefits exactly.
Speaker 1 (04:34):
Tangible benefits are easy, you save money on operations, things
run faster, you can count it. But the intangible benefits
those are often the strategic game changers, like what improving
decision making because reports are more accurate, enhancing the company's image,
boosting employee morale, maybe hard to put a dollar figure on,
but incredibly valuable long term.
Speaker 2 (04:53):
Okay. And the third one, the really human one, operational feasibility.
Speaker 1 (04:58):
And this might be the most critical ch honestly, operational
feasibility asks will people actually use this thing effectively once
it's installed?
Speaker 2 (05:07):
It all comes down to people.
Speaker 1 (05:08):
Entirely, human resources, office politics, organizational culture acceptance. You can
have the most technically perfect, budget friendly system, but if
the people it's meant for won't adopt it or can't
use it properly, it's worthless. This connects back to that
really interesting idea from the sources about organizational metaphors. Doesn't
it how the company sees itself?
Speaker 2 (05:29):
It absolutely does. Culture gets described using these implicit metaphors. Right,
is your place seen as a machine, a family, maybe
a war zone or a jungle. The success of a
new system hinges massively on whether it fits those unspoken
rules and expectations. A highly structured system might fly in
(05:51):
a machine culture, but crash and burn in a jungle
where everyone's fighting.
Speaker 1 (05:55):
For resources, regardless of how well it's coded.
Speaker 2 (05:58):
Regardless, the analyst almost needs to be an anthropopy first,
then an engineer.
Speaker 1 (06:01):
That's a huge insight. Okay, okay, So let's say we've
passed feasibility, especially operational, we think the system will be used.
How do analysts then map out the logic? This is
where the analysis tools come in, right.
Speaker 2 (06:13):
Let's start with the visual approach. Data flow diagrams DSDs.
Speaker 1 (06:17):
Pictures of data moving around.
Speaker 2 (06:18):
Essentially, Yes, they use simple symbols to graphically show data processes,
where data flows, and where it's stored. They chart the
journey of data through a business function.
Speaker 1 (06:27):
But why draw pictures? Why don't just write it down?
Speaker 2 (06:30):
Ah? Because DFDs force a really important separation. They let
the analyst define the logical system what should happen, separately
from the physical system what currently happens, maybe with pay
per forms or old software.
Speaker 1 (06:43):
And why is that separation so vital?
Speaker 2 (06:45):
Because if you only analyze the current physical system, you
risk just automating outdated or inefficient processes. DFDs help you
design what should be happening, not just pave the cowpaths,
so to speak.
Speaker 1 (06:58):
Got it? Design the ideal flow first, and the dfd's
partner is the data dictionary, making sure everyone agrees.
Speaker 2 (07:05):
On terms precisely. Think of the data dictionary as the
system's definitive reference guide. It collects and coordinates all the
specific data terms, the metadata or data about the data.
Speaker 1 (07:15):
So customer ID needs the same thing to marketing and
accounting exactly.
Speaker 2 (07:18):
That consistency is non negotiable for complex systems, no ambiguity allowed.
Speaker 1 (07:23):
I saw a note connecting this to web systems too,
specifically XML.
Speaker 2 (07:27):
Yes, it's fundamental. The data dictionary is basically the starting
point for creating XML schemas. XMEL is great because it
stores data as plaintext, independent of any specific.
Speaker 1 (07:38):
Software, making it easy to share right.
Speaker 2 (07:40):
And the dictionary provides the stricture rules ensuring that data
is consistent and can be validated easily when it's shared
between different systems or platforms.
Speaker 1 (07:48):
Okay, So DFDs show the flow. Dictionaries define the terms.
Now what about the actual decision points in that flow?
How do analysts document structured decisions, the ones that are
rule based, no human judgment needed, like calculating a fee.
Speaker 2 (08:03):
There are three main ways. The simplest is probably structured.
Speaker 1 (08:06):
English sounds like coding almost It's close.
Speaker 2 (08:09):
You use plain English, but with standardized keywords like if
then elsie do, while often using indentation to show the
logic sequence It reads a bit like pseudocode, but.
Speaker 1 (08:19):
I imagine that gets complicated fast if you have lots
of interacting conditions.
Speaker 2 (08:22):
It really can, which is why for more complex logic
with many combinations of conditions and actions, we turn to
decision tables.
Speaker 1 (08:29):
Tables like spreadsheets.
Speaker 2 (08:32):
Sort of, but very structured. They force you to map
out every single possible combination of conditions, the rules that apply,
and the resulting actions. It's incredibly useful for catching contradictions
or impossible scenarios before they get.
Speaker 1 (08:45):
Coded, making sure all the bases are covered.
Speaker 2 (08:47):
Every single one.
Speaker 1 (08:47):
And the third method decision trees. How are they different?
Speaker 2 (08:51):
Decision trees are best when the sequence of checking conditions matters.
The branching structure visually shows the order you ask the
questions or check the condition.
Speaker 1 (09:00):
Ah, so the path matters exactly.
Speaker 2 (09:03):
Also, if not all conditions apply to all outcomes, meaning
some branches and early, a tree can be much clearer
and less cluttered than a huge table full of not
applicable cells.
Speaker 1 (09:14):
Okay, those tools sound powerful for nailing down the logic,
but as effective as they are, the world realized that
the whole step by step waterfall thing, the classic SDLC
could be just too slow, too rigid for businesses needing
constant change.
Speaker 2 (09:29):
And that necessity really drove a huge paradigm shift in
software development towards modern methods that prioritize speed, flexibility, and
getting constant feedback from users and the business. The big
one here is agile modeling.
Speaker 1 (09:42):
Agile. We hear that word a lot, we do.
Speaker 2 (09:45):
It's really a collection of approaches, all user centered, built
on four core values, communication, simplicity, feedback, and courage.
Speaker 1 (09:53):
So instead of a giant upfront plan, it works in
shorter cycles.
Speaker 2 (09:57):
Exactly short development cycles often called prints, maybe two to
four weeks. And the plan isn't some fixed document, it's
a dynamic product backlog, a prioritized wishless pretty much a
list of features constantly reprioritized based on what brings the
most business value right now. Teams even use techniques like
scrum planning poker to estimate task effort.
Speaker 1 (10:19):
Collaboratively planning poker sounds fun, but how do managers keep
track if things are changing so fast? Doesn't they get chaotic?
Speaker 2 (10:26):
You'd think so, but it's actually quite controlled thanks to
tools like the burn down chart.
Speaker 1 (10:31):
What's up?
Speaker 2 (10:31):
It's a simple graph, really key in agile. It plots
the amount of work left to do, maybe in hours,
maybe in tasks, against the time remaining in the.
Speaker 1 (10:39):
Sprint, so you see progress visually instantly.
Speaker 2 (10:42):
If the line's dropping steadily, you're on track. If it
flattens out, the team knows immediately they need to figure
out what's wrong and adjust. It provides that crucial constant
feedback loop.
Speaker 1 (10:52):
And that focus on feedback naturally leads to thinking more
about the user experience, doesn't it.
Speaker 2 (10:57):
UX design absolutely, UX is a one is explicitly customer first.
It's all about observing how people actually behave when using
a product or service, and then designing to make that
experience better to boost satisfaction and loyalty.
Speaker 1 (11:12):
And the strategy is sometimes counterintuitive.
Speaker 2 (11:14):
It can be Prioritizing a great experience might mean not
maximizing profit on every single interaction because you know that
long term loyalty derived from a good experience is strategically
worth more.
Speaker 1 (11:26):
And part of that experience today means dealing with all
the different devices people use. Oh.
Speaker 2 (11:30):
Definitely, Responsive web design RWUD is a huge part of
modern UX. It's about making sure your website or application
adapts and displays content properly, no matter.
Speaker 1 (11:40):
What device is used, phone, tablet, desktop, Right.
Speaker 2 (11:42):
It doesn't just shrink the page. It intelligently reorganizes the
content to fit the screen and be easy to use
wherever the user happens to be.
Speaker 1 (11:51):
Now, getting this speed, this user focus, it requires more
than just new tools. It needs a cultural shift too,
which brings us to DevOps.
Speaker 2 (12:00):
Yeah. DevOps short for development and operations. It's really the
cultural shift needed to make agile work smoothly, especially in
larger organizations.
Speaker 1 (12:09):
What problem does it solve?
Speaker 2 (12:10):
It tackles that classic friction point. You have developers pushing
for rapid innovation, new features all the time, and you
have operations folks focused on keeping things stable monitoring systems. Historically,
they often ended up pointing fingers when something broke right.
Speaker 1 (12:25):
Whose fault is the bug?
Speaker 2 (12:26):
DevOps tries to break down that wall. It fosters a
culture where development and operations work in close collaboration, often
on parallel tracks. DEV focuses on rapid releases. Ops focuses
on continuous monitoring and maintenance.
Speaker 1 (12:39):
Of what's live, so they work together instead of against
each other.
Speaker 2 (12:42):
Yeah, that's the goal. It prevents delays caused by arguments
over responsibility and lets the organization innovate quickly while maintaining stability.
It's a cultural alignment.
Speaker 1 (12:50):
Okay, so we have faster, user focused systems built with
agile and DevOps. Powerful stuff, but it only works if
it's reliable. Talk quality assurance. How do analysts make sure
qualities baked in? Especially with these faster cycles.
Speaker 2 (13:06):
Quality can't be an afterthought. It has to be continuous.
One really influential idea analysts often borrow is six sigmas.
Speaker 1 (13:13):
I've heard of that, very rigorous.
Speaker 2 (13:15):
Incredibly, it sets an extremely high bar for quality. The
statistical goal is essentially to eliminate almost all defects, aiming
for no more than three point four defects per million opportunities.
Speaker 1 (13:26):
Wow, And how do you catch errors before they get
anywhere near that stage? Peer review?
Speaker 2 (13:30):
Yes, systematic peer review through things like structured walkthroughs. It's
not just casual feedback. It's a routine process.
Speaker 1 (13:37):
How does it work.
Speaker 2 (13:37):
You have a small team, maybe the analyst who did
the work, a coordinator, and a couple of peers. They
methodically walk through the design, the code, whatever the artifact
is looking for problems, catching them early, exactly, catching them
when they're cheap and easy to fix, not after the
system is deployed and a failure could be catastrophic.
Speaker 1 (13:55):
Makes sense beyond just defects. What about managing the project
timeline itself, especially for really big projects. How do analysts
keep things on schedule?
Speaker 2 (14:06):
For complex projects with lots of moving parts, tools like
per program evaluation and review technique are essential.
Speaker 1 (14:13):
What is pro doue?
Speaker 2 (14:14):
It helps you map out all the project activities, figure
out how long each will take, and understand the dependencies
between them. But its real power comes from identifying the
critical path.
Speaker 1 (14:24):
The critical path Okay, what exactly.
Speaker 2 (14:26):
Is that it's the longest sequence of dependent activities from
the start of the project to the end. Because it's
the longest chain, any delay in any task on that
path will delay the entire project's completion date.
Speaker 1 (14:38):
Ah, so that's the chain you absolutely cannot let slip.
Speaker 2 (14:41):
Precisely, if you lose a day on the critical path,
the whole project is a day late. Managers have to
watch those critical path tasks like hawks, sometimes even letting
less critical tasks slide if necessary to keep the main
sequence on track.
Speaker 1 (14:54):
Okay, that's crucial for control. Finally, let's look ahead of
it systems are getting bigger data is exploding. What emerging
concepts are analysts grappling with now?
Speaker 2 (15:06):
Two big data concepts really stand out.
Speaker 1 (15:08):
First, data mining, digging through data for insights.
Speaker 2 (15:11):
Basically yes, it operates on the assumption that past behavior
is the best predictor of future behavior. Companies use it
to analyze massive databases, credit card transactions, social media activity,
website clicks.
Speaker 1 (15:24):
Could predict what customers will do next and.
Speaker 2 (15:26):
Target them much more effectively, turning huge data stores into
potential profit by understanding patterns and predicting future purchases or
actions with startling accuracy.
Speaker 1 (15:36):
And the second big one blockchains, which are more than
just cryptocurrency.
Speaker 2 (15:40):
Right, oh, much more Fundamentally, a blockchain is an open,
unchangeable record of transactions, essentially a distributed database shared among
many parties.
Speaker 1 (15:50):
What's the benefit?
Speaker 2 (15:51):
Improve security, reduced risk, better efficiency, Think supply chains. Everyone
involved can see the same trusted, verified ledger of where
goods are, who did what? But when? No single point
of failure or control.
Speaker 1 (16:03):
But there's a catch there is.
Speaker 2 (16:05):
The biggest barrier often isn't technical, it's organizational trust. Getting
large organizations used to centralized control to trust and rely
on a decentralized, transparent shared record that requires a significant
shift in mindset and challenges established power structures.
Speaker 1 (16:23):
Fascinating. Wow, Okay, that was quite a journey. We went
from the the rigid blue prints of the classic SELC.
Speaker 2 (16:30):
Right through the speed and flexibility of agile and the
cultural shift of DevOps.
Speaker 1 (16:35):
Touched on those deep analysis tools like DFDs and decision tables,
and ended.
Speaker 2 (16:39):
Up right at the edge with data mining and blockchains.
Speaker 1 (16:42):
It really underscores how strategic the analyst role is. Yeah,
you need that foundational knowledge, but also the agility to.
Speaker 2 (16:48):
Adapt, absolutely respecting the sdlc's structure while fully embracing modern
speed and user focus. And we saw how quality, whether
through sixing the discipline or carefully managing that critical path
is just completely non negot.
Speaker 1 (17:00):
And that thread running through it all, the human element
kept popping up, operational feasibility, Will people use it?
Speaker 2 (17:06):
It's often the ultimate decider and that connection to organizational culture,
those metaphors machine family war zone.
Speaker 1 (17:13):
It determines whether a technically perfect system actually succeeds in
the real world.
Speaker 2 (17:18):
That cultural fit. Maybe that's the real critical path. Sometimes
a brilliant system designed for machine culture will just break.
If you drop it into a jungle environment, the design
has to mesh with those unspoken rules and expectations.
Speaker 1 (17:32):
So here's something provocative for you, our listener, to think
about after this deep dive. Consider that idea of organizational
culture as a metaphor, which one machine family, jungle war zone,
something else, which one really feels like your organization? And
how does that unique culture shape the systems you use
every day or the ones you might be thinking about
building or adopting next. That alignment, that sweet spot between
(17:56):
the code and the culture, that's where true operational fees, ability,
and ultimately success is really found.
Speaker 2 (18:03):
Great point until next time, Keep analyzing those
Speaker 1 (18:05):
Systems and keep diving deep
Okay, let's unpack this. We live in a world where
everything I mean, from the smallest startup process right up
to huge global supply chains, it all runs on these
complex digital systems, and for business professionals, that complexity can
feel well, pretty overwhelming, sometimes.
Speaker 2 (00:19):
Information overload, definitely, it's real.
Speaker 1 (00:21):
Yeah, And what we really need is a kind of
systematic shortcut, almost like a blueprint, right to understand how
these critical digital things are dreamed up, built and managed effectively.
Speaker 2 (00:33):
And that's exactly our mission today. We're doing a deep
dive into systems analysis and design, or SAD as it's
often called. We're pulling together insights from some really comprehensive
sources you shared. We want to unpack the core processes,
the tools analysts use, and also those big shifts you know,
from the old traditional ways to more agile user focus
methods we see now.
Speaker 1 (00:53):
So at its heart systems analysis and design, it's the
process analysts use to figure out what the organization actually
needs exactly.
Speaker 2 (01:00):
It's about systematically looking at how data flows in, how
it gets processed, where it gets stored, and what useful
information actually comes out the other end. The aim is
always improvement.
Speaker 1 (01:12):
Analyzing designing, implementing better systems.
Speaker 2 (01:16):
Better computerized systems. Yeah, and to really guide that whole process,
we kind of have to start with the let's call
it the foundational map for the industry.
Speaker 1 (01:24):
Which is the classic system development life cycle STLC.
Speaker 2 (01:27):
That's the one. Now it's often adapted or even replaced
by newer approaches today, but it's seven phases still give
us that basic structure for thinking about any major project.
Speaker 1 (01:39):
It's basically the waterfall approach, right, you finish one step before.
Speaker 2 (01:42):
You move on, pretty much sequential.
Speaker 1 (01:45):
So Phase one is that critical starting point identifying problems, opportunities,
and objectives.
Speaker 2 (01:50):
Yeah.
Speaker 1 (01:51):
You just can't afford to skip this, can you, Because
building the perfect solution to the wrong problem, well that's
just wasted effort.
Speaker 2 (01:58):
Huge waste yearsotentially. So once you've nabled the problem, you
move to phase two analyzing system needs. That's all about
gathering the nitty gritty requirements. Then phase three designing the
recommended system. This is the logical design part. It's not
just database structures, but really critical things like user procedures,
how people will actually do their jobs with it, and
(02:20):
the human computer interaction.
Speaker 1 (02:22):
HgI, how the person actually interfaces with the screen, the keyboard.
Speaker 2 (02:26):
Everything exactly, how it feels to use, and.
Speaker 1 (02:28):
Comes the heavy lifting phases four and five. Right.
Speaker 2 (02:31):
Phase four developing and documenting the software, coding basically and
writing it all down. Phase five is testing and maintaining
the system, finding the bugs.
Speaker 1 (02:43):
And then finally getting it out there six and.
Speaker 2 (02:45):
Seven implementing the system in phase six and crucially evaluating
its success after launch in phase seven. Did it actually work?
Did it solve the problem we identified back in phase one?
Speaker 1 (02:57):
And you mentioned this sequence, this phase definition, it's really
important when you look at costs over time.
Speaker 2 (03:02):
Oh, absolutely crucial, especially when you look at the project's
long term cost curve. A huge mistake people make is
underestimating the financial hit on the back end.
Speaker 1 (03:11):
You mean after it's launched.
Speaker 2 (03:12):
Yeah, the sources are really clear on this. The resources
consumed time, money, They increase dramatically over the system's life,
particularly maintenance.
Speaker 1 (03:21):
So testing catches initial bugs, but what drives those big
cost spikes later on?
Speaker 2 (03:27):
Major changes? Think about it. The business evolves, technology shifts,
new regulations come in, the system needs significant updates years
down the line. Wow, And if that initial analysis and
documentation back in phrases one, two, three, if that was sloppy,
fixing or changing that system later can be exponentially more expensive.
(03:47):
Good upfront analysis is like it's your insurance policy against
those future cost blowouts.
Speaker 1 (03:52):
Wow. Okay, So given that huge potential future cost, it
makes sense that before you even start that whole cycle
you need to check if it's even worth doing the
feasibility study Exactly.
Speaker 2 (04:02):
Any serious project needs to pass muster in three key areas.
It's like a quick checklist respecting your time and resources. First,
technical feasibility is it possible?
Speaker 1 (04:10):
Can we actually build this with the tech we have
or the tech we can realistically.
Speaker 2 (04:14):
Get precisely hardware software expertise? Is it doable? Second economic
feasibility the classic cost benefit analysis.
Speaker 1 (04:24):
Do the long term gains actually outweigh the short term
development costs? And here we need to look beyond just
the obvious stuff.
Speaker 2 (04:31):
You mean tangible versus intangible benefits exactly.
Speaker 1 (04:34):
Tangible benefits are easy, you save money on operations, things
run faster, you can count it. But the intangible benefits
those are often the strategic game changers, like what improving
decision making because reports are more accurate, enhancing the company's image,
boosting employee morale, maybe hard to put a dollar figure on,
but incredibly valuable long term.
Speaker 2 (04:53):
Okay. And the third one, the really human one, operational feasibility.
Speaker 1 (04:58):
And this might be the most critical ch honestly, operational
feasibility asks will people actually use this thing effectively once
it's installed?
Speaker 2 (05:07):
It all comes down to people.
Speaker 1 (05:08):
Entirely, human resources, office politics, organizational culture acceptance. You can
have the most technically perfect, budget friendly system, but if
the people it's meant for won't adopt it or can't
use it properly, it's worthless. This connects back to that
really interesting idea from the sources about organizational metaphors. Doesn't
it how the company sees itself?
Speaker 2 (05:29):
It absolutely does. Culture gets described using these implicit metaphors. Right,
is your place seen as a machine, a family, maybe
a war zone or a jungle. The success of a
new system hinges massively on whether it fits those unspoken
rules and expectations. A highly structured system might fly in
(05:51):
a machine culture, but crash and burn in a jungle
where everyone's fighting.
Speaker 1 (05:55):
For resources, regardless of how well it's coded.
Speaker 2 (05:58):
Regardless, the analyst almost needs to be an anthropopy first,
then an engineer.
Speaker 1 (06:01):
That's a huge insight. Okay, okay, So let's say we've
passed feasibility, especially operational, we think the system will be used.
How do analysts then map out the logic? This is
where the analysis tools come in, right.
Speaker 2 (06:13):
Let's start with the visual approach. Data flow diagrams DSDs.
Speaker 1 (06:17):
Pictures of data moving around.
Speaker 2 (06:18):
Essentially, Yes, they use simple symbols to graphically show data processes,
where data flows, and where it's stored. They chart the
journey of data through a business function.
Speaker 1 (06:27):
But why draw pictures? Why don't just write it down?
Speaker 2 (06:30):
Ah? Because DFDs force a really important separation. They let
the analyst define the logical system what should happen, separately
from the physical system what currently happens, maybe with pay
per forms or old software.
Speaker 1 (06:43):
And why is that separation so vital?
Speaker 2 (06:45):
Because if you only analyze the current physical system, you
risk just automating outdated or inefficient processes. DFDs help you
design what should be happening, not just pave the cowpaths,
so to speak.
Speaker 1 (06:58):
Got it? Design the ideal flow first, and the dfd's
partner is the data dictionary, making sure everyone agrees.
Speaker 2 (07:05):
On terms precisely. Think of the data dictionary as the
system's definitive reference guide. It collects and coordinates all the
specific data terms, the metadata or data about the data.
Speaker 1 (07:15):
So customer ID needs the same thing to marketing and
accounting exactly.
Speaker 2 (07:18):
That consistency is non negotiable for complex systems, no ambiguity allowed.
Speaker 1 (07:23):
I saw a note connecting this to web systems too,
specifically XML.
Speaker 2 (07:27):
Yes, it's fundamental. The data dictionary is basically the starting
point for creating XML schemas. XMEL is great because it
stores data as plaintext, independent of any specific.
Speaker 1 (07:38):
Software, making it easy to share right.
Speaker 2 (07:40):
And the dictionary provides the stricture rules ensuring that data
is consistent and can be validated easily when it's shared
between different systems or platforms.
Speaker 1 (07:48):
Okay, So DFDs show the flow. Dictionaries define the terms.
Now what about the actual decision points in that flow?
How do analysts document structured decisions, the ones that are
rule based, no human judgment needed, like calculating a fee.
Speaker 2 (08:03):
There are three main ways. The simplest is probably structured.
Speaker 1 (08:06):
English sounds like coding almost It's close.
Speaker 2 (08:09):
You use plain English, but with standardized keywords like if
then elsie do, while often using indentation to show the
logic sequence It reads a bit like pseudocode, but.
Speaker 1 (08:19):
I imagine that gets complicated fast if you have lots
of interacting conditions.
Speaker 2 (08:22):
It really can, which is why for more complex logic
with many combinations of conditions and actions, we turn to
decision tables.
Speaker 1 (08:29):
Tables like spreadsheets.
Speaker 2 (08:32):
Sort of, but very structured. They force you to map
out every single possible combination of conditions, the rules that apply,
and the resulting actions. It's incredibly useful for catching contradictions
or impossible scenarios before they get.
Speaker 1 (08:45):
Coded, making sure all the bases are covered.
Speaker 2 (08:47):
Every single one.
Speaker 1 (08:47):
And the third method decision trees. How are they different?
Speaker 2 (08:51):
Decision trees are best when the sequence of checking conditions matters.
The branching structure visually shows the order you ask the
questions or check the condition.
Speaker 1 (09:00):
Ah, so the path matters exactly.
Speaker 2 (09:03):
Also, if not all conditions apply to all outcomes, meaning
some branches and early, a tree can be much clearer
and less cluttered than a huge table full of not
applicable cells.
Speaker 1 (09:14):
Okay, those tools sound powerful for nailing down the logic,
but as effective as they are, the world realized that
the whole step by step waterfall thing, the classic SDLC
could be just too slow, too rigid for businesses needing
constant change.
Speaker 2 (09:29):
And that necessity really drove a huge paradigm shift in
software development towards modern methods that prioritize speed, flexibility, and
getting constant feedback from users and the business. The big
one here is agile modeling.
Speaker 1 (09:42):
Agile. We hear that word a lot, we do.
Speaker 2 (09:45):
It's really a collection of approaches, all user centered, built
on four core values, communication, simplicity, feedback, and courage.
Speaker 1 (09:53):
So instead of a giant upfront plan, it works in
shorter cycles.
Speaker 2 (09:57):
Exactly short development cycles often called prints, maybe two to
four weeks. And the plan isn't some fixed document, it's
a dynamic product backlog, a prioritized wishless pretty much a
list of features constantly reprioritized based on what brings the
most business value right now. Teams even use techniques like
scrum planning poker to estimate task effort.
Speaker 1 (10:19):
Collaboratively planning poker sounds fun, but how do managers keep
track if things are changing so fast? Doesn't they get chaotic?
Speaker 2 (10:26):
You'd think so, but it's actually quite controlled thanks to
tools like the burn down chart.
Speaker 1 (10:31):
What's up?
Speaker 2 (10:31):
It's a simple graph, really key in agile. It plots
the amount of work left to do, maybe in hours,
maybe in tasks, against the time remaining in the.
Speaker 1 (10:39):
Sprint, so you see progress visually instantly.
Speaker 2 (10:42):
If the line's dropping steadily, you're on track. If it
flattens out, the team knows immediately they need to figure
out what's wrong and adjust. It provides that crucial constant
feedback loop.
Speaker 1 (10:52):
And that focus on feedback naturally leads to thinking more
about the user experience, doesn't it.
Speaker 2 (10:57):
UX design absolutely, UX is a one is explicitly customer first.
It's all about observing how people actually behave when using
a product or service, and then designing to make that
experience better to boost satisfaction and loyalty.
Speaker 1 (11:12):
And the strategy is sometimes counterintuitive.
Speaker 2 (11:14):
It can be Prioritizing a great experience might mean not
maximizing profit on every single interaction because you know that
long term loyalty derived from a good experience is strategically
worth more.
Speaker 1 (11:26):
And part of that experience today means dealing with all
the different devices people use. Oh.
Speaker 2 (11:30):
Definitely, Responsive web design RWUD is a huge part of
modern UX. It's about making sure your website or application
adapts and displays content properly, no matter.
Speaker 1 (11:40):
What device is used, phone, tablet, desktop, Right.
Speaker 2 (11:42):
It doesn't just shrink the page. It intelligently reorganizes the
content to fit the screen and be easy to use
wherever the user happens to be.
Speaker 1 (11:51):
Now, getting this speed, this user focus, it requires more
than just new tools. It needs a cultural shift too,
which brings us to DevOps.
Speaker 2 (12:00):
Yeah. DevOps short for development and operations. It's really the
cultural shift needed to make agile work smoothly, especially in
larger organizations.
Speaker 1 (12:09):
What problem does it solve?
Speaker 2 (12:10):
It tackles that classic friction point. You have developers pushing
for rapid innovation, new features all the time, and you
have operations folks focused on keeping things stable monitoring systems. Historically,
they often ended up pointing fingers when something broke right.
Speaker 1 (12:25):
Whose fault is the bug?
Speaker 2 (12:26):
DevOps tries to break down that wall. It fosters a
culture where development and operations work in close collaboration, often
on parallel tracks. DEV focuses on rapid releases. Ops focuses
on continuous monitoring and maintenance.
Speaker 1 (12:39):
Of what's live, so they work together instead of against
each other.
Speaker 2 (12:42):
Yeah, that's the goal. It prevents delays caused by arguments
over responsibility and lets the organization innovate quickly while maintaining stability.
It's a cultural alignment.
Speaker 1 (12:50):
Okay, so we have faster, user focused systems built with
agile and DevOps. Powerful stuff, but it only works if
it's reliable. Talk quality assurance. How do analysts make sure
qualities baked in? Especially with these faster cycles.
Speaker 2 (13:06):
Quality can't be an afterthought. It has to be continuous.
One really influential idea analysts often borrow is six sigmas.
Speaker 1 (13:13):
I've heard of that, very rigorous.
Speaker 2 (13:15):
Incredibly, it sets an extremely high bar for quality. The
statistical goal is essentially to eliminate almost all defects, aiming
for no more than three point four defects per million opportunities.
Speaker 1 (13:26):
Wow, And how do you catch errors before they get
anywhere near that stage? Peer review?
Speaker 2 (13:30):
Yes, systematic peer review through things like structured walkthroughs. It's
not just casual feedback. It's a routine process.
Speaker 1 (13:37):
How does it work.
Speaker 2 (13:37):
You have a small team, maybe the analyst who did
the work, a coordinator, and a couple of peers. They
methodically walk through the design, the code, whatever the artifact
is looking for problems, catching them early, exactly, catching them
when they're cheap and easy to fix, not after the
system is deployed and a failure could be catastrophic.
Speaker 1 (13:55):
Makes sense beyond just defects. What about managing the project
timeline itself, especially for really big projects. How do analysts
keep things on schedule?
Speaker 2 (14:06):
For complex projects with lots of moving parts, tools like
per program evaluation and review technique are essential.
Speaker 1 (14:13):
What is pro doue?
Speaker 2 (14:14):
It helps you map out all the project activities, figure
out how long each will take, and understand the dependencies
between them. But its real power comes from identifying the
critical path.
Speaker 1 (14:24):
The critical path Okay, what exactly.
Speaker 2 (14:26):
Is that it's the longest sequence of dependent activities from
the start of the project to the end. Because it's
the longest chain, any delay in any task on that
path will delay the entire project's completion date.
Speaker 1 (14:38):
Ah, so that's the chain you absolutely cannot let slip.
Speaker 2 (14:41):
Precisely, if you lose a day on the critical path,
the whole project is a day late. Managers have to
watch those critical path tasks like hawks, sometimes even letting
less critical tasks slide if necessary to keep the main
sequence on track.
Speaker 1 (14:54):
Okay, that's crucial for control. Finally, let's look ahead of
it systems are getting bigger data is exploding. What emerging
concepts are analysts grappling with now?
Speaker 2 (15:06):
Two big data concepts really stand out.
Speaker 1 (15:08):
First, data mining, digging through data for insights.
Speaker 2 (15:11):
Basically yes, it operates on the assumption that past behavior
is the best predictor of future behavior. Companies use it
to analyze massive databases, credit card transactions, social media activity,
website clicks.
Speaker 1 (15:24):
Could predict what customers will do next and.
Speaker 2 (15:26):
Target them much more effectively, turning huge data stores into
potential profit by understanding patterns and predicting future purchases or
actions with startling accuracy.
Speaker 1 (15:36):
And the second big one blockchains, which are more than
just cryptocurrency.
Speaker 2 (15:40):
Right, oh, much more Fundamentally, a blockchain is an open,
unchangeable record of transactions, essentially a distributed database shared among
many parties.
Speaker 1 (15:50):
What's the benefit?
Speaker 2 (15:51):
Improve security, reduced risk, better efficiency, Think supply chains. Everyone
involved can see the same trusted, verified ledger of where
goods are, who did what? But when? No single point
of failure or control.
Speaker 1 (16:03):
But there's a catch there is.
Speaker 2 (16:05):
The biggest barrier often isn't technical, it's organizational trust. Getting
large organizations used to centralized control to trust and rely
on a decentralized, transparent shared record that requires a significant
shift in mindset and challenges established power structures.
Speaker 1 (16:23):
Fascinating. Wow, Okay, that was quite a journey. We went
from the the rigid blue prints of the classic SELC.
Speaker 2 (16:30):
Right through the speed and flexibility of agile and the
cultural shift of DevOps.
Speaker 1 (16:35):
Touched on those deep analysis tools like DFDs and decision tables,
and ended.
Speaker 2 (16:39):
Up right at the edge with data mining and blockchains.
Speaker 1 (16:42):
It really underscores how strategic the analyst role is. Yeah,
you need that foundational knowledge, but also the agility to.
Speaker 2 (16:48):
Adapt, absolutely respecting the sdlc's structure while fully embracing modern
speed and user focus. And we saw how quality, whether
through sixing the discipline or carefully managing that critical path
is just completely non negot.
Speaker 1 (17:00):
And that thread running through it all, the human element
kept popping up, operational feasibility, Will people use it?
Speaker 2 (17:06):
It's often the ultimate decider and that connection to organizational culture,
those metaphors machine family war zone.
Speaker 1 (17:13):
It determines whether a technically perfect system actually succeeds in
the real world.
Speaker 2 (17:18):
That cultural fit. Maybe that's the real critical path. Sometimes
a brilliant system designed for machine culture will just break.
If you drop it into a jungle environment, the design
has to mesh with those unspoken rules and expectations.
Speaker 1 (17:32):
So here's something provocative for you, our listener, to think
about after this deep dive. Consider that idea of organizational
culture as a metaphor, which one machine family, jungle war zone,
something else, which one really feels like your organization? And
how does that unique culture shape the systems you use
every day or the ones you might be thinking about
building or adopting next. That alignment, that sweet spot between
(17:56):
the code and the culture, that's where true operational fees, ability,
and ultimately success is really found.
Speaker 2 (18:03):
Great point until next time, Keep analyzing those
Speaker 1 (18:05):
Systems and keep diving deep
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.