Software Patterns

On Tuesday, the class did the final project walk through.  The walk through went well, with good thought given to the project.

 

Overall, I must say that I thoroughly enjoyed teaching this class.  The students were terrific - and I'm sure they will all have excellent careers after graduate school.  They were interested in learning in learning the subject and very comfortable in asking questions and helping me focus on their areas of interest.  I will take the student's feedback into consideration if I teach this course again. 

 

I'm off from teachnig for the next month - teaching the last half of a freshman technology class.  I look forward to blogging about that experience.

I changed the final lecture in class from Service Oriented Architecture (SOA) to Software Architecture.  As I was preparing for the lecture I figured that SOA made little sense outside of the context of software architecture.  I started the lecture by discussing conceptually layering an application, a technique used by good architects.  The lecture centered around the layered approach I took in defining the conceptual architecture for my Communications as a Service article.   

 

After a good discussion on layering (peppered with discussion on SIP/IMS signaling), I mapped the different layers of a software system to different technologies in the .NET stack.  I spoke about SOA in the context of Windows Communication Foundation (WCF), and showed a demonstration of WCF.  I then spoke about service consumers creating a Windows Presentation Foundation (WPF) consumer of the WCF service I created.  I tried to show an excellent demonstration I have of a business process layer, but my demo was broken and I didn't want to waste the class's time trying to get it to work.

 

 

Last night's class had the final lecture from the text, which covered some interesting topics like, requirements validation, how to develop requirements for sustaining engineering projects, COTS solutions and outsourced projects; change control; and requirements tracking.  These topics aren't very pertinent to the assignments in the class, but is critical knowledge for leaders on software projects.

 

Overall, I beleive that the text was good.  Optimally, it would have contained more information on agile methodologies, which are as commonplace as structured methodologies these days.  The text should also talk more about more modern modeling techniques like UML.  Some of the models in the text were being talked about when I took a similar course in graduate school in 1995 - and I've never seen them used in software development since.  I think that the better parts of the text were Chapter 12 to Chapter 20, which dealt with software quality attributes and the aforementioned topics.  I don't know of another book that covers those topics as well as the Weigers text.

 

 

Professor Don McCubbery lectured the class last Thursday on the Colorado Benefits Management System (CMBS) case study he authored.  CMBS was a disaster of a software solution that affected countless numbers of people receiving public assistance.  CMBS was an example of the gross mismanagement of a software development effort in which user concerns and quality reports were largely ignored in the decision making of whether the flawed solution should be placed in to production or not.  The solution was put into production and people were impacted.

 

A lot of the discussion centered around what decision we would have made in terms of putting the system in production.  My feeling was to scrap the solution if there could be no firm commitments as to the completion of the project.  We also spoke about who was responsible: (1) project management, including state employees and a manger from AMS (a company I worked for in the mid 1990s); (2) EDS - the vendor who was responsible for delivering the project; (3) the State of Colorado Governor's Office of Innovation and Technology (OIT) that was to provide oversight of the project.  My feeling was that all were responsible, with the bulk of the responsibility falling on the shoulders of the project management who made the decision to take the project live.

 

Finally, I added my 2 cents on how it is people who tend to be mostly responsible for software project failures, either through personal politics or blatant incompetence (or a combination of the both).  I have never seen a solution fail in which people were working together to get the project done, even under very tough circumstances.  Sometimes people need to swallow some pride and do what is best to deliver a project.  Even though this may seem contradictory to ones political aspirations (everybody wants to be the visible hero), the learning experience of delivering a quality solution tends to be the best measure of a valuable employee.