Developing secure software. Was: Re: [Dshield] DCOM morning after

Jon R. Kibler Jon.Kibler at aset.com
Thu Aug 14 18:02:25 GMT 2003


Kenneth Porter wrote:
> 
> --On Wednesday, August 13, 2003 10:44 AM -0400 "Jon R. Kibler"
> <Jon.Kibler at aset.com> wrote:
> 
> > Developing far less buggy software than is commonly seen today can be easily
> > done. The technology to do so has been available since the early 1970s.
> 
> So what's the magic (if expensive) pill? (Pointers to web pages would be fine.)
> 

Here are some starting points for learning more about Systems and Software Engineering standards and best practices. This is not a complete list by any means. For example, I don't have a good direct reference on Configuration Management (CM is NOT the same as "software version control"!), which is CRITICAL for ANY successful development effort (hardware or software).

Let me also say that good systems development practices requires a MAJOR mindset change in any organization for it to be successful. A story from personal experience illustrates...

I used to teach Requirements Engineering to various Silicon Valley defense contractors' systems and software development organizations. These were usually one to three week classes. The classes usually consisted of project engineers, managers, and senior software developers. The engineers and managers were usually 'old-timers' that had been with the company 'forever.' However, the software types were usually fairly new hires that did not have any background or experience in formal development methods. 

The engineers and managers just loved having available the formal reproducible processes for controlling development that were taught in these classes. The bit-herders, err... I mean software engineers (I can poke fun at them, because at one time I was one), were far less enthusiastic. Usually, by the beginning of the third day, the software types would start complaining "Why do we need all these written requirements, design models, test plans, and other documentation? We have some idea what the customer wants, why can't we just start writing code?". Answer: Because without all this paper work, you really cannot say exactly what it is the customer wants, and exactly how it works. Plus, you have no way to prove what you produce is exactly what the customer said they needed. In addition, these methods impose quality standards on all development activities that result in highly reliable products.

(I should add that most of these projects had over 50,000 functional requirements, over 1,000,000 design constraints, and over 2,000,000 implementation constraints for systems hardware and software. Most of these systems were 10 to 20 or more million lines of code.)

It usually took a couple of years for the software types to start to understand and appreciate "all the paper work" that formal methods require -- and it only started to sink in when they saw that they were able to produce systems that worked first time. Turn over in software departments were always high, because so many programmers resented peer review and complained that standard ways of doing things cramped their creative style.

So, end of story. Moral: Improving software quality takes a MAJOR change in both the way systems are developed and people's attitude regarding quality verses creativity.


Here are the starting references...

Organizations:
==============
International Council on Systems Engineering
        http://www.incose.org/

Software Technology Support Center
        http://stsc.hill.af.mil/

Software Engineering Institute
        http://www.sei.cmu.edu/

IEEE Computer Society
        http://www.computer.org/

Project Management Institute
        http://www.pmi.org/info/default.asp



Standards and Similar Docs:
===========================
Guidelines for Successful Acquisition and Management of Software Intensive Systems
        http://stsc.hill.af.mil/resources/tech_docs/gsam3.html
Standard IS0-12207
Standard EIA/IEEE J-STD-16
IEEE Software Engineering Standards Collection
All standards given on above on above organization's web sites
DSMC Systems Engineering Management Guide
DSMC Mission Critical Computer Resources Management Guide
DSMC Risk Management Concepts and Guidance
DSMC Embedded Computer Resources Management Guide
DSMC Test and Evaluation Management Guide
DSMC Subcontracting Management Handbook
DSMC Integrated Logistics Support Guide
DSMC Manufacturing Management Guide for Program Managers
Clean Room Software Development Guidelines (I don't have a reference immediately available)

DSMC = Defense Systems Management College. Many of these pubs are out of print, but most still give GREAT Guidance. I use the SE, RM, and T&E guides regularly.

Probably the best guide for management is STSC's S/W Intensive Systems guide.

Developing successful systems depends on following documented standards and practices. SEI certification shows that an organization has good processes in place, and provides a good measurement of how successful an organization will be in producing quality software.


Books:
======
Just about anything written by the following authors should provide good insight:
   Barry Boehm
   Ivar Jacobson
   James Rumbaugh
   Capers Jones
   Ed Yourdon
   Grady Booch


Not exactly on topic, but should be required reading for anyone in the IT industry are:
   PeopleWare by DeMarco & Lister (The politics of an office organization)

   The Mythical Man Month by Brooks (Explains to managers why if one woman can produce a baby in 9 months, why 9 women cannot produce a baby in a single month.)


Hope this helps! Feel free to contact me off list if you would like some more info.

Good Luck!

Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA




More information about the list mailing list