Slashdot Mirror

Johnson's biography is quite a good read--not going to win a Nobel prize in literature any time soon, but the content is a delight for aerospace engineers like me. Johnson WAS Skunk Works, for many many years.

Funny note about Rule 4: He's advocating version control for engineering projects. If he was alive today, I suspect Mercurial would give him a hard-on.

Rule 4: A very simple drawing and drawing release system with great flexibility for making changes must be provided.

Last point: It's funny how many of the 14 Rules are anathema to modern management practice, particularly as implemented by the dominant aerospace firms. I'm not saying you can solve all of the industry's problems by requiring 14 Rule adherence, but you'd come close, The parent post already mentioned Rule 14, and implied it's laughable contradiction with current pay-scales in the engineering industry; Rule 5 directly contradicts the micro-managed, hyper-documented approach for modern systems engineering standards. Rule 12 has been repeatedly blown away by deeply-ingrained contractor dishonesty w.r.t. pricing and scheduling estimates, and by contractees' fanatical devotion to requirements creep and abrupt project changes (although in fairness, the budgeting environment doesn't help things), and as a result it's hard to imagine that this kind of trust will ever again exist between the government and the large aerospace contractors. Rule 10 is also a victim of this phenomenon.

"Proper software engineering" does work, its called "Systems Engineering", is well established and successfully used for large-scale mission-critical projects in almost every industry outside of IT - which seems to be blind to anything invented outside of IT.

Systems engineering has its own professional accreditation organization: http://www.incose.org/practice/whatissystemseng.aspx

True, but the problem is when the Great Plan becomes too rigid. It's necessary to change it as warranted. This actually seems to be easier in hardware, when you say "sure I could get that last 1dB of dynamic range you wanted, but it'll double the price and power consumption", or "yes we could put that function in module X as planned, but it'd be half the cost and complexity if we move it to module Y". Good systems engineers know this. Of course the headache of being a systems engineer is fighting with the implementers - half the changes or spec relaxations they ask for make sense, and the other half are about laziness or incompetence.

I do hardware and software in a 50/50 split, so I see both sides. Hardware is more easily understood to have physical constraints, but every thing in software that isn't exactly as planned is seen as a failure of the implementers.

some PDFs (presentation slides) on Silicon Valley history:
http://ewh.ieee.org/soc/cpmt/presentations/cpmt1209a.pdf "The Origins of Silicon Valley: Why and How It Happened Here" Paul Wesling, IEEE SFBA Council (3.5 MB PDF). One particular slide has , "Tube Shops’ Challenges Design around ~250 RCA triode patents – Enormously difficult task (Samsung vs Apple case)"
http://www.incose.org/sfbac/2011events/111108Presentation-50YearsInSpace_v5.pdf "The Global Triggers in the Birth, Growth, and Challenges of System Engineering in Space and Internet" by Sam Araki. This also shows influence of government spending on recon satellites and how it drove chip manufacturers.

slides used by Sam Araki, http://www.incose.org/sfbac/2011events/111108Presentation-50YearsInSpace_v5.pdf

The INCOSE Tools Database Working Group (TDWG) has a Requirements Management Tools Survey: http://www.incose.org/productspubs/products/rmsurvey.aspx The responses are self-reported by the tool vendors, but they appear to be mostly accurate. This survey could help you choose between requirements management tools to help you find one that will fit your needs and your business style.

There's inexperienced developers, and there's experienced developers.

As a systems engineer for a gov contractor, I needed to make a survey for documentation revision control software. Due to my CS background, I immediately thought about CVS, sourcesafe, and other source code revision control packages. The source code revision control packages were not up to the task of documentation revision control. Since systems engineers deal with requirements, and requirments are stored via documentation, every requirements analysis package comes with documentation revision control software. These packages also help to create documents from templates and databases. Depending upon your needs, these documents keep track of customer requirements from concept through delivery/installation, into maintenance.

There are many systems engineering tools that handle requirements analysis in various ways. Many of them work with MS Office (prolly what your writers currently use), and have built in versioning control. My best source for information on these tools was at the INCOSE tools website. This sites lists tools and checks them for the following features...

Store standard document outlines - used as starting points? User definable templates or modifiable?

Produce architecture views from functional and object oriented (OO) perspectives? Examples: WBS, functional , physical, data flow, state diagrams

Support various physical architectures? (View from a number of levels, Black box, Rack, circuit board, chip)

Enable tailoring to specific standards and requirements, IEEE, ISO, MIL-STD?

User friendly & menu driven (drag and drop capabilities)?

Support a single user or multiple concurrent users?

Input document change / comparison analysis

Visibility into existing links from source to implementation--i.e. follow the links.

History of requirement changes, who, what, when, where, why, how.

Baseline/Version control

Access control (modification, viewing, etc.)

. Support of concurrent review, markup, and comment

Multi-level assignment/access control
Plus many more features.

It is my opinion, that the following packages are up to the task:

Cradle

Doors

rtm

rdt

Caliber rm

If you go the page that I linked, it provides an in depth review of each of these tools plus many more.

Dun dun dun. Crash course in Managing Software(and hardware) Development. There are millions of links out there. So here's an introduction so people know what to look for. Remember, there is no magical model that automatically works!
---
This is why you learn different management in software development models, because there is no one model that suits everyone. There are generally held principles that anyone can come to, but they aren't solutions that you can work out by common sense.

Here are some general statements:

"Software development is multi-dimensional."

OK, duh.

"Developers pay attention to what they are measured on"

OK, that makes sense. People _respect_ what management _inspects_.

"Some performance dimensions in software may be in conflict"

Makes sense, although a little more complex. (e.g., min memory, min SLOC vs. min effort and max user satisfaction vs max maintainability...)

Objectives in managing software development:

* define the process by which projects are conceived approved, and delivered
* define the guidelines and standards that are used by architects, developers and managers who will develop software
* define the mechanisms used to deliver the software to the marketplace
* general models to develop specific models in particular niche's such as "shrink wrapped" or "web based" or "b2b" or "b2c" or "OEM" etc
* define who is involved (e.g., product management, project management, development, technical writers, human factors/ui, localization etc) and their roles and their tasks.
* Specifications documents should follow these definitions and management models such as that for cost estimation (e.g., COCOMO, other models).
* once tasks are defined, you can help employees do what they are supposed to and evaluate them for future changes to development model

Interesting links:
a n article
The CMU software engineering institute
more
Defense system management college introduction to project management
wooha lots of links.
needed skepticism regarding empirical analysis with models!!!
"Commercial software models"

Example of cost estimation in use (findings from them at least):
http://www.ll.mit.edu/llrassp/jca/mcmb w.html

_Development models_ include (*== > in double sided->):

The incremental model;

AKA. The market model. Often dictated by management and generally follows QA builds.

(P.1)()()()()(1.0)()()()...(2.0)..

The evolutionary model;

AKA. The pseudo academic model

(Product Idea)*-*(Prototype)->(Clean Code)->(test and rinse)->(evolve)->(repeat)

The spiral model:

This model makes you ask the question as to the value of functionality and what process one would take in implementation.

(Kernel)->(Kernel+key or riskiest functionality)->(kernel+key+less troublesome components)->(K.+key+LTC+Less troublesome functionality)

Waterfall Model:

Intent:

(Product Idea)->(Analysis)->(Design)->(Implementation)->(te sting)->(Product life)

Reality:

(PI)*-*(Analsysis)->(design)*-*(implementation)* -*(testing)->(product life)*[arrows back to design and analysis]

Rapid Prototype model:

(product idea)->(prototype & analysis & design)->(implementation)->(testing)->(product life)

Common misuse:

(Product Idea)->(Prototype)->(More Code)->(Test)->(release)

etc, and hybrids like the "extreme programming" model, which seems to be a more detailed rapid prototype model

_Requirements methodologies_:

* generally: Requirements are what. Specifications are how (although they mix).

Incorrect requirements = no product, or bogus development plan

The method from which we develop requirements is:

discovery
refinement
modeling
specifications

requirements elicitation(href="http://www.se i.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf ) -- more detail (http://www.incose.org/rwg/97panel/97 panel.html) - etc - (http://www.kingst on.ac.uk/~ma_s435/personal/work/CO1032B/tools_5/)

How to defend against requirements crep:

* use formal methods !
* use customer requirements formats such as manuals or other docs !
* your answer must not always be yes !
* proposed changes must be evaluated and rational !
* there is always nearly a version 2.0 !
* the customer almost always values quality over a short delay !
* remain flexible enough to react to the work-place !

"without a manual, we don't have a product".