Thursday, January 8, 2004

Proto Spasms

In our CS540 class Monday we discussed prototyping. One recurring issue is how members of the team can prevent promotion of the prototype to a product. Recall that most prototype schemes are designed to support requirements elicitation and after the prototype is completed the appropriate course is to formalize requirements and then begin design. Unfortunately prototypes often take on a life of their own and sometimes the developers contribute to it.



So the question is how can we insure that prototyping is not misused. My answer in class was a strategic one involving architects and architectural reviews. However, in organizations where reviews are not in place (and may never be in place) what can teams do to prevent misuse?



For the contrarians out there, do you know of instances where promoting a prototype (excluding evolutionary prototypes) to a product was a good thing? I appreciate your input! Later.



Saturday, January 3, 2004

Redesign

Return visitors will notice that I have redesigned the site. This includes making it more consistent with Stevens colors. I would appreciate your comments on the site.



My New Year's resolutions include posting at least once per week on this site. I know there was a bit of inactivity during the holidays but I hope to increase the activity in the coming months.



If you find value to this site, tell your friends AND contribute to the site. I will be happy to post new items if you email them to me and of course give you credit fo rthe post. Of course you can always comment on the posts.



Advancing Software Engineering will always be a community effort of all the constituencies: practitioners, researchers and stakeholders. Later.



The Unexplored Universe

This is a request for feedback from students who have taken my Introduction to Quantitative Software Engineering Course, CS540 for those of you who prefer numbers. However I encourage others to contribute, since I will provide the current list of topics I introduce in the course.



Currently the course covers: Software Process Models, Software Requirements, Capability Matrurity Model and the Software Engineering Institute, Managing Software Requirements, Software Project Planning, Software Requirements, Metrics, Estimating Effort, Risk Analysis, Scheduling, Softwar eProject Reviews, MULTICS case study, Quality Assurance, Development Standards, Configuration and Build Management, Testing, Systems Engineering, Analysis and Modeling, Architecture, Design, Supporting Techniques (Problem Solving, Meeeting Methods, Negotiation, Management management), Object-Oriented Analysis, OO Design, OO Testing, OO Metrics, Light vs. Heavy Methodologies Including XP, Open Source, Gaming, Softwar Factories, Computer Human Interaction, Formal Methods, Clean Room Development, Fault Tolerance, Software Archeology. Phew. The textbooks include Brooks Mythical Man Month and van Vliets Software Engineering.



My goal is to touch on each of these subjects and provide pointers so that students can investigate the topics further on their own. So I am reticent to exclude topics and would appreciate pointers to topics in Software Engineering that I have missed. One bit of feedback last semester was that I should spend more time on Quality.



Are there other topics that I am missing? Are there some topics that I should not cover? Do you have ideas for other classic case studies? One topic I am considering adding next term is Out Sourcing of Software -- would this be helpful?



Thanks for your help! Later.



Friday, December 12, 2003

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.



Quality Recommendations

One of my students has asked for recommendations on books for Software Quality Assurance and Testing. I will provide you my recommendations in a later post but I am interested in your recommendation of books and websites on these two topics. Thanks for your help! Later.



Wednesday, December 3, 2003

Exploring the Real Universe

With the end of the term and the holidays coming soon, you might want to know what to do with all that spare time.  Besides reconnecting with your family and friends or reading a great book, if you are looking for a low cost alternative, check out these paper models that NASA offers at (updated link) this location.



The link is daunting but it is worth browsing some of the model building activities listed there. 



Later.



Universal Access

Universal Access is the category in Apple's OS X operating system to tune the system for the hearing and vision impaired. Designing and developing software that can be used by the maximum number of people not only is the right thing to do but also makes good business sense.



A great web site to familiarize yourself with what is available is http://www.abilityhub.com/.



Do you regularly design and develop software and systems that takes into account Universal Access? Do you know of other resources for folks interested in Universal Access? Please share your thoughts with the group!



Later.