Two out of Three ain't bad!

Here's a great article that justifies my career choices of Systems Engineer and part time College Professorship. Money magazine and PayScale.com rated the top 50 careers with great pay and growth prospects. Systems Engineer is #1 and College Professor is #3. Nice.

Even better, the Systems Engineer article mentions the CSEP as a required certification for some jobs. Maybe I'll get more students for the CSEP preparation course I teach.

Only problem is they do place SE under Information Technology. This kind of bugs me to no end. I know IT requires SE but SE is more then IT. During my recent job search I kept getting recruiters asking for a more IT related System Engineering work, i.e. Do you know UNIX or JAVA? How good are your System administration skills in Unix, Linux, and/or Windows platforms? Do you have experience with VMware ESX server, Lab Manager, Virtual Infrastructure Client? Do you have the ability to write basic scripts using shell scripting or Perl?

I got so feed up I created a standard reply:

Thank you for the info but I'm not really an IT guy or software development guy. I help PMs and their Program Offices with the technical aspects of acquiring new systems and capabilities for DoD. Milestone Documentation, Architecture review, Requirement Tracability, Validation and Verification of requirements, test planning via TEMP development, etc. Look at chapter 4.1 of the Defense Acquisition Guidebook. That will give you a good understanding of what I do. Bottom Line is my strength is in Systems Engineering/Technical Advisory (SETA) work.

I know it's kind of snippy but it was the best way for me to deal with it.

Well I got to get back to work here at the Best Job in America. OORAH!

2009 ~ Busy year for a SE Scholar

Thing's have been busy for me lately -- extensive travel and a new job situation -- so it's been hard to keep this blog current. Here are few things since the last update:

(1) I was able to give lecture on the new DoD 5000.02 changes at the February INCOSE meeting. (My slides are here.)

My tenure as the Programs Director for our local INCOSE chapter has been fun. I've gotten a lot of great speakers.

Date	Topic (links in this column for the presentation material)	Presentation by(links in this column for the speaker bio)
11/18/09	The State of Graduate Level System Engineering Education	Peter Hoch, D.Sc.
10/21/09	Systems Engineering Opportunities in the Emerging PBL World	Michael “Bo” Gourley, DML
9/16/09	Essential elements of SE: What's the minimum needed for project success	David M. Fadeley, PE, PMP
8/19/09	Update: System Readiness Level for Defense Acquisition Programs	Eric Forbes
7/15/09	Where Is Systems Engineering in the SOA/EA Relationship?	Janalea M. Milford, CEA
6/17/09	Leadership Styles for Complex Adaptive Systems	Suzette S. Johnson
5/20/09	Status of Model Based SE in INCOSE	L. Mark Walker
4/15/09	Gathering Requirements in a Post-Modern World	Steven Edwards
3/18/09	DoD 5000.02 - Revolutionary Revamp	Paul Martin
2/18/09	Second Life Gets Systems Engineering	Robert Ostergaard
1/21/09	A Systems Approach To Engineering Investigations	Dr. Gareth Digby

So come on out to our Monthly dinner every third Wednesday night at JHU/APL from 5:30 - 8:00pm. It's a great networking opportunity.

(2) This October I'll be teaching Certified Systems Engineering Professional (CSEP) Preparation course for UMBC Training Center. Please register if you have any interest in getting your CSEP designation from INCOSE.

It's interesting to think that I started this blog years ago just to document my experience in getting my CSEP. I've come full circle as I try to help others get their certification as well.

Weapon Systems Acquisition Reform Act of 2009

A good friend of mine pointed me to this news item just now hitting the News circuits. Carl Levin, the Michigan Democrat who heads the Senate Armed Services Committee and senior Republican panel member John McCain of Arizona introduced bipartisan legislation, called the Weapon Systems Acquisition Reform Act of 2009, which would make it easier to kill weapons programs that spawn runaway development costs, while taking steps to improve competition in the heavily consolidated industry. If you read the Government Executive article you’ll find this great quote from Levin, "The key to successful acquisition programs is getting things right from the start with sound systems engineering, cost-estimating and developmental testing early in the program cycle." Can I get all my engineering friends to shout a hardy AMEN! But it gets better. The article also explains the “The Levin-McCain bill also would require Defense to:

