I started my first UMass Dartmouth class last week, it’s called “Paradigmatic Software Development”. You can read all about the syllabus and course objectives here if you’re so inclined. Following are my notes from the first reading assignment (Chapter 1 of Object-Oriented and Classical Software Engineering):

· The book starts off with a story about a man who received a bill for $0 and after receiving it multiple times, he sends in a check for $0, which then proceeds to crash his bank account. Funnier still is that this story appears to be an urban legend. I’m sure the bigger point is that errors like the one mentioned are all too common, hence this course. In case the author ever reads this, there is a much better list of famous bugs on wikipedia; see also Off-by-one error, fencepost error.

· Definition: software engineering is a discipline whose aim is the production of fault free software, delivered on time and within budget, that satisfies the clients need. Additionally the software must be easy to modify when the users needs change.

· There are 5 aspects of software engineering: historical (a very low percentage of software products have been completed sucessfully), economic (tech ‘a’ is 10% better than tech ‘b’ so if we switch to using ‘b’ we should be able to complete project ‘x’ in 10% less time), maintenance (requirements, analysis, design, implementation, post delivery maintenance, retirement)

· Real life example of the life cycle model mentioned above: at Mindseye we a) met with the client to get the project [requirements], b) produced a features and functions document which was agreed upon before work started [analyis], c) produced the black lines / specifications [design], d) implemented the site [implementation], e) entered into support contract [post delivery maintenance] or existing resources took over the project. The one thing we didn’t do was design of the software itself, our design / specification document was made up mostly of an object model and black lines (similar to what most people would call information architecture).

· Maintenance often happens before the project is released ( because of changes to the design etc…). Only good software actually makes it to post delivery maintenance phase because bad software is thrown away well before that time (or is never implemented)

· The book at this points presents a trivial example of how encapsulation is “a good thing” by showing how it would be much better to use this:

public static final float salestax = 6.0;

than to insert 6.0 in multiple places in your code (obviously). The funny thing is that by using a float to represent sales tax, he unwittingly introduced a bug into his code.

· Average cost percentages per phase (requirements, analysis, design, etc..) has hardly changed over the 20 or so years (~20% to requirements, ~20% to design, ~35% to coding / unit testing, ~25% to integration) but much more interesting is the fact that more than 75% of the total cost of a project is related to post delivery, so anything that can reduce the amount of time and money that you spend in that phase should probably be closely looked at.

· requirements / design / analysis:
  — fixing costs more when you find it later (if you’re using the classical software development model)
  — techniques that help you complete the requirements / analysis / design phase better will help save quite a bit of money and time up front

· planning phase: Not included because planning is usually carried out all through the life cycle; mostly during the beginning of the project and the software project management plan

· testing: needs to be happening all the time althoguh the book seems to think more of a QA group than of unit / automated testing

· documentation phase? No because the documentation should be kept up at all times so there ahould never be a time when it is out of date

· Object Oriented
  — strengths of OO: post delivery maintenance is easier because of information hiding, OO makes more sense when modeling (which should lead to higher quality software), encapsulation (OO is sometimes referred to as responsibility-driven design or design by contract), classical paradigm results in a set of modules that is conceptually a single uit, OO results in smaller largely independent units ,OO promotes reuse
  — diff between OO and classical:
    — OO has workflows, classical has phases
    — OO starts integrating classes almost right away while classical doesn’t integrate modules until the design phase.