Why Should Business Care About Software Quality?

June 26th, 2009 Comments off
Best Quality

Building software is like building a house in many ways.  When building a house, we have to have a good foundation, strong pillars, proper plumbing and wiring, and so on and so forth.  When building software, we need to have a good design, clear and concise code, proper wiring of components, etc.

There is one subtle difference between building software and building a house though.  Usually when we build a house, we rarely make large renovations such as adding a story, moving around walls and windows, putting in a new electrical system, or modifying the foundation. Software, on the other hand, needs to be modified and updated quite often due to changes in business caused by Read more…

Total Quality Management (TQM)

September 2nd, 2007 Comments off

Traditionally, quality assurance ensures the quality of a product once it’s built in order to shield customers from receiving defective product. TQM suggests that rather than putting quality assurance at the end of the product cycle, feedback loops be placed at every step of the product building process so that the actual causes of defects can be identified and fixed. Fixing causes of defects can continually increase customer satisfaction at continually lowers costs.

MSF Agile v4.0 Team Model

August 27th, 2006 Comments off

Out of all the Agile methodologies I have studied so far (XP, Scrum, AUP, and MSF), I really like the fact that MSF provides a Team Model that goes into details about how project teams should be structured. While it may be obvious to some, I know from experience that properly structuring teams is not something that that comes naturally to many organizations. In fact some organizations have less success with agile only because of their ineffective team structures.
MSF Team Model is based on the following basic principles:

  • A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
  • Advocacy for all key constituencies that must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
  • Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.

There are 7 advocacies that are represented in the MSF Agile Team Model. In my opinion it’s imperitive that these advocacies have proper representation in order to ensure success of a given project. Since MSF offers a stretch-to-fit approach, it’s possible to map these 7 advocacies into fewer role clusters as determined by the phyical size of the team.

Following are the advocacies and their respective focus as presented by the MSF Team Model:

Product Management


  • Understand, communicate, and ensure success from the standpoint of the economic customer requesting the solution.

Functional Areas

  • Marketing
  • Business Value
  • Customer Advocacy
  • Product Planning


  • Acts as customer advocate
  • Drives shared project vision/scope
  • Manages customer requirements definition
  • Develops and maintains business case
  • Manages customer expectations
  • Drives features vs. schedule vs. resources tradeoff decisions
  • Manages marketing, evangelizing and public relations
  • Develops, maintains, and executes the communications plan

Program Management


  • Right solution is delivered at the right time and all expectations are understood, managed and met.
  • Deployed solution will meet qualities of service & business objectives, and be viable in the long term.

Functional Areas

  • Project Management
  • Solution Architecture
  • Process Assurance
  • Administrative Services


  • Drives development process to ship product on time
  • Manages product design and specifications
  • Facilitates communication and negotiation within the team
  • Implements and ensures standards
  • Maintains the project schedule and reports project status
  • Drives implementation of critical trade-off decisions
  • Develops, maintains, and executes the project master plan and schedule
  • Drives and manages risk assessment and risk management



  • Implementation, estimates, high quality maintainable code and unit tests.

Functional Areas

  • Technology Consulting
  • Implementation of Architecture and Design
  • Application Development


  • Specifies the features of physical design
  • Estimates time and effort to complete each feature
  • Builds and/or supervises building of features
  • Prepares product for deployment
  • Provides technology subject matter expertise to the team

Quality Assurance


  • Ensure solution quality.

Functional Areas

  • Test Planning
  • Test Engineering
  • Test Reporting


  • Ensures all issues are known
  • Develops testing strategy and plans
  • Conducts testing
  • Reports test results



  • Timely readiness and compatibility of infrastructure.

Functional Areas

  • Infrastructure
  • Support
  • Operations
  • Commercial Release Management


  • Act as advocate for operations, support and delivery channels
  • Manage procurement
  • Manage product deployment
  • Drive manageability and supportability trade-off decisions
  • Manage operations, support, and delivery channel relationships
  • Provide logistical support to the project team

User Experience


  • Provide user documentation and training
  • Understand and communicate users’ context, and ensure usability from user perspective

Functional Areas

  • Technical Communications
  • Training
  • Usability
  • Graphic Design
  • Internationalization
  • Accessibility


  • Acts as user advocate on team
  • Manages user requirements definition
  • Designs and develops performance support systems
  • Drives usability and user performance enhancement trade-off decisions
  • Provides specifications for help features and files
  • Develops and provides user training

Agile Resource Allocation

August 22nd, 2006 Comments off

For Agile methodologies to really work with the promised increase in efficiency, it’s important that all participating team members be generalists rather than specialists.

For some companies migrating to Agile from other traditional methodologies, this may not be the case. I have worked with companies that have well-defined and assigned roles for Business Analysts, Database Administrators, Front-end Developers, Back-end Developers, etc. When such companies move towards Agile, they face a problem of optimal resource allocation and utilization.

As an example, a developer may not be productive while a DBA is creating new tables in the database and writing stored procedures. Once the DBA is done with his tasks, he may not have enough to do until the start of the next iteration. Since Agile is iterative, and iterations can’t overlap, this may result in poor resource utilization and may adversely effect the overall efficiency.

Before starting to implement an Agile methodology within your organization, it is important to make sure that your IT human-resource infrastructure actually supports it. While Agile may work in companies with specialized IT roles, it is definitely not designed and optimized for those scenarios.