• Re-establish systems engineering organizations and developmental testing capabilities.
• Introduce trade-offs between cost, schedule and performance early in the program cycle.
• Use prototypes more often, including competitive prototypes, to prove that new technologies work before attempting to produce them.”

Just as I pointed out in my blog post “SE to the rescue?” it will fall on the Systems Engineers to see this through. Are we up to the challenge?


By the way, it really is strange that this legislation is coming out just a few months after DoD revamped their Defense Acquisition Management System with a major update to DoD Instruction 5000.02, Operation of the Defense Acquisition System, dated December 2, 2008. It grew from 37 to 80 pages – that’s about 116%. It incorporates new policies that originated from a very active Congress from 2004 thru 2008, including six National Defense Authorization Acts (NDAA) for FY’s 2004 through 2009. The update includes a new emphasis on:

• Technology Development: This phase now includes a mandatory requirement for competitive prototyping of the system or key-system elements.
• Integrated System Design. This effort is intended to define system and system-of-systems functionality and interfaces, complete hardware and software detailed design, and reduce system-level risk. Integrated System Design includes the establishment of the product baseline for all configuration items.
• System Capability and Manufacturing Process Demonstration. This effort is intended to demonstrate the ability of the system to operate in a useful way consistent with the approved KPPs and that system production can be supported by demonstrated manufacturing processes.

All of this points to DoD’s desire to put a greater emphasis on doing Systems Engineering upfront and early. They even include an Enclosure 12 -- Systems Engineering -- which proclaims:

SYSTEMS ENGINEERING ACROSS THE ACQUISITION LIFE CYCLE. Rigorous systems engineering discipline is necessary to ensure that the Department of Defense meets the challenge of developing and maintaining needed warfighting capability. Systems engineering provides the integrating technical processes to define and balance system performance, cost, schedule, and risk within a family-of-systems and systems-of-systems context. Systems engineering shall be embedded in program planning and be designed to support the entire acquisition life cycle.

Don't these senators or staff read this stuff? Isn’t the Levin-McCain bill just preaching to the choir? Just wondering.

The Zune software bug -- What's a leap year?

On Dec 31st my Zune went into a coma. It wasn't pretty. It stayed in this perpetual start up screen. It didn't respond to any outward stimuli. And it turns out I wasn't the only one affected but every 30GB Zune player on the planet had the same problem. The geek press was a calling it the Zune Apocalypse.

Fortunately it was a short lived Apocalypse. The Zune software had "a bug in the internal clock driver related to the way the device handles a leap year. " Click here for a story about Microsoft's official response. Which basically says, "Wait 'till New Years officially gets underway and everything will go back to normal. " Which it did by the way. My Zune is back and happily providing me podcasts, like Radio Lab, for me to enjoy during my work commute.

But here's the best part of the Microsoft press release:

"... there was a widespread issue affecting our 2006 model Zune 30GB devices (a large number of which are still actively being used)."

The parentheses indicate to me that Microsoft is actually surprised, yes surprised, by the fact that many people would actually use the device for more then two years. --- A device these people spent more then $100 to own. -- Did Microsoft really think that customers would get tired of these things after a few months and get rid of them? What kind of short sighted development is that? And how does any software engineering team working on a internal clock not include leap year into their calculations??

This bug could have been caught and eradicated if the software went through a peer review. In the SE class I teach I explain that the two biggest Quality Control Points are:

• Peer Reviews
• Unit Test

These should be protected at all cost.

But even a peer review can fail if you don't have the knowledgeable and experienced programmers on the team in order to help catch errors or discover overlooked industry conventions. So I also emphasize to my students the heuristic: variations among people account for the biggest differences in software productivity. So always try to hire good people.