CSDP Driven

I have heard and tried to use Design Patterns ever since (and maybe before) the Gang of Four book. I have read and used Peter Coads pattern book, as well as using his Together product before it was bought by Borland. One of my more useful books was “Applying UML and Patterns” by Graig Larman. I continue to read and try to implement patterns in my work. However, I still haven’t got the hang of it. Just using good object-oriented techniques and using existing published code as templates doesn’t seem like a long term solution.

At the last conference, I attended a tutorial by Alan Shalloway of NetObjectives and bought his book; “Design Patterns Explained”. I have high hopes that this book will be that key that unlocks the design patterns concept. Having just read the preface, Alan had a become a very good object-oriented designer, and had learned about design patterns. The promise of his book, is that he will teach you how to apply patterns and learn why they work and how they work together.

I think I had a similar experience learning object-oriented coding – you struggle to understand why while you implement the techniques until at some point in time you cross over the chasm and realize what all the theory is about. There are two ways this happens, trial and failure, and/or instruction. This time maybe I can use this book to avoid some of those trials!

BTW, if you ever have a chance to attend a tutorial or read a book/article by Alan Shalloway, I highly recommend taking the time.

Allen

Competitive Engineering:A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage
ISBN 0750665076 Publisher: Elsevier Butterworth-Heinemann by Tom Gilb.

I bought this book after taking Tom Gilb’s Tutorials at a conference in 2006. The conference was quite good, and I (along with others) was able to spend some time with a wonderful person. He is that unique person, which has a profound effect on your life. The book could be classified as a reference work, but it also presents concepts by building on previously introduced ideas. So I suppose it is a textbook that then becomes a reference book. The book introduces Tom’s “Planguage”, which clearly and unambiguously communicates management objectives and systems engineering requirements. To quote further from the book cover; Competitive Engineering encompasses Requirements Specifications, Design Engineering, Evolutionary Project Management, Project Metrics, Risk Management, Priority Management, Specification Quality Control, and Change Control.

I think that sums it up quite well, but I will give you some of my thoughts. Each page of the book can be a template for managing the entire Software Engineering life cycle. It defines concepts of the Planguage using Planguage. It gives guidance on how to use the different concepts, as well as how to combine the concepts into larger concepts. Planguage was designed to be specific yet flexible, just like the Software Engineering discipline. Just like Design Patterns, CE gives you a tool, that you can modify and custom fit to your environment, yet with a little explanation anyone can read, understand and use. I am still reading and learning from the book.

Tom has a number of interesting ideas and techniques, which anyone would do well to investigate. After all, there is no magic incantation or secret sauce that can produce good software, only tools and techniques t hat when properly used and applied, can help us deliver what the customer really needs and wants. I highly recommend this book as one of those resources.

Allen

How does one manage Software Engineering?

In this case, I am defining “manage” as more than just a manager and controlling projects. How does one (individual, team, or manager) decide what is a good process to follow, or which SE principle applies? First I think that experience is the number one factor. Experience can compare the principle, process, or technique to similar instances and can suggest the probability of the outcome. I think this is also why most projects fail – somewhere in the chain of people and events, someone either ignored the past or could not do the comparison(maybe they had no experience). I know I have been involved with this issue on too many projects!

How does one gain this experience? You either pay the price to hire an individual with it, or you pay the price to develop it. Given a foundation of some level of experience, I think the next level (I will keep this vague in this discussion) can be obtained through study; reading, discussions, conferences, or courses. And of course I believe, based upon my own experiences, that experience develops better in a group rather than as an individual. In fact this may very well be why I believe in attending conferences.

For those that haven’t checked out the requirements of the IEEE CSDP, the application requires documention of at least a minimum of 9,000 hours of software engineering experience within at least six (6) of the eleven (11) knowledge areas.

I. Professionalism and Engineering Economics
II. Software Requirements
III. Software Design
IV. Software Construction
V. Software Testing
VI. Software Maintenance
VII. Software Engineering Management
VIII. Software Configuration Management
IX. Software Engineering Process
X. Software Engineering Tools and Methods
XI. Software Quality

The number of hours on the Report of Experience and Education Form must total at least 9,000 hours and software engineering assignment dates must indicate that the candidate has at least two (2) years of software engineering experience within the four-year (4) period prior to the application.

Allen