Basics: Difference Between Models, Frameworks, and Methodologies

Nesting Easter eggs show each layer of the process improvement architecture

One of my children owned a (Russian nesting doll) that is now somewhere in our attic.  I was always struck how one piece fit within the other and how getting the assembly out of order generated a mess. I think I learned more from the toy than my children did.  The matryoshka doll is a wonderful metaphor for models, frameworks, and methodologies. A model represents the outside shell into which a framework fits followed by the next doll representing a methodology placed inside the framework. Like models, frameworks, and methodologies, each individual doll is unique, but they are related to the whole group of dolls.

 

Five Problems That Impact Testing Effectiveness and Efficiency: #5 Process

Apparently the cleaning crew flows a process

Developing or maintaining a piece of software requires a fairly complicated set of processes, including processes for collecting requirements, designing, coding, verifying and validating a solution. All of the processes need to work together well or they risk impacting the quality of the delivered product. Process problems tend to be most severe when testing and engineering processes are mismatched, organizations embrace a one-size-fits-all testing solution or ad-hoc testing processes (gag).

• Mismatched processes – Testing is a collaborative process requiring communication between everyone involved in developing software. When development and testing processes are not synchronized, the chance of miscommunication increases.  For example, consider the communication problems that would ensue if the developers were using Agile techniques while the testers were using waterfall techniques. Agile development techniques would be focused on delivering functional code rather than omnibus requirements or design documents that are often used to drive waterfall testing. Whether Agile, waterfall, RUP or some other framework if testing and development have not found a mechanism to synchronize how they work together, defects will make it to production.
• One-size-fits-all testing solutions – Every project has its own set of nuances and risks. The testing solution for each project needs to be tailored to meet the specific needs of the project. A one-size-fits-all solution will tend to overemphasize specific types of testing (e.g. functional testing, system testing or integration testing) when another type may need emphasis.  For example, recently I observed a large program that initially failed on delivery because integration testing was not part of the standard process the firm used.
• Ad-hoc testing – Ad-hoc testing (just winging it) went out of style as soon as someone thought about the quality of the code being delivered, it never worked and never will. Just don’t do this.

Development is a dance of multiple inter-related processes. Regardless of whether the project uses the team uses a mixture of extreme programming, test-driven development, black-box testing or exploratory testing the processes need to work together. Synchronized and compatible development and testing processes are critical for effectively and efficiently developing. Agile techniques leveraging cross-functional teams, that include developers and testers, put teams in the best position to ensure a synchronized process.

 

It Is The Product That Counts!

Frameworks, methodologies and systems are tools to create value.  They provide guidance for practitioners.  It is easy to become convinced that you need the newest, shiniest framework, methodology or system.  The means becomes as, or more important, than the end.  While having the right framework is important, in the end, it is the product that gets delivered that is important.

As you begin a project remember that the goal of the project is to deliver value to the organization that is funding the project.  When delivering a project the ends and the means are clearly related, however the means can’t become the goal.  Focusing on the end product, business goal, makes delivering value much more likely.

FYI – The picture today is a close friend’s new brewing system.  The beer is great and that is what really counts!

Note that the Software Process and Measurement Podcast features an interview this week with Bob Ferguson on Product Development  – check it out!

 

Daily Process Thoughts: Form and Design, March 25, 2013

The anchor plate (also known as a wall washer) is designed to hold the end of tie rod to support a wall or floor so they do not bow.  The star shaped version is a melding of functionality and beauty. Who cares that beauty and functionality are rolled together, builders, architects or the man on the street?  If we were to ascribe functionality to one group’s needs and design to another’s needs, we would miss the point that both are important to most users.

Most internal IT products seem to see design and functionality as two diametrically opposed attributes, like the “tastes great/less filling” dichotomy from the light beer commercial . . . unfortunately both IT and light beer manufactures miss on the whole form/function trade-off. The form/function trade-off is made every day by project teams in IT organizations. The reasons are varied, ranging from schedules that don’t address for design to engineers that substitute for product or graphic design personnel.

My wife recently bought a MacBook Pro. Every step of the purchasing process was designed and choreographed to bond her to the product.  Even the act of removing the shrink wrap was a designed ceremony.  Software development methods, techniques or frameworks are rarely developed and designed with same level of form and function as the MacBook Pro. Consumer products and IT processes might not evoke the same passion, but should that be the case? Can we design our processes to create passionate users who can appreciate both its form and function?