Archive
Viable, Vulnerable, Doomed II
As the title indicates, this blow-sst is an extension of yesterday’s inane blabberfest. While yesterday’s lesson (<— lol!) dealt with the static structure of Viable, Vulnerable, and Doomed (VVD) orgs, today’s BS-fest talks about the dynamic behavior of VVD social groups. Behold that if you’re conscious and you concentrate on observing the world around you, the structure plus behavior of an org will clearly and unambiguously reveal over time what it does. Forget what its so-called leaders say it does, observe for yourself how the stratified monolith is structured, how it behaves, and what it actually produces. If you’re diligent and astute, you’ll discover the principle of POSIWID: the Purpose Of a System Is What It Does (not what it’s leadership says it does).
The UML diagram below shows a state machine model of: the mutually exclusive states of a VVV system, the transitions between the states, and the events that trigger the transitions. But wait…… VVV? What happened to VVD? Well, in a dumbass attempt to inject levity and fruitlessly retain your interest, I changed the name of the “Doomed” state to “”Vucked” so that all states start with the letter “V”. Stupid, no?
Virtually all startup companies initialize into the viable state. After all, if they didn’t have a product or service that a market didn’t want to consume, they wouldn’t be born as a viable entity, right? Over time, if they neglect their explorers and single mindedly, greedily, milk their product/service to death, eventually they’d become vulnerable to competitors. If the leadership becomes drunk with success and their heads expand too far, they start resenting and rejecting their explorers – they become vucked!
Unless, as the figure below shows, an epiphany in the head shed occurs (and the chances of that occurring in fat headed executives rolling in dough are incredibly slim) it’s death to the org and all its membership – including the innocents who had no hand in the implosion. This ain’t a hollywood story so there’s no happy ending.
Rules, Exceptions, Guidelines
Unlike natural laws (on the macroscopic level) which unremorsefully allow no exceptions, I think all human concocted rules should be flexible to exceptions, no? If you believe that, then maybe the word “rule” should be replaced with “guideline”. Doing this can be interpreted as splitting hairs, but I think it may positively affect those who are required to operate by the “rules”. It shows respect and implies that some freedom is allowed to continuously improve things. Since the yearning for freedom is built into the fiber of every human being, those in positions of authority who conjure up the “rules” should take heed.
Note: The model above is a UML “class diagram”, which is used to depict the static structure of a system. Other UML diagrams can be used to model the behaviors of a system. The diagram can be interpreted as follows:
- A bureaucracy has NUM_BMS BMs and NUM_DICS DICs and a Rule Book.
- The BMs make the rule book, which has NUM_RULES (usually a boatload) rules.
- The DICs are obliged to follow the rules, written or unwritten (but understood) – or else.
Jumpin’ Out
If you’re deeply embedded in a complex social system, it’s incredibly difficult to gain any insight into what the system you’re enmeshed in really does, or how it does what it does. Even though you’re an integral element of the system, your view is most likely obscured by your lack of interest in finding out or, more likely, by a lack of communication from the dudes in the penthouse. All you can see are trees. No forest, and no sun above the treetops.
A great way of “jumping out of the system” to get a better view and understanding is by modeling. By taking a stab at modeling the static structures and dynamic behaviors of the system you’re in, you can get a much better feel for what’s going on.
A formal language like UML or SysML paired with a good visual drawing tool like Visio can be a powerful tool set to help you gain perspective, but all you really need is a pencil and paper to start things off. Since your first few iterations will suck and be totally wrong, you’ll be throwing away lots of wood pulp if you don’t use an electronic tool. If you stick with it, you’ll acquire an understanding of what really happens in your system as opposed to what is espoused by those in charge.
All models are wrong, but some are useful. – George Box
Hold The Details, Please
When documenting software designs (in UML, of course) before, during, or after writing code, I don’t like to put too much detail in my models. By details, I mean exposing all public/protected/private data members and functions and all intra-member processing sequences within each class. I don’t like doing it for these reasons:
- I don’t want to get stuck in a time-busting, endless analysis paralysis loop.
- I don’t want a reviewer or reader to lose the essence of the design in a sea of unnecessary details that obscure the meaning and usefulness of the model.
- I don’t want every little code change to require a model change – manual or automated.
I direct my attention to the higher levels of abstraction, focusing on the layered structure of the whole. By “layered structure”, I mean the creation and identification of all the domain level classes and the next lower level, cross-cutting infrastructure and utility classes. More importantly, I zero in on all the relationships between the domain and infrastructure classes because the real power of a system, any system, emerges from the dynamic interactions between its constituent parts. Agonizing over the details within each class and neglecting the inter-class relationships for a non-trivial software system can lead to huge, incoherent, woeful classes and an unmaintainable downstream mess. D’oh!
How about you? What personal guidelines do you try to stick to when modeling your software designs? What, you don’t “do documentation“? If you’re looking to move up the value chain and become more worthy to your employer and (more importantly) to yourself, I recommend that you continuously learn how to become a better, “light” documenter of your creations. But hey, don’t believe a word I say because I don’t have any authority-approved credentials/titles and I like to make things up.
ICONIX SysML Training Preview
During the week of January 25-29, I, along with 19 other enginerds will be attending a SysML training course given by Doug Rosenberg of ICONIX. At this point in time, I think the specific course is named “SysML JumpStart Training with Enterprise Architect“. I love the following “no-candyasses-allowed” warning at the bottom of the web page:
JumpStart Training is not a class for uncommitted students or uneasy beginners. Because of the rapid-learning atmosphere, JumpStart Training is ideal for those looking for an intense and highly-focused training course which will get the project up and running, fast!
I’m grateful for the opportunity and excited to attend the course because I’m a big fan of both the UML and its SysML profile. Over the past several years, I’ve been teaching myself at a leisurely pace how to apply these two increasingly important technologies to the software design and specification work that I do.
Because of the powerful and sprawling nature of the UML family, unless you’re an Einsteinian genius, it’s my uncredentialed opinion that you can’t learn UML or SysML overnight. The symbology, syntax, and semantics of the languages are rich and necessarily complex because they’re designed to tackle big hairball software-centric systems problems. Based on my personal experience, I don’t think very many people can acquire a deep understanding of the UML’s 13 diagrams or SysML’s 9 diagrams in 5 days, but you gotta start somewhere and formal training is a good start. We’ll see how it goes.
While surfing the ICONIX web site, I stumbled upon this “MDG Technology For DDS” page (MDG = Model Driven Generation, DDS = Data Distribution Service). Interestingly, there seems to be no equivalent “MDG Technology For CORBA” page on the ICONIX web site. It’s interesting because I’m currently fighting a CORBA vs DDS battle in house. It’s even more interesting in that this InformIT author page states that Doug Rosenberg has previously developed and taught a CORBA class. I’ll be sure to ask Doug about this anomaly when I meet him.
Requirements Before, Design After
The figure below depicts a UML sequence diagram of the behavior of a simulator during the execution of a user defined scenario. Before the code has been written and tested, one can interpret this diagram as a set of interrelated behavioral requirements imposed on the software. After the code has been written, it can be considered a design artifact that reflects what the code does at a higher level of abstraction than the code itself.
Interpretations like this give credence to Alan Davis’s brilliant quote:
One man’s requirement is another man’s design
Here’s a question. Do you think that specifying the behavior requirements in the diagram would have been best conveyed via a user story or a use case description?
Shallmeisters, Get Over It.
If you pick up any reference article or book on requirements engineering, I think you’ll find that most “experts” in the field don’t obsess over “shalls”. They know that there’s much more to communicating requirements than writing down tidy, useless, fragmented, one line “shall” statements. If you don’t believe me, then come out of your warm little cocoon and explore for yourself. Here are just a few references:
http://www.amazon.com/Process-System-Architecture-Requirements-Engineering/dp/0932633412/ref=sr_1_3?ie=UTF8&s=books&qid=1257672507&sr=1-3
With the growing complexity of software-intensive systems that need to be developed for an org to remain sustainable and relevant, the so-called venerable “shall” is becoming more and more dinosaurish. Obviously, there will always be a place for “shalls” in the development process, but only at the most superficial and highest level of “requirements specification”; which is virtually useless to the hardware, software, network, and test engineers who have to build the system (while you watch from the sidelines and “wait” until the wrong monstrosity gets built so you can look good criticizing it for being wrong).
So, what are some alternatives to pulling useless one dimensional “shalls” out of your arse? How about mixing and matching some communication tools from this diversified, two dimensional menu:
- UML Class diagrams
- UML Use Case diagrams
- UML Deployment diagrams
- UML Activity diagrams
- UML State Machine diagrams
- UML Sequence diagrams
- Use Case Descriptions
- User Stories
- IDEF0 diagrams
- Data Flow Diagrams
- Control Flow Diagrams
- Entity-Relationship diagrams
- SysML Block Definition diagrams
- SysML Internal Block Definition diagrams
- SysML Requirements diagrams
- SysML Parametric diagrams
Get over it, add a second dimension to your view, move into this century, and learn something new. If not for your company, then for yourself. As the saying goes, “what worked well in the past might not work well in the future”.
I’m Finished
I just finished (100% of course <-LOL!) my latest software development project. The purpose of this post is to describe what I had to do, what outputs I produced during the effort, and to obtain your feedback – good or bad.
The figure below shows a simple high level design view of an existing real-time, software-intensive, revenue generating product that is comprised of hundreds of thousands of lines of source code. Due to evolving customer requirements, a major redesign and enhancement of the application layer functionality that resides in the Channel 3 Target Extractor is required.
The figure below shows the high level static structure of the “Enhanced Channel 3 Target Extractor” test harness that was designed and developed to test and verify that the enhanced channel 3 target extractor works correctly. Note that the number of high level conceptual test infrastructure classes is 4 compared to the lone, single product class whose functionality will be migrated into the product code base.
The figure below shows a post-project summary in terms of: the development process I used, the process reviews I held, the metrics I collected, and the output artifacts that I produced. Summarizing my project performance via the often used, simple-minded metric that old school managers love to use; lines of code per day, yields the paltry number of 22.
Since my average “velocity” was a measly 22 lines of code per day, do you think I underperformed on this project? What should that number be? Do you summarize your software development projects similar to this? Do you just produce source code and unit tests as your tangible output? Do you have any idea what your performance was on the last project you completed? What do you think I did wrong? Should I have just produced source code as my output and none of the other 6 “document” outputs? Should I have skipped steps 1 through 4 in my development process because they are non-agile “documentation” steps? Do you think I followed a pure waterfall process? What say you?
Standard CCH Blueprint
The figure below is a “bent” UML (Unified Modeling Language) class diagram of a standard corpo CCH (Command and Control Hierarchy). Association connectors were left off because the diagram would be a mess and the only really important relationships are the adjacent step-by-step vertical connections. Each box represents a “classifier”, which is a blueprint for stamping out objects that behave according to the classifier blueprint. The top compartment contains the classifier name, the second compartment contains its attributes, and the third compartment houses the classifier’s behaviors. Except for the DIC Product Development Team, the attributes of all other classifiers were elided away because the intent was to focus on the standard cookie-cutter behaviors of each object in the “system”. Of course, the org you work for is not an instantiation of this system, right?
Useless Cases
Despite the blasphemous title of this blarticle, I think that “use cases” are a terrific tool for capturing a system’s functional requirements out of the ether; for the right class of applications. Nevertheless, I agree with requirements “expert” Karl Wiegers, who states the following in “More About Software Requirements: Thorny Issues And Practical Advice“:
However, use cases are less valuable for projects involving data warehouses, batch processes, hardware products with embedded control software, and computationally intensive applications. In these sorts of systems, the deep complexity doesn’t lie in the user-system interactions. It might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system’s behavior.
I help to define, specify, design, code, and test embedded (but relatively “big”) software-intensive sensor systems for the people-transportation industry. The figure below shows a generic, pseudo-UML diagram of one of these systems. Every component in the string is software-intensive. In this class of systems, like Karl says, “the deep complexity doesn’t lie in the user-system interactions”. As you can see, there’s a lot of special and magical “stuff” going on behind the GUI that the user doesn’t know about, and doesn’t care to know about. He/she just cares that the objects he/she wants to monitor show up on the screen and that the surveillance picture dutifully provided by the system is an accurate representation of what’s going on in the real world outside.
A list of typical functions for a product in this class may look like this:
- Display targets
- Configure system
- Monitor system operation
- Tag target
- Control system operation
- Perform RF signal filtering
- Perform signal demodulation
- Perform signal detection
- Perform false signal (e.g. noise) rejection
- Perform bit detection, extraction, and message generation
- Perform signal attribute (e.g. position, velocity) estimation
- Perform attribute tracking
Notice that only the top five functions involve direct user interaction with the product. Thus, I think that employing use cases to capture the functions required to provide those capabilities is a good idea. All the dirty and nasty”perform” stuff requires vertical, deep mathematical expertise and specification by sensor domain experts (some of whom, being “expert specialists”, think they are Gods). Thus, I think that the classical “old and unglamorous” Software Requirements Specification (SRS) method of defining the inputs/processing/output sequences (via UML activity diagrams and state machine diagrams) blows written use case descriptions out of the water in terms of Return On Investment (ROI) and value transferred to software developers.
Clueless Bozo Managers (BMs) and senior wannabe-a-BM developers who jump on the “use cases for everything” bandwagon (but may have never written a single use case description themselves) waste company time and money trying to bully “others” into ramming a square peg into a round hole. But they look hip, on the ball, and up to date doing it. And of course, they call it leadership.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 