1. As Simple As Possible, But No Simpler Sam Guckenheimer http://lab.msdn.microsoft.com/vs2005/teamsystem/ samgu@microsoft.com

2. Simple Project Management Functionality Quality Resources Time “The Iron Triangle” (err… tetrahedron)

3. 21 st Century Mantra Do more with less! But if your only variables are: But if your only variables are:  Functionality  Quality  Resources  Time …then how are you going to do that? …then how are you going to do that?

4. An Older Truth Happy families are all alike; every unhappy family is unhappy in its own way. Tolstoy, Anna Karenina Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.

5. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

6. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

7. Code Some why-nots Some why-nots  Use managed code  Use modern frameworks  Use service- oriented architecture  Use available tools Transparency Transparency  Responsible costing  Visible results Available tools Available tools  Unit tests  Code coverage  Static analysis  Profiling performance  Source control  Work item tracking  Build automation

8. Unit Tests and Code Coverage Unit Test Results Code Under Test not covered during the test run

9. Code Analysis http://blogs.msdn.com/jason_anderson/archive/2004/09/05/225798.aspx Code Analysis recommendations as build warnings Direct jump to code from the warning

10. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

11. Product Definition Personas and Scenarios Personas and Scenarios Qualities of Service Qualities of Service Capture implicit requirements Capture implicit requirements  Kano analysis Stack ranking Stack ranking Continually challenge your assumptions!

12. Personas and Scenarios PM Starts New Portfolio Project PM Enumerates Requirements in Excel PM Schedules Work in MS Project PM Monitors Project Status PM Reviews Project Status PM Promotes For Deployment CEO Signs Contract Architect Updates Design Architect Adds Tasks & Checks In Dev Writes Code Dev Writes & Runts Unit Tests Dev Reviews Work Dev Runs Code Analysis Dev Writes Load Tests Dev Checks In Work Dev Diagnoses & Fixes Dev Checks In Work Tester Checks Build Status Tester Runs Load Test Tester Reports Bug PROJECT MANAGEMENTARCHITECTDEVELOPERTEST Jacqui Ackerman Project Manager Art Benson Architect Martin Gaines Developer Renee Davis Tester Renee Davis Tester

13. Qualities of Service Performance Performance  Responsiveness  Concurrency  Efficiency  Fault tolerance  Scalability Trustworthiness Trustworthiness  Security  Privacy  Conformance to standards  Interoperability Usability Usability  Accessibility  Attractiveness  Compatibility  Discoverability  Ease of use  Localizability Manageability Manageability  Availability  Reliability  Installability and uninstallability  Maintainability  Monitorability  Recoverability  Testability  Supportability

14. Kano Analysis Hinshitsu (Quality), The Journal of the Japanese Society for Quality Control, XIV:2, pp.39-48, April 1984

15. Challenging Assumptions Customer in usability lab Customer’s desktop

16. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

17. Architecture Service-Oriented Architecture Service-Oriented Architecture Infrastructure Architecture Infrastructure Architecture Legacy Legacy

18. Service Orientation Build systems using autonomous services that adhere to the four tenets of Service Orientation: 1. Boundaries are explicit 2. Services are autonomous 3. Services share schema and contract, not class 4. Service compatibility is determined based on policy http://msdn.microsoft.com/msdnmag/issues/04/01/Indigo/default.aspx

19. Application Designer Service-Oriented Architecture model Port Details editor

20. Infrastructure Architecture Points of Failure Points of Failure Points of Observation Points of Observation Points of Attack Points of Attack Manageability Manageability

21. Logical Infrastructure Designer Services assigned to logical infrastructure Architecture validated against operational settings and constraints

22. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

23. Build Automation Nightly build Nightly build  Project heartbeat Pre check-in tests Pre check-in tests  Validation of code prior against current base prior to check-in  Variant is continuous integration Build verification tests Build verification tests  Functional tests (from unit tests)  Component integration tests Build reporting Build reporting  Against backlog, by check-in/changeset

