Unlocking the Power of ChatGPT and AI in Testing - A Real-World Look, present...
Building Dependable Software
1. Building
Dependable Software
Strategic technology advice
for building dependable business-critical software
Dr. Jayaraj Poroor
http://jayaraj.poroor.com
2. Overview
The land of
requirements
The land of
dependable software
The gap needs to
be filled by
employing the
right technology
strategies.
● Architecting
● Analysis
● Feasibility Studies
● Prototyping
Semantic gap
between
requirements and
dependable code.
3. Bugs vs Strategic Mistakes
● It will take a lot of bugs to kill a typical
software - but a single strategic mistake
is enough.
4. FBI’s Virtual Case File project
$170 million project scrapped
700,000 lines of unusable code written
“The [VCF] architecture was developed without adequate
assessment of alternatives and conformance to various
architectural standards.”
Assessment Report by Aerospace Corp.
[IEEE Spectrum]
5. What is Software Architecture?
A complex jigsaw that connects together
frameworks, libraries, modules, data stores,
platforms, app servers into a robust system.
●
6. Functional vs Non-functional
requirements
Functionality is only a part of the puzzle.
Stability Extensibility Performance
Security Scalability
Domain
Functionality
7. Good vs Bad Architecture
A system that can
collapse any time
A system that can
gracefully handle stress
vs
● load
● attacks
● changes
9. Data architecture is especially
important
“Show me your flowcharts and conceal your tables, and I
shall continue to be mystified. Show me your tables, and I
won't usually need your flowcharts; they'll be obvious.”
Fred Brooks
Computer Pioneer & Turing Award* Winner
* Turing Award is Computer Science equivalent of Nobel Prize
10. Data Architecture: Good vs Bad
System
Requirements
Wrong Data Architecture
System
Requirements
Right Data Architecture
vs
11. Not all application data are equal
Basic
Domain
Data
Time-tagged
Log Data
Relationship
Data
Unstructured
Text
Session
Data
The same application may have diverse data requirements.
12. Force fit all data into the same
data store?
● Poor performance/scalability
● Complex application code
○ Slow/buggy
Application’s diverse data
requirements.
A single data store won’t fit all
requirements
13. Hybrid Data Architecture
● Use the right kind of data store for each
different kind of data requirement.
16. Choices are many!
Ruby on
Rails
Groovy
on Grails
Express
(Node.js)
Spring
CakePHP
Client-side
frameworks, e.g.
AngularJS
17. Security: Protect your precious data!
Security incidents result in serious financial losses
and lost credibility
Cross-site
Scripting
XSRF
SQL
Injection
Use of
Vulnerable
Libraries
18. Rework is costly
● Architectural mistakes are strategic
mistakes - costly to correct
○ e.g., migrating from a bad framework or
migrating to a new data store.
● Investment in architecture will save you
time, money, and your reputation
tomorrow
19. Strategic decisions must be
based on hard data
“In God we trust; all others must bring
data.”
Edward Deming*
*The man behind Japanese post-war industrial revolution
21. Performance & Scalability
“Premature optimization is the root of all evil.”
Don Knuth.
● Scalability is important but not everyone
needs to be Google or Twitter.
○ Over-architecting can be expensive.
○ Under-architecting can be disastrous.
22. Performance & Scalability
1. Study Requirements.
2. Start with a simple architecture.
3. DO
Model the architecture, simulate (in AWS
with actual VMs), and collect performance
data.
Identify bottlenecks.
Incrementally modify the architecture.
ITERATE UNTIL
PERFORMANCE IS
SUFFICIENT
23. Choosing the right framework
You’re unsure whether to really go with
framework A, B, C, or D?
How to decide? Roll a dice?
27. Using an insecure library?
Analysis should reveal whether libraries,
frameworks, platforms you are using have any
serious security issues.
28. Technology Feasibility Study
When you explore fresh & challenging application
domains feasibility study report will be your map.
29. Technology Prototyping
Nothing beats building an actual prototype when
exploring new & challenging domains.
“I do and I understand.” “The map is not the territory.”
- - Confucious