Software Engineering Series Part 4 - Software Testing and Quality Measurement Monday, December 29, 2008

The goal of software testing is to provide development team members, project managers, and stakeholders a pulse on the quality of a software system. By extension, software testing aims to find the greatest number of defects with a manageable amount of effort applied over a realistic time span.

Roger S. Pressman notes the following points in his textbook regarding the measurement of software quality:

Measuring Quality

• Correctness - the degree to which a program operates according to specification
• Maintainability - the degree to which a program is amenable to change
• Integrity - the degree to which a program is impervious to outside attack
• Usability - the degree to which a program is easy to use

Many in the academic and business research space argue that the Defect Removal Efficiency or DRE should be the key quality indicator for most software projects:

Defect Removal Efficiency (DRE) = (errors) / (errors + defects)

where:
errors = problems found before release
defects = problems found after release

Given that most organizations use some form of defect tracking, the above metric can easily be calculated and tracked over time to see how the DRE changes. This metric, in my opinion, is useful only in the context of other metrics such as project sizing (KLOC), code coverage, test suite count, etc.

Software Engineering Series Part 3 - The Four P’s Friday, December 19, 2008

Roger S. Pressman notes the following notable "Four P’s" in his textbook:

• People - the most important element of a successful project
• Product - the software or system to be built
• Process - the set software engineering tasks to get the job done
• Project - all work required to make the product a reality

I find it useful to keep these in the back of my head at all times.

Software Engineering Series Part 2 - Object-to-Object Communication Wednesday, December 17, 2008

In object oriented programming, a message is an abstraction of object-to-object communication whereas one object (called the sender) sends a message to another object and the receiving object (called the receiver) responds. The response is NOT considered a second, distinct message.

In languages such as C/C++/Java/C#/etc., the concept of a "message" just happens to be the method call (and the response is a return value). In reality, a message is really just a message, nothing more, nothing less (as in Ruby, Smalltalk...).

Method calls being a manifestation of object-to-object messaging is just a necessary evil of compiled, strongly typed languages. As my colleague T.K. notes, it possibly also has a lot to do with language designers' attempts to step from a procedural mind set to objects; there's a lot of OO concepts that they just gloss over as unimportant and miss the real power of OO in the process.

Alan Kay, American computer scientist, known for his early pioneering work on object-oriented programming and windowing graphical user interface design, has argued that message passing is a concept more important than objects in his view of object-oriented programming, however people often miss the point and place too much emphasis on objects themselves and not enough on the messages being sent between them. [1]

 

References:

[1] http://www.wikipedia.org

Software Engineering Series Part 1 - The Nature of Software Tuesday, December 16, 2008

Software by nature is intangible, that is, it has no real world physical manifestation. Software is designed to be changed, otherwise the functionality would have been implemented in hardware. It then easily follows that software does not "wear out" (no mechanical "parts"), rather it degrades in quality due to constant change. These simple statements about the nature of software will set the stage for future topics in this series.

Software Engineering Series Coming Soon

In the coming days and weeks, I will be presenting a blog series on various software engineering related topics inspired by my graduate studies. Possible topics include process frameworks, quality control, estimating and planning, requirements engineering, analysis and design, and more. The topics will have more a of an academic twist while hopefully relating them to practical experience. Stay tuned.