24. Build Reporting

25. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

26. Versions Track versions for each of Track versions for each of  Source  Tests  Executables and other runtimes you create  XML, HTML, images, docs & databases  Environmental/deployment components  Bugs Report them together & relate them Report them together & relate them

27. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

28. Environment Production environment Production environment Test environment Test environment Capturing environment Capturing environment Tools Tools  Microsoft Virtual PC  Microsoft Virtual Server Maintain lab images Maintain lab images

29. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

30. Security The core problem The core problem Threat modeling Threat modeling Code analysis Code analysis Security testing Security testing Michael Howard, Writing Secure Code, 2003 J.D. Meier et al., Improving Web Application Security, 2003

31. Security: Core Problem Odds of securing a single level is 1 / ∞ Odds of securing a single level is 1 / ∞  Bad guy has to find only one vulnerability  Infinite time Microsoft as example Microsoft as example  100’s of different IT environments  2,500 unique attacks per day  125,000 incoming virus-infected e-mails per month Need to secure at every level Need to secure at every level  Design  Default  Deployment Multiple layers of defense needed Multiple layers of defense needed

32. Threat Modeling Analyze the design for vulnerability Analyze the design for vulnerability Model data flows Model data flows  S- Spoofing Identity  T- Tampering with Data  R- Repudiation  I- Information Disclosure  D- Denial of Service  E- Elevation of Privilege

33. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

34. Performance Deployment configuration Deployment configuration  Model performance as part of product definition  Replicate environment in lab  Test it as part of development  Fix it where it hurts Three-tiered problem Three-tiered problem  System  Components  Code

35. System and Component Performance measures of test and Systems Under Test Alerts and warnings on Systems Under Test

36. Code Performance Timeline of memory consumption Suspect functions, drillable to code

37. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

38. Manageability Operations documented and current for every service or application Operations documented and current for every service or application Service level agreement in place Service level agreement in place Security scanning in place Security scanning in place Proactively monitor and fix Proactively monitor and fix Reactive and proactive problem management Reactive and proactive problem management

39. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

40. Testing Mission & Approach Marick’s Framework Marick’s Framework Different missions and approaches apply for each quadrant Different missions and approaches apply for each quadrant Technology Facing Business Facing Support Programming Critique Product http://www.testing.com/cgi-bin/blog/2003/08/21#agile-testing-project-1

41. Let the punishment fit the crime! A good test approach is: A good test approach is:  Diversified  Risk-focused  Product-specific  Practical  Defensible Fit the technique and its data to its purpose in the quadrant Fit the technique and its data to its purpose in the quadrant Gilbert & Sullivan, The Mikado Kaner, Bach & Pettichord, Lessons Learned in Software Testing, 2002

42. Testing Mission & Approach Representative techniques Technology Facing Business Facing Support Programming Unit testing, code coverage, code analysis Test-Driven Development Granularity matches code Discrete scenarios Example-driven data Realistic 80% cases Prioritized regression testing Critique Product Specialize by QoS Model-driven tests Generated data Exploratory testing Soap operas

43. Test Coverage Identify the Scenario, QoS or Code that the test tests Identify the Scenario, QoS or Code that the test tests  If they’re newly discovered, capture them  If you can’t name them, question the value of the test Measure coverage against these dimensions Measure coverage against these dimensions

44. Test Automation and Its Discontents Technology Facing Business Facing Support Programming Lowest cost Critique Product Highest cost ROI= Σ t (Value of Information) - Σ t (Cost to Maintain) Σ t (Cost to Implement) (adjusted for net present value and risk)

45. Test Automation and Its Discontents Value depends on context Value depends on context Automation is a programming exercise Automation is a programming exercise Opportunity cost high due to resource constraints Opportunity cost high due to resource constraints Options theory problem Options theory problem  Very sensitive to volatility  Often incalculable ROI= Σ t (Value of Information) - Σ t (Cost to Maintain) Σ t (Cost to Implement)

