Useful Use Cases

Requirements elicitation and representation is always difficult, especially when the results need to be understood by two potentially diverse populations: the stakeholders (users, management, customers, ...) and the architects, designers and developers of the system. Use cases, emphasizing scenarios, are a great middle ground for representing large hunks of the requirements in a style that is both understandable to the stakeholders and specific enough for the technical community charged with architecting, designing and implementing them.

Use cases were introduced by Ivar Jacobson in his book, Object-Oriented Software Engineering: A Use Case Driven Approach, ISBN:0201544350. However, if you are not ready to purchase the book for $60, a great free resource on Use Cases is Rebecca Wirfs-Brock's OOPSLA 2002 tutorial, The Art of Writing Use Cases. You can download a copy of it here. Wirfs-Brock's site is an excellent resource for many OO requirements, design and architecture topics. Definitely worth browsing.

If any one has had experience using Use Cases or knows of further resources, I would appreciate it if you would add a comment. Later.

Reliable Advice

Attached is a description of the new edition of John Musa's book, Software Reliabilitiy Engineering: More Reliable Software Faster and Cheaper. Thanks to Professor Bernstein for forwarding John's notice to me. Software reliability is one of the key "ilities" (along with usability, enhance-ability, ...) of interest when developing a software architecture. John's book has been a classic in this area and provides the reader with tons of practical advice and even free software to deal with software reliability issues.

Has anyone else used or read Musa's book? I would be interested in your comments. Later!

Musa's description of the book:

The new edition of "Software Reliability Engineering: More Reliable Software Faster and Cheaper," now available, focuses on making software practitioners more competitive without working longer. This is a necessity in a world of globalization and outsourcing where professionals want more time for their personal lives.

John D. Musa has written what is essentially a new book. It reflects the latest software reliability engineering (SRE) practice. Reorganized and enlarged 50% to 630 pages, the material was polished by thousands of practitioners in the author's classes at a wide variety of companies worldwide.

One of the book's new features is a series of workshops for applying each area that you learn to your project. The frequently asked questions (answered, of course) were doubled to more than 700. All the popular features of the previous edition have been updated and rewritten. These include the step-by-step process summary, the glossary, the background sections, and the exercises. The user manual for the software reliability estimation program CASRE, downloadable at no charge from the Internet, reflects the latest version. The list of published articles by SRE users of their experiences now numbers more than 65. Everything is exhaustively indexed to make the most detailed topic easily accessible to those using it as a deskside reference.

The book separates basic practice from special situations for faster learning. Musa presents the material in a casual, readable style, with mathematics placed in separate background sections. All this was done to make the book especially effective for self learning. It also furnishes everything you need to implement SRE in your organization, even discussing the most effective methods of how to persuade people to adopt the practice.

One of the first Print on Demand (POD) professional books, it is coupled with a web site where you can browse and order the book. The web site has a complete detailed Table of Contents and extensive samples from the book that simulate the bookstore browsing experience. POD uses the latest automated technology to custom print each order and ship it anywhere in the world. It is as fast as you can obtain a traditionally published professional book. The cost is similar. POD technology makes it economic to keep the book in print for as long as even a handful of people want it.

Musa is one of the founders of the field of software reliability engineering. He is an IEEE Fellow and is Engineer of the Year in 2004. Listed in Who's Who in America since 1990, Musa is a prolific researcher, international consultant and teacher, and experienced and practical software developer and manager. ACM Software Engineering Notes noted for the first edition, "The author's experience in reliability engineering is apparent and his expertise is infused in the text."

The book, published by AuthorHouse, comes in hard cover and paperback editions. It contains 630 pages, including prefaces and appendices.

First and Second Contact

I often provide pointers to free resources on the web. In one of my latest wanderings I discovered a treasure of information on the NATO conference that literally began software engineering! It has the pdf's of the first and second NATO conferences on software engineering in 1968 and 1969 -- the documents that began software engineering. You can find this remarkable collection here.

Thanks to Brian Randell (one of the original editors) and the University of Newcastle Upon Tyne for scanning and hosting these documents. Brian also provides a retrospective and some incredible pictures of the staff and luminaries that attended the conference. Future posts will delve into these documents.

