Resource sources

Charles "Chuck"  Lutz presents a host of great resources on the web in this discussion group entry.  In particular he provides a reference to a Parnas paper and that is fantastic.  As you recall, I encourage any aspiring software engineer to get the Parnas' book of collected papers, Software fundamentals: Collected papers by David L. Parnas, D.M. Hoffman and D.M. Weiss(Eds.), Addison Wesley, 2001, ISBN: 0-201-70369-6.  Especially since the gift giving season is upon us, you might give yourself this book.  It will serve you well.  Highly recommended.

Mary Shaw's paper that Chuck refers to in van Vliet is "Some patterns for software architectures."  Mary Shaw and David Garlan also wrote a book on software architecture, Software architecture: Perspectives on an emerging discipline, Prentice Hall, 1996, ISBN:0-13-182957-2.  One of the few rigorous books on software architectures.

Attached is Chuck's log, entry, thanks Chuck.  Later!

I've got a bunch of stuff to share that I've accumulated over the years which I believe 
has relevance to this course. I'll send them along as time permits (I've already got a 
backlog...!)

FYI: Mary Shaw's paper that van Vliet refers to on p. 273 can be found here.

Parnas' paper "On the Criteria to be Used in Decomposing Systems into Modules" is an 
absolute classic of software engineering. It pours a lot of timeless wisdom into just six 
pages. A web search yields many sources (I would not be surprised if it is in the top ten 
of most referenced papers). Here is the first that Yahoo yielded me.

A few weeks ago Prof. Vesonder mentioned in his notes a review technique of posting 
information on a wall. This is a very interesting area to explore, especially in trying to 
solve the problem of establishing a common vocabulary and understanding - to "get 
everyone on the same page" so-to-speak.

Here are two sources I think you might find interesting:

I'm an "information design" nerd and enjoy following the work of people in the ID and 
information architecture fields (IA). I've always enjoyed the work of Marc Rettig. Here is 
one take on the "wall" process as applied to product design.


For a more formal take on the "wall" process, including aspects that computer scientists 
can relate to, I recommend David Straker's excellent book on getting maximum 
collectively derived information using quite cheap materials.


In the future we will have wall-sized displays and software support that maximizes this 
resource. I expect such techniques will become increasingly popular as the cost of 
making changes decreases in these models as a result of this support.

The NeverEnding Story/Software

In the past ten years I have noticed a new class of software projects emerging. For lack of a better term I call them organic projects, since they take on a life of their own -- they really have no real endpoint and releases, when they occur, are a matter of convenience not a potential endpoint. Often these projects go through continuous release and evolve not only as the understanding of the requirements evolve, but also grow because they create new capabilities, that inspire a new burst of requirements, that create new capabilities, that inspire ... . Data collection and data mining projects fall into this category as do other internal projects that support corporate operations. The web as a whole is an evolving meta project of this class, where requirements evolve through use. Many Open Source projects follow a similar path but often their evolution is inspired by a changing developer and user base. Indeed I see more projects falling into this category as software permeates more of our lives and more individuals have the capability to author and modify software. Another defining attribute of this software is that it normally lasts decades (if not longer since software has only been around for decades!).

These projects are not well accommodated by current Software Engineering models, theory and practice. Agile methods come close, but they do not seem to consider long time scales. Incremental and spiral models, although spawning lots of releases, are workng to an end -- in incremental you prioritize the features and in spiral you do that plus risk assessment. Similarly design, development, testing, maintenance, (name your own) are affected.

So what do you think? Is this a new class of software and do you have other (better) examples of this? Is it worth beginning a thread on this blog that discusses this class of software and thoughts on the software engineering of these evolving systems?

Later.

About Feasibility

Attached is a logbook entry from Sushil Vachhani, a student in my Intro to Quantitative Software Engineering class. He writes about practical experience with feasibility studies. It is a great post.

Comments are encouraged.

I was once considering writing a program that would convert C++ code to Java code. I was deciding on several preliminary issues as to how would I go about it and in what language would the source code be written, C++ or Java? I chose C++ because I was more comfortable with its file handling features at that

time.

I knew that there were many similarities in the basic language features and so it was a matter of drawing out the 1 to 1 mapping. For example, the syntax of for-loop, while-loop, do-while-loop, declaration of integer and character variable (excluding arrays) and that of some other constructs was the same in c++ and Java and so it was a matter of merely duplicating these constructs in the output program that would be generated as a result of running this program with another C++ program as argument.

Next, there were some features in C++ that could be implemented in Java but some modification would be required. But there were many other features that were extremely difficult to implement such as pointers.

Also for doing this project I needed to have a deep understanding of the class libraries and the inbuilt functions that provided in C++ and whether its exact or comparable counterparts existed in Java.

Java also included many features such as Interfaces and Packages, Multithreading and the most importantly the GUI based Applets. Even if a C++ code could be transformed into Java, there was a certain possibility that the above mentioned features of Java would not be implemented thereby underutilizing the functionality of the language.

Finally, after careful consideration, I decided not to go ahead with the project at that time. The important lesson for me here was that my feasibility study paid off and saved me a lot of disappointment which I would have felt had I blindly begun working on the program.

Logbook Entries?

Would it be worthwhile to provide a weekly logbook entry in this blog? I would post either one of my own or (with permission and attribution) a logbook entry from a present or former student. If former students would like to post an entry please email me the entry and I will do the posting. Thanks!