46. Testing Web Applications View of content as rendered Content validation http request & response Performance breakdown Data substitution

47. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

48. Metrics Consider many dimensions at once Consider many dimensions at once  Single metrics easily mislead  Test results  Bug rates  Code churn  Code coverage  Requirements coverage  Never use metrics for reward or punishment Flow of value, not completion of tasks Flow of value, not completion of tasks Planned and unplanned work Planned and unplanned work Robert Austin, Measuring and Managing Performance In Organizations, 1996

49. Which Component is Healthiest? Contrast two views of project data Contrast two views of project data Fewest bugsHighest test pass rate

50. Which Component is Healthiest? Conclusions: Conclusions:  Tests are stale  Highest risk here Lowest code coverage Highest code churn

51. Focus on Flow of Value David J. Anderson, Managing with Cumulative Flow, 2004 www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html Control height of work in progress Value measured on completion

52. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

53. Processes Differ for Good Reasons… Economics Economics  Regulation  Liability Plan-Driven vs. Adaptive Plan-Driven vs. Adaptive Iteration length Iteration length Documentation required Documentation required Sign-off gates Sign-off gates Time tracking requirements Time tracking requirements

54. Infrastructure Architect Project Manager Developer Tester Solution Architect Business Stakeholder …and for Bad Reasons

55. Solution is Transparency Infrastructure Architect Solution Architect Project Manager Developer Tester End User

56. Transparency Single product backlog Single product backlog Task-aware versioning Task-aware versioning Project portals Project portals Process handbook Process handbook

57. Single Product Backlog Single backlog of all Work Items (Reqts, Tasks, Bugs, etc.) Queries to filter, view, report Details for each entry Complete change history

58. Task-aware Versioning Source files to check in … …with Work Items done… …and Check-in Notes and Policy Status

59. Project Portal

60. Process Handbook http://workspaces.gotdotnet.com/msfv4

61. 13 Symptoms of Unhappiness It’s the code, stupid! It’s the code, stupid! Actually it’s the requirements! Actually it’s the requirements! No, the problem is that you neglected the architecture! No, the problem is that you neglected the architecture! Architecture, schmarchitecture. I just want a working build. Architecture, schmarchitecture. I just want a working build. What good is that the way we mix up versions?! What good is that the way we mix up versions?! Not code versions, but the environments, don’t you get it? Not code versions, but the environments, don’t you get it? Ever heard of security?! Ever heard of security?! Yeah, but you ignored performance, duh! Yeah, but you ignored performance, duh! So what if it worked in the lab -- it’s still unmanageable! So what if it worked in the lab -- it’s still unmanageable! Oh, and did we mention testing? Oh, and did we mention testing? Since you’re not measuring it, you can’t manage it anyway! Since you’re not measuring it, you can’t manage it anyway! With a process like that, what do you expect? With a process like that, what do you expect? It’s our culture – you’ll never change that. It’s our culture – you’ll never change that.

62. Culture Productivity and predictability Productivity and predictability Responsibility over assignment Responsibility over assignment Team and individual Team and individual Product mentality Product mentality

63. 13 Symptoms of Unhappiness  It’s the code, stupid!  Actually it’s the requirements!  No, the problem is that you neglected the architecture!  Architecture, schmarchitecture. I just want a working build.  What good is that the way we mix up versions?!  Not code versions, but the environments, don’t you get it?  Ever heard of security?!  Yeah, but you ignored performance, duh!  So what if it worked in the lab -- it’s still unmanageable!  Oh, and did we mention testing?  Since you’re not measuring it, you can’t manage it anyway!  With a process like that, what do you expect?  It’s our culture – you’ll never change that.

64. Sam Guckenheimer http://lab.msdn.microsoft.com/vs2005/teamsystem/ samgu@microsoft.com