Later.

Software Infrastructure

In the past few years I have a consistent analogy for the changing perception of software in corporations. Software has gone from being considered as the paint on the walls of the building, changed every few years, to the building itself, part of the long term assests of the company. This changes the approach to current software from a philosophy of replacement to a philosophy of maintenance. It also should change the approach of building software from one of knee jerk response to today's need to careful planning, architecting and designing of an entity that will be around for decades.

The rhetoric of the software industry has changed to match the perception. For instance, we now talk of trustworthy software. However I do not believe the practice of software matches the rhetoric. Others agree. Fernando Pereira has referred me to an article by Dan Bricklin titled, "Software that lasts 200 years." In the article Bricklin discusses the changes necessary for prepackaged software to meet these longevity aspirations. I highly recommend the article and would be interested in your opinions both of the article and whether you feel that the software industry and the software engineering community are addressing these challenges. Later!

A side note - Fernando Pereira, has a terrific web log called Fresh Tracks where he discusses an amazing array of topics including skiing, books, science and music. Highly recommended. Fernando is chairperson of the Computer and Information Science Department of the University of Pennsylvania.

Measure twice, cut once!

Dennis Lowary's Log Book entry presents a case study of programming in the small (one person) on a short duration project. He tried to use some software estimation and requirements techniques but abandoned them early, because he felt it was too much overhead for the project. In the end, he felt the project did not turn out quite like he intended and wondered if he too hastily abandoned a software engineering discipline.

There is an old carpentry saying, "Measure twice, cut once!" Meticulous attention to upfront detail makes the project go easier. What carpenters knew centuries ago is great advice for us, but does current software engineering practice "scale down" to small projects or do we need to revise them significantly? What do you think or, better yet, what have you experienced? One thing is sure, we need more case studies and data to understand what does and does not work! Later!

Dennis Lowary's Log Book entry:

My entry is about thoughts I had while working on a recent project.

Courses like this focus on projects of long duration (months and years of work for a group of people). Can the theories discussed be applied to situations that are significantly smaller in magnitude? What should/could be done under the following conditions:

You’re told: “Create a database-driven website of some useful functionality”

You have:

* 14 days starting now

* A single-person staff (yourself)

* Very limited, or no experience with the languages you must use

* No advanced tools

With such a short time frame, is it possible to apply anything discussed in this course such that it is a

benefit? This was something I considered recently while working on this project. After choosing an overall function for the site, I attempted to create a set of requirements. Part of the deal was I had to state specific aspects of the intended functionality and once stated they had to be completed. I needed to not make it too simplistic, but a big concern was not to say I would do something that I couldn’t. I don’t have an enormous amount of experience with coding, but I have enough to know that something I might think simple on paper may be unforeseeably difficult to implement.

I considered trying to create some sort of ranking system for the possible features so that I could decide which ones to commit to. After doing that for about 5 minutes, I thought “What am I doing? I can’t worry about this that much; there isn’t enough time.” So I ended up putting very little thought into what it might take to implement each one and just picked some that seemed easy enough to be attainable. My hasty rough estimates were not good. I had a very hard time getting everything working on time, and what did work was either ugly to look at, ugly from a logical point of view, very not user-friendly, or a mixture of those things. I have to think that not doing any (in-depth) type of metrics or estimation that I saved time that I (apparently) needed to get the thing to the barely usable state that I did. On the other hand, I wonder if I spent more time on estimation, could it have possibly come out better. I certainly understand that it would have with a large scale version (larger staff and time frame) but with such limited time and resources is it possible at all?

Can Open Source become too popular?

In his Log Book entry Lucas Vickers discusses his experience with Open Source support and contrasts it with his experience with Microsoft support. He also poses an interesting question at the end, thqat as more folks use Open Source the expertise level will go down and more Open Source developers will be bombarded with newbie questions. Do you think this will happen? If so, how can Open Source developers handle the support demand?

As an added bonus in his Log Book, Lucas gives us a pointer to another rule base language, Drools. In a later blog entry I will give you my impressions of the Drools tool. Later!

