Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Development and Quality Management at Microsoft


Published on

A quick one page project report to explain operational implications of Software Development and Quality Management at Microsoft

Published in: Education, Technology, Business
  • Be the first to comment

Software Development and Quality Management at Microsoft

  1. 1. Software Development andQuality Management at IMBA NOV 2010 N1 Group H IE BUSINESS SCHOOL Andrea Carrow Kundan Bhaduri Miguel Piedrahita Mitsuru Nakayama Paolo Dina Regina Hernández
  2. 2. Software Development and Quality Management at MicrosoftMicrosoft designs and delivers several lines of consumer and enterprise software products every year that formthe core of its business. Each software product development process is considered a project and therefore hasdifferent sets of inputs, outputs and workflows. Further, the design process differs amongst product type (OS,ERPs, DTP applications, Database applications, Web Services etc). Each project is characterized by multi-member teams consisting of between 3 to 10 members per project, depending on the size of product (Small orMedium). However, it is not uncommon for larger projects to typically involve 100s of engineers and productspecialists. Since skilled manpower form the key resource for each project, most projects at Microsoft aregenerally estimated with a buffer of 20-25% idle capacity.The Software design and development process is sub-divided into four sub-processes: Scope definition,Development, Stabilization and Delivery which have linear milestone-based sub-tasks (Exhibit 1). Althoughthere are many software product development methods that have evolved at Microsoft over the past decade,one of the most prevalent ones is the Risk-Requirement based development methodology. In this process, atthe time of scope definition and requirement design, all pertinent risks to the project are identified andassociated to one or more requirements in what is known as a Risk-Requirement Matrix (Exhibit 2). At the endof development, this matrix is used to prioritize testing for those requirements that had the highest riskassociated to them, thus mitigating these risks. This method ensures product quality with lower effort and cost.Microsoft observes three quality goals in all its software development projects – Functionality, performance andtimeliness of delivery. The key quality issues that are commonly experienced are low reliability, highinteroperability costs, and low scalability. These can be attributed to various bottlenecks arising out ofinterdependence of various systems and modules. Microsoft also identifies its Software Quality Gap, which isdefined as the deviance between the result of quality delivered and the combined expectation of the softwareproducer and the customer. These gaps are mitigated through managed development methods such as JointApplication Development (JAD) at Microsoft. The key metrics that are used to benchmark software quality at thecompany are explained in Exhibit 3.In its very basic form, the software development process is nothing but an assimilation of inputs in terms of userrequirements that are transformed into usable software programs. The process has many subdivisions andtherefore several intermediate outputs get generated throughout the process of software development. The keyprinciple assumed in this process is that the resources are able to meet the schedule and process thedeliverable. Project Management is therefore a key aspect in the software development process. Projectmanagers frequently use planning and quality tools such as Microsoft Project Plan (MPP) and Quick Test Pro(QTP) to track resource utilization, identify bottlenecks, generate cost estimations and track revenues.Microsoft uses several key ratios to track efficiency of their development and quality assurance processes. Thetwo widely used ratios are Defect Leakage Rate (DLR) and the Defect Rejection Rate (DRR) (Exhibit 4). At anoverall level, for every defect in the system at the 3 quality level (i.e. 3 defects per 1000 lines of code [LOC]),on an average 37.5% defects get leaked into production. It is therefore clear that early detection and resolutionof defects is critical for Microsoft to keep its costs low. Therefore it is important that the company makes theright tradeoff between Costs and Quality (COQ) during the software development process (Exhibit 5).The company also adopts a lean Quality Control process throughout its development cycle. The process beginsby allocating a severity and priority to all identified defects. The severity is based on the defect’s importance tothe technical implementation, while the priority of a defect signifies its importance to business requirementconformance. Only upon resolution of all high severity and high priority defects, is any product released tomarket after iterative testing (Exhibit 6). However, we all know from our experience that zero-defect-release hasalways been elusive for Microsoft. Some permutations of inputs that result in ‘bugs’ get potentially leakedthrough the testing cycle, and creep into production release (but get subsequently detected by the consumersdue to a large install base). Over the past four years, Microsoft has consistently focused on decreasing its DLR,which has shown impressive results. While the Vista operating system had a very high DLR (upwards of 10%),the company’s most successful OS till date, Windows 7, introduced in 2010 enjoys a DLR of <1% (whileimproving the process quality to 6 ) thanks to improved control systems in the company.In conclusion, right quality assurance practices can help reduce development & maintenance costs and lowercustomer dissatisfaction, which in turn drives sales. Microsoft is a perfect case in point in this direction. © IE Business School | Operations Management T2 Final Project | IMBA Nov 2010 N1 Group H 1
  3. 3. Software Development and Quality Management at Microsoft Requirement Risks Q1 R1 Q2 R2 Q3 R3 Q4 R4 Requirement Q5 is not tested, Q5 since no risks are associated Exhibit 1: Software Development Process Exhibit 2: Risk-Requirement Quality Assurance Method  Functionality: Correctness, completeness, security and timeliness.  Usability: User-friendliness, availability, suitability, adaptability.  Reliability: Resilience, Recovery, Degradation, Transfer  Performance: Speed, Economy  Supportability: Testability, Maintainability, Portability, Manageability Exhibit 3: Software Quality Metrics Exhibit 4: Important Quality Ratio used at Microsoft Total Cost of QualityHigh Microsoft’s sweet (TCQ) spotCOST Cost of implementing Defects Cost of rectifyingLow Defects Low QUALITY High Exhibit 5: Cost of Quality and point of equilibrium Exhibit 6: Defect Prioritization System © IE Business School | Operations Management T2 Final Project | IMBA Nov 2010 N1 Group H 2