Lucas Vicker's Log Book Entry:

Open source is the topic of this week’s discussion, and it is something that I am fairly interested in. I have worked with open source products, and I have also worked with Microsoft products. I know using Microsoft as the model for what comes out of corporate development is a little unfair; however I am going to do so because I have the most extensive experience with them. To be honest I have found Microsoft products that work really well, and I have found open source products that work really well. I once developed a program for the pocketPC platform using Microsoft tools, and oh my that was one of the buggiest platforms I have ever worked with (this was back in 2002). I have also recently tried to integrate Drools, an open source and java based rules engine. After a few weeks of heavy coding with Drools I found that there was a major flaw in the implementation which halted my work. What I am trying to say is that each product has its flaws. The difference is as soon as I had a problem with drools, I sent off an email to the developer, met him on IRC on #drools, and we resolved the problem with in a few days. Any problem I had with Microsoft all I could do was search MSDN and pray that they have an answer to my question. I think that one major factor to consider is the group of developers behind a project. Open Source developers really love what they do, work in their spare time because it’s a passion, and are very easy to contact. Microsoft developers, however, hide behind the veil that is Microsoft and it is near impossible to get an explanation for why a function works a certain way. I think knowing that OS developers are developing because they want to and love to, and are accessible, gives open source software an edge. I wonder if this edge would disappear once the average user began attempting to use OS software and the developers became flooded with repetitive and useless questions.

Catch-22

The following entry from Kaylon Daniels begins a series of entries from my summer software engineering class. It seems that every semester, outsourcing becomes a larger issue with the graduating generation of computer scientists. Kaylon's entry discusses the effect it is having in this country and speculates on the long term effects. A later entry in this series will discuss some other aspects of outsourcing and its effect on quality. I would appreciate any comments on this post or your views on outsourcing, its effect and potential opportunites outsourcing may provide.

Here's Kaylon's Logbook entry.

Most of my log book entries have been relatively short. But this one will be one of my longer posts. I just wanted to write some of my thoughts and discoveries about outsourcing. This is an important topic to me because I am unemployed at the moment and have been wondering how much of the credit I can assign my employment status to this phenomenon. I’ve read some articles in Business 2.0 and Business Weekly and I’m unsure which opinion to believe. Biz 2.0 states that outsourcing is going to have long term positive impacts on the U.S. economy. The middle class in other countries can afford to purchase our goods; this will produce more jobs in the U.S. They also feel that it frees Americans to pursue more advanced technologies while low level maintenance work is passed on to the third world. Now, Business Weekly states that outsourcing has nothing to do with the low level of tech jobs available. They state that the U.S. worker has been undone by his/her own productivity. Because the American worker can do more with less, there is less of a need for skilled workers. Maybe they are both correct to some extent, but I am sure of one fact. The last job fair I attended, I waited in a line that went around an entire city block. I couldn’t believe what I was seeing. This country is beginning to resemble Brazil more every month. Outsourcing is just another blow to the middle class which is already starting to disappear. Personally, I haven’t seen another tech industry pop up to replace dot-com businesses. There has been talk about nanotech and commercial space goods, but how can we capitalize on these markets when very few Americans are actually studying sciences. Most students in these fields are from nations we are currently outsourcing to. These emerging countries should be able to produce enough capital (thanks to a growing middle class) to research these new tech fields; why would one assume that the U.S. will have any real influence on the next generation of technology. It seems to be a catch-22 situation.

End of logbook entry. Before I end this post, a brief interlude on the phrase Catch-22, which defines a can't win situation. Catch-22 was written by Joseph Heller and Alan Arkin starred in the movie in 1970. It concerned World War II bomber pilots. Orr was pilot who was trying to get grounded by reason of insanity. The defining moment in the book is captured in this quote:

There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he was sane he had to fly them. If he flew them he was crazy and didn't have to; but if he didn't want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.
"That's some catch, that Catch-22," he observed.
"It's the best there is," Doc Daneeka agreed.

If you would like to discover more about Catch-22, check out this site, where I refamilliarized myself with the book. It is a great book that was very popular in courses when I was in college in the late 60's, early 70's.

Later.