2002/2003 Meeting Agendas

This session of the Software Quality Discussion Group will be an introductory level presentation and discussion on Software Quality Management. Our facilitator for the evening will be Fiona Koether of Nortel Networks.

Fiona is the Process & Configuration Management Manager for a Nortel software development team that has 180 staff across Ottawa and Calgary (yes there is still a strong software community at Nortel!). She was educated in Britain and worked in a variety of software roles for companies in Britain before emigrating to Canada in 1993. She had the good fortune to work for ACTC in Calgary (well known for it's software process maturity) before joining Nortel. She has worked at Nortel for 7 years and loves her job. Nortel is project driven and Fiona's team leads Organizational Process Improvement and integrating this with the project teams.

The topic of Software Quality Management, as described in the new ASQ CSQE Body of Knowledge, comprises:

2. SOFTWARE QUALITY MANAGEMENT

1. Goals and objectives
1. Quality goals and objectives

   Describe, analyze, and evaluate quality goals and objectives for programs, projects, and products. (Evaluation)

2. Outsourced services

   Define, analyze, and evaluate the impact of acquisitions, subcontractor services, and other external resources on the organization's goals and objectives. (Evaluation)

3. Planning

   Identify, apply, and evaluate scheduling and resource requirements necessary to achieve quality goals and objectives. (Evaluation)

4. Software quality management (SQM) systems documentation

   Identify and describe various elements related to SQM system documentation. (Comprehension)

5. Customer requirements

   Analyze and evaluate customer requirements and their effect on programs, projects, and products. (Evaluation)

   [NOTE: Changes in requirements are covered in III.B.3. The focus in this section is to ensure that customer requirements are evaluated properly.]

2. Methodologies
1. Review, inspection, and testing

   Define, describe, evaluate, and differentiate between these defect detection methods. (Evaluation)

2. Change management methods

   Identify and apply various methods appropriate for responding to changes in technology, organizations, environment, human performance, etc. (Evaluation)

   [NOTE: Change-agent tools are covered in I.C.1.]

3. Cost of quality (COQ)

   Define, differentiate, and analyze COQ categories (prevention, appraisal, internal failure, external failure) and their impact on products and processes. (Analysis)

   [NOTE: Interpreting and reporting COQ data are covered in IV.B.2.]

4. Quality data tracking

   Define, describe, select, and implement information systems and models used to track quality data in various situations. (Evaluation)

5. Problem reporting and corrective action procedures

   Define, describe, analyze, and distinguish between these procedures for software defects, process nonconformances, and other quality system deficiencies. (Evaluation)

6. Quality improvement processes

   Define, describe, analyze and distinguish between various defect prevention, detection, and removal processes, and evaluate process improvement opportunities in relation to these tools. (Evaluation)

3. Audits
1. Program development and administration

   Identify roles and responsibilities for various audit participants, including team leader, team members, auditee, auditor, etc. (Comprehension)

2. Audit preparation and execution

   Define and distinguish between various audit types, including process, compliance, supplier, system, etc. Define and describe various steps in the audit process, from scheduling the audit through the closing meeting and subsequent follow-up activities. Define and identify various tools and procedures used in conducting audits. (Comprehension)

3. Audit reporting and follow up

   Identify, describe, and apply the steps of audit reporting and follow up, including the need for and verification of corrective action. (Application)

The idea of the talk had its inception in a conversation I had with Kim about software quality while watching our kids play soccer. I suggested that quality is dependent, to a large degree, on the type of programming language chosen to implement the project. I suggested that regardless of any other quality initiatives, the language you choose will ultimately determine the level of quality you can achieve. Of course, this is an over-simplification, but I will argue that, in the end, it really is that simple.

That said I am not going to recommend a language! I am, however, going to talk about some of the initiatives that are going on (including my experiences with Charity and the use of linear types) and about their growing pains. I will talk about some recent advances in semantics, the difficulty involved in turning these ideas into programming constructs, and the task of finding a place for them in the programmming landscape.

Robin Cockett is presently a Professor in the Department of Computer Science at the University of Calgary. His area of interest includes, categorical programming, semantics of programming, and proof theory. He teaches undergraduate courses in compiler construction and functional programming, and graduate level courses in Category Theory and Program Transformation.

The long awaited revision of the Body of Knowledge has been done, and the new CSQE Primer is now available. The June 2002 exam was based on the new Body of Knowledge, as will all future exams until it is revised again. But what has actually changed? While this is a critical issue for anyone planning to write the certification exam, and has been working from the old BoK, it should also be important to those of us who are already certified. What are we now expected to know? Many of you have expressed strong feelings about some of the content of the old Body of Knowledge in previous meetings. Do you like the new one better? Check the certification web site for details on your favourite (or most hated) section and let?s talk about it.

This presentation will look at the differences and similarities between the two versions: the topics which have been emphasised or de-emphasised, the level of cognition expected for each, the new structure and point counts, and the new content covering the newer technology.

Sherry Heinze has twenty years of information technology experience as a Tester, Trainer, Analyst and Technical Writer. She has a broad background in design, testing, implementation, training, documentation and user support. Sherry has worked for large corporations with detailed standards and guidelines for development projects, and for small organizations without either. Sherry is an ASQ member and an ASQ Certified Software Quality Engineer.

This presentation will address key issues surrounding processes and related standards applicable to the software industry, and will provide insightful information in response to:

• What is a process?
• The pros and cons of documenting your processes
• What is happening in the software industry regarding processes?
• Standards and Models -- which ones are relevant and how are they being applied in the software industry?

Marielle Chevrier is the owner of Tantara Inc., a software business consulting firm specialized in best practices for improving software process effectiveness and software product performance. Marielle has over 20 years experience in software process and quality improvement initiatives. Her experience spans software organizations ranging from 10 employees to over 300, involving a wide variety of applications and industries. Marielle holds many credentials including a certificate for both a "Certified Provisional SPICE Assessor" and "Provisional ISO 9000 Auditor". Marielle has helped many software organizations improve their software development capabilities. Her combination of consulting and training experience can benefit others in learning how software processes can effectively improve their business. For more information about Tantara and Marielle, see http://www.tantara.ab.ca/.

This session of the Software Quality Discussion Group will be an introductory level presentation and discussion on Software Engineering Processes. Our facilitator for the evening will be Colette Bielech of Autodesk.

Colette Bielech has over 20 years experience in the software development industry, in avionics, telecommunications, SCADA, and commercial environments. Her exposure to a broad scope of software products has provided her an understanding of the different quality and business issues that affect software development and processes. Colette is IEEE Senior Member and an ASQ Certified Software Quality Engineer.

Colette is currently the quality team leader for the MapGuide product at Autodesk Development Canada. MapGuide is a Web based product suite for publishing location and mapping information on the Web. The product has been selling internationally for six years.

The topic of Software Engineering Processes, as described in the new ASQ CSQE Body of Knowledge, comprises:

3. SOFTWARE ENGINEERING PROCESSES

1. Environmental conditions
1. Life cycles

   Compare and evaluate the characteristics of spiral, waterfall, incremental, rapid prototyping, V-model, etc. Differentiate these life cycles, describe what they are designed to do, what their benefits are, and in what situations they should be used. (Evaluation)

2. Systems architecture

   Identify, describe, evaluate, and distinguish between system architectures, including client server, n tier, B to B, B to C, and B to E, web (internet/intranet/extranet) and wireless development, messaging and collaboration software, etc. (Analysis)

2. Requirements management
1. Requirements prioritization and evaluation

   Describe, assess, prioritize, and evaluate the requirements for verifying software correctness, consistency, completeness, and testability. Determine what should be covered in a requirements statement, how to specify a requirement, etc. (Evaluation)

2. Requirements change management

   Define, describe, and evaluate various elements of managing requirements change, including what processes should be followed, when requirements need to change, what review processes to use, etc. Define the effect of changing requirements at various stages of the project life cycle. (Evaluation)

3. Bi-directional requirements traceability

   Describe, select, and evaluate various traceability elements, including requirements to design, design to code, and requirements to test. Describe and apply traceability tools and mechanisms, such as system verification diagrams, traceability matrices, etc. (Evaluation)

   [NOTE: Traceability of configuration items is covered in VII.C.5.]

3. Requirements engineering
1. Requirement types

   Define, describe, and analyze various requirement types such as security, regulatory, quality, feature and product functionality, etc., and the significant elements of each. (Analysis)

2. Requirements elicitation

   Define and describe various elicitation methods, including using tools such as quality function deployment (QFD), joint application development (JAD), customer needs analysis, etc. Describe the key steps necessary for gathering product requirement details, and identify common causes of failure to comply with requirements. (Comprehension)

3. Requirements analysis and modeling

   Describe, select, and analyze tools such as data flow diagrams (DFDs), entity relationship diagrams (ERDs), use cases, etc. Describe how they are used at different phases of development and requirements specifications. (Analysis)

4. System & software requirements specifications

   Define and distinguish between these two types of specifications and their purpose, and describe their relationship to each other. (Analysis)

4. Analysis, design, & development methods and tools
1. Software design methods

   Define and use various design methods, including object-oriented analysis and design (OOAD), structured analysis and design (SAD), unified modeling language (UML), etc. Identify the steps used in program design and explain their uses. (Application)

2. Types of software reuse

   Define, describe, and differentiate the use of various reuse methods including reengineering, reverse engineering, plug-and-play, etc., and describe the design paradigms that address these concepts. (Application)

3. Clean room and other formal methods

   Define and describe these methods and their benefits. (Comprehension)

4. Software development tools

   Identify, describe, use, and distinguish between various tools used for modeling, code analysis, documentation, relational databases, etc. (Application)

5. Maintenance management
1. Maintenance types

   Describe the characteristics of corrective, adaptive, and perfective maintenance types and their benefits and risks. (Comprehension)

2. Operational maintenance

   Describe the various categories of and activities involved in providing operational services to the customer, managing application portfolios, and providing basic software maintenance. (Comprehension)

This presentation will endeavour to provide some understanding of the Quality Assurance implications of Agile Processes. The Agile Alliance is trying to change the conversation about the standard software development processes that are used on projects. Extreme Programming and Scrum are starting to be used on some projects, but what does all of this mean for Quality Assurance?

1. Why is there a shift towards the so-called Agile Methodologies?

Understanding the motivating factors as to why organizations and projects go Agile in the first place, is key to understanding teh way that Agile projects change what is needed from Quality Assurance.

2. Do we need Agile Quality Assurance?

Surely the traditional quality assurance processes and techniques are sufficent? After all the Agile processes are not all that different - or are they?

3. Agile Testing - another buzzword or a step in the right direction?

Brain Marick set up a mailing list and website dedicated to Agile Testing, http://testing.com/agile/, so at least one tester thinks that Agile is different, but how different is it for testers?

4. Do Agile Methods require changes in the way we do Quality Assurance?

With this background in place, we can now explore the aspects of Quality Assurance that are unchanged with Agile processes and those aspects of Quality Assurance that might need to change.

Pete McBreen is the author of "Software Craftsmanship" and "Questioning Extreme Programming". He is an independent consultant who actually enjoys writing and delivering software. Despite spending a lot of time writing, teaching and mentoring, he goes out of his way to ensure that he does hands-on coding on a live project every year. Pete specializes in finding creative solutions to problems that software developers face. After many years of working on formal and informal process improvement initiatives, he took a sideways look at the problem and realized, "Software development is meant to be fun. If it isn't, the process is wrong."

What a great opportunity to meet with fellow quality practitioners to partake of some fine vituals, hoist a few and talk about software quality, amongst other things, I'm certain.

We will be convening in Great Room "C" at the Sandman Hotel in downtown Calgary. The Sandman is located on the NE corner of the intersection of 7th Avenue and 8th Street S.W., right beside the LRT station. Doors open at 18:00. There'll be a cash bar and buffet to sustain us throughout the evening. I'm looking for a fabulous turnout this year.

This session will look at management and process issues involved in software configuration management in a practical, real-world situation. The discussion will overview the key components of classic configuration management -- identification, control, accounting and audits. The presentation will also cover use of configuration management tools, and the importance of teams and clearly defined responsibilities in implementing a working environment.

Anthony Ebsworth has been practicing Configuration Management for most of his 15 years in the high tech industry. He has developed and adapted CM processes, tools, and teams in space, military and commercial environments - from a software start up through to multinationals. Anthony has developed and implemented CM needs within software, hardware and systems development teams. He has also delivered CM to meet manufacturing and life cycle support requirements.

Recently he was Director of Corporate Quality at a software development company. Mr. Ebsworth studied psychology at McGill University and completed a Management Development diploma at the University of Calgary in 1999.

Earned Value is a project management technique which can be used as a leading performance indicator allowing project managers to identify and control project problems before they become insurmountable. Earned Value provides significant improvement over the traditional project measures. Traditional project measurement uses planned expenditures and actual costs. Earned Value uses the traditional project measures plus a third dimension - the actual accomplishment. Actual accomplishment gives project managers greater insight into potential project risks. It also provides more accurate estimates for the estimated completion costs and schedule. With these project leading performance indicators, project managers can proactively manage their project with a greater rate of success.

Mr. Tse is the programme manager of PM Governance, Business Performance, EDS Canada -- Solutions Consulting. He has been managing consultant, senior IT manager, technology manager, and software engineer in the sectors of IT consulting services, Healthcare, Banking, Government and Telecommunication. Mr. Tse has had a long and successful consulting/management career in a broad range of information technology environments. He has had a wide variety of national and international experience in realizing business benefits and improving business performance through programme and project management, and the application of information technology.

Mr. Tse holds a Masters degree in Electrical Engineering from the University of Alberta, Canada and a Bachelor of Science (Honours) in Computer and Communication Engineering from the University of Essex, UK. He is registered Professional Engineer in Alberta, certified project management professional (PMP) of Project Management Institute (PMI) and a senior member of The Institute of Electrical and Electronics Engineers (IEEE).

This session of the Software Quality Discussion Group will be an introductory level presentation and discussion on Software Project Management. Our facilitator for the evening will be Kenneth Fung, Program Director (Science and Technology), Faculty of Continuing Education, University of Calgary.

The topic of Software Project Management, as described in the new ASQ CSQE Body of Knowledge, comprises:

4. PROGRAM AND PROJECT MANAGEMENT

1. Planning
1. Project planning elements

   Describe and use factors such as forecasts, resources, schedules, etc., to develop, initiate, and accomplish project goals. (Application)

2. Goal-setting and deployment

   Identify and use milestones, objectives achieved, task duration, and other goal-setting and deployment methods. (Application)

3. Project planning tools

   Define, apply, and analyze various methods of managing risk, estimating costs, scheduling resources, etc. using tools such as PERT charts, critical path method (CPM), work breakdown structure (WBS), etc. (Analysis)

   [NOTE: Gantt charts are covered in IV.B.1.]

4. Cost and value data

   Identify and use various methods for calculating project-related data such as earned value, development investment costs, etc. (Application)

2. Tracking and controlling
1. Phase transition control techniques

   Develop and use various control techniques for tracking projects, including entry/exit criteria, phase gate reviews, Gantt charts, etc. (Analysis)

2. Interpreting and reporting cost of quality (COQ) data

   Review, interpret, and report COQ data and evaluate how each category is affected by continuous improvement strategies. (Evaluation)

   [NOTE: The definitions and distinctions between these categories are covered in II.B.3.]

3. Tracking elements and methods

   Describe, assess, and apply different tracking methods, including establishing metrics for costs, deliverables, productivity, etc., creating and evaluating status reports and life-cycle phase reports, measuring changes in earned value, evaluating changes in business conditions, etc. (Evaluation)

   [NOTE: Calculating earned value is covered in IV. A. 4.]

4. Project reviews

   Define, use, and differentiate various types of reviews, including post-project, senior management, team, etc., and use closed-loop methodologies to improve projects as a result of lessons learned. (Analysis)

3. Risk management
1. Risk management planning methods

   Define, integrate, and analyze various risk management methods, including assessing, preventing, and mitigating risk with respect to critical aspects of a project and its supporting strategies. (Synthesis)

2. Risk probability

   Describe and evaluate various risk warning signs, assess risk probability and impact, and develop contingency plans. (Evaluation)

3. Product release decisions

   Identify situations and factors that require trade-offs on product release decisions. Develop and analyze various ways of bringing a project back on track when problems occur that affect quality, scheduling, customer requirements, product functionality, etc. (Evaluation)

4. Software security, safety, and hazard analysis issues

   Identify, review, and evaluate various factors related to software security, safety-critical software, and hazard analyses. Identify and describe rationales for developing safety plans and for implementing hazard analyses. (Analysis)

   [NOTE: The legal aspects of product safety are covered in I.D.2.]

KENNETH FUNG, B.Sc., CMA, CCP, MBA, ISP, PMP, CSQE, has 10 years of Information Technology experience as systems analyst, project manager and QA team leader and 10+ business experience in accounting and finance. He has worked, implemented systems and led cross functional teams in oil and gas, medical claim processing, banking, high-tech, Information Technology, manufacturing and distribution industries in Calgary, Winnipeg, Vancouver, Portland, Chicago, Atlanta, Austin, San Francisco, Hong Kong and Beijing. He has developed and taught project management courses at Mount Royal College, Motorola and Cisco as well as Business Process Reengineering workshop, accounting and management courses. He is working towards a Ph.D. in Information Systems.

Quality counts. When a major oil and gas company wanted tools to proactively manage loss control activities it wanted them out in the field where incidents are most likely to occur. Field workers can be a challenging crowd when it comes to IT. What started as a legacy system rewrite grew into a full fledged distributed .NET implementation. Jim Stuart and his team delivered an application that hits the mark with field and head office users. Join us as we share the challenges and rewards from this successful .NET project. We will explore how the field was engaged, the business benefits, the technology strategy, and how Rational Unified Process methodology was used to mitigate risk on this fixed price project.

Jim Stuart is a Principle with Sierra Systems and a proven technical project leader with over 16 years' experience in the industry. Jim's last three engagements have successfully implemented web based solutions utilizing Microsoft .NET and J2EE technologies. Recently Jim has been managing the delivery of B2B and B2C eBusiness solutions.

Barry Oxby is a Partner with Sierra Systems. With over twenty years in the business, Barry has extensive expertise in information technology delivery and a wide range of business experience. His background includes a broad range of positions including Operations Research, IT Director, Senior Consultant and Business Development Manager. He has worked with numerous emerging and Fortune 500 clients in Western Canada. Barry focuses on new economy strategy, IT planning, business development and project delivery. He is responsible for delivery management at Sierra Systems Calgary.

In addition to his professional credentials, Barry serves on the IT Advisory Board for SAIT.

This session of the Software Quality Discussion Group will be an introductory level presentation and discussion on Software Inspections. Our facilitator for the evening will be Christine Bovaird of Nortel.

The topic of Software Inspections, as described in the new ASQ CSQE Body of Knowledge, comprises:

6. SOFTWARE VERIFICATION AND VALIDATION (V&V)

2. Reviews and inspections
1. Types

   Define, describe, and use various types of reviews and inspections, including desk-checking, walk-throughs, Fagan and Gilb inspections, technical accomplishments, resource utilization, future planning, etc. (Application)

2. Items

   Identify, describe, and use various review and inspection items, including proposals, project charters, specifications, code, tests, etc. (Application)

3. Processes

   Define, describe, and use various review and inspection processes to examine objectives, criteria, techniques, methods, etc. (Application)

4. Data collection, reports, and summaries

   Define, describe, and use terms related to data collection, including preparation rates, defect density yield, phase containment, etc. (Application)

Over the past 7 years, Christine Bovaird has worked in the Software Industry in the following areas: Quality Assurance, Test and Process. Experience ranges from small entrepreneurial companies to major service providers within the Oil and Gas Sector where Christine has setup Software and Data Test Teams and practices.

Two years ago, Christine moved to Nortel Wireless Division in order to experience Software Process on an International scale. Her focus has been the experimentation and implementation of formal code inspection processes, including development of an inspection effectiveness metrics program and standards.

Education

• ASQ - CQM
• ASQ - CSQE
• University of Calgary - Management Certificate
• British Columbia Institute of Technology - Advanced Diploma in Civil Engineering Technology - Geographic Information Systems
• B.Sc. Geology, University of New Brunswick
• Misc courses in Software Metrics, Quality Auditing, Advanced Test Design

It has been said that smart people learn lessons from their own mistakes while wise people learn lessons from the mistakes of others. Successful people learn from failures.

The failure of software to behave as intended provides testers, developers and business sponsors the opportunity to learn from these failures, adapt and ultimately deliver a successful application. Anyone remotely involved in software development has experienced failure, made mistakes, and ultimately been given an opportunity to learn from them.

This presentation is based upon experiences, both good and bad, and lessons learned while testing a successful e-commerce web site (sales greater than $1,000,000 per day) in the spring of 2002.

Alastair Handley is an independent consultant based in Calgary Alberta. His background includes spatial information systems, project management, teaching, team leading, software development and software testing. At this time Alastair is developing wireless applications and trying to figure efficient ways to test them.

We will discuss and explore test-driven development using the JUnit framework, with examples, within what is commonly referred to as the Traffic Light Metaphor. Topics will include automation, continuous integration, and regression testing at the unit test level. The recently developed FitNesse framework from ObjectMentor, and relevant books related to TDD, will also be investigated.

Miroslav is a System Engineer with Borland Canada. Aside from continually learning new things, his current role involves pre/post sales technical support, workshop deliver and consulting.

Miroslav had the privilege of co-authoring a book on eXtreme Programming with Dave Astels, and Granville Miller: A Practical Guide to eXtreme Programming. He?s been a proponent of extreme programming from early on, following developments in the area, and taking advantages of opportunities to apply its tenets.

Miroslav?s current professional interests include patterns, agile methodologies, and instructional /coaching techniques.

Four basic values put forth in the Agile Manifesto are:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Knowing there is value in the items on the right, but valuing the items on the left more.

The presentation will show how the quality philosphy, principles, and processes as set out in the CQSE guidelines, can align with these values.

Examples of Agile Development Practices are taken from XP and SCRUM. The focus of the presentation will be on these processes:

• Requirements Engineering and Management
  • prioritization and evaluation
  • requirements change management
  • traceability
  • Requirement types & Requirements elicitation
  • System and software requirements specifications
• Development analysis, design, methods and tools
  • Software design methods
  • Software development tools
• Prevention vs. detection

Team Management and its importance in an agile world, Project Tracking & Risk Managment, will also be addressed.

Janet Gregory started out as a software developer following graduation from the University of Alberta with a degree in Computer Science, but changed directions after a few years to focus on quality. Janet received her ASQ Quality Management certification in 1999.

Janet established the first quality initiatives at EFA software and was instrumental in getting their test team going. She then spent a year at Wind River Systems, a leader in embedded software as the Q/A Manager for their Consumer Products Group. She was instrumental in establishing a corporate Product Life Cycle, and introduced their quality system including early involvement of the test team in the development cycle. It was there Janet was first introduced to Extreme Programming and test first development. Later, as a QE Lead in a small agile development team at TCPL, she became aware of all the positive effects that agile development process can bring to a development team.

Janet currently works at Envista Technologies Inc., and is leading the implementation of an agile development process. She is on the organizing committee of the Calgary Agile Methods User Group (CAMUG), and helped edit "Testing Extreme Programming" by Lisa Crispin and Tip House. Although she will be using this book as a reference in her talk on QA Processes in an Agile Environment, the session will focus on much more than just testing. She will also discuss how other quality processes fit and are adapted to agile methodologies.

Software testing and QA is all about risk assessment and risk management. To effectively perform these roles we must clearly understand the business risk factors and influences associated with business processes and business activities. This presentation will show you how to perform a risk assessment from a business and testing perspective. With this information you will be able to more effectively direct the QA/QC efforts and be more business focused in their execution.

Immanuel Kant, the great philosopher, was in the habit of keeping paper and pen on his bedside table. Often he would wake up in the middle of the night, and jotdown a thought or idea. Then he would go back to sleep. One morning, he awoke convinced that he had discovered the answer to a question that had puzzled him for months. While dreaming, he had dazzling insight that seemed to break the mental logjam. He seized the paper on his bedside table in eager anticipation. There he found the words: Think in different terms.

Here in North America, a great number of companies have arrived at the same conclusion. Based on the number of business automation projects that have exceeded budget, exceeded schedules or failed to deliver on the requirements, companies are now looking for different ways to assess and mitigate project risks. The end objective deliver on time, on budget and deliver what the business requires.

Our guest speaker today - Bryan Schultz will explore how to perform a risk assessment on business automation projects in different terms - software quality. As you will learn, Bryan?s approach helps mitigate the commonly encountered factors that threaten the success of such projects.

Mr. Schultz has fourteen years of experience in computer system quality assurance, project management and quality control. He is both an instructor and keynote speaker in Canada and the U.S. on the subject of software testing and quality assurance. Bryan is a Certified Quality Analyst and a Certified Software Test Engineer and he is currently writing a book on the topic of risk management.

Validating the quality of requirements is a problem on many projects. Personally I see many projects that are exceedingly stressed because insufficient brainpower was invested in really getting to grips with what is needed and wanted. All too often, people jump into solution mode before they really understand the problem domain.

Agile processes can make this tendency worse, especially if people think that they are supposed to start implementing a solution quickly. Luckily however, Agile projects have a built in feedback mechanism that prevents the team getting too far off track - the user gets to use the software really early on as well, and as soon as this happens, the team will listen to what the users say. Yeah, really...

This is where a quality assurance person earns the big bucks. We have to listen to the users feedback, and then present it to the team in such a way as to enable the team to take corrective action. My personal opinion is that this approach is wasteful, and too late on in the process.

If Agile projects insist on trying to work with "requirements as conversation," someone on the team, ideally the quality assurance person, has to take on the task of creating a permanent record of these conversations. No, I'm not suggesting that the QA person take a course in technical writing on how to produce tree killing documents that land on a desk with an "almighty thud".

What I am suggesting is that the QA person should be proactive in recording what the user expects to be able to do once the software is delivered. Why? Because we are the ones who will be expected to tell the user whether their software works or not. So enlightened self interest suggests that we need to document the requirements ourselves.

Appropriate documentation for requirements in agile projects is the topic of this talk.

Pete McBreen is the author of "Software Craftsmanship" and "Questioning Extreme Programming". He is an independent consultant who actually enjoys writing and delivering software. Despite spending a lot of time writing, teaching and mentoring, he goes out of his way to ensure that he does hands-on coding on a live project every year. Pete specializes in finding creative solutions to problems that software developers face. After many years of working on formal and informal process improvement initiatives, he took a sideways look at the problem and realized, "Software development is meant to be fun. If it isn't, the process is wrong."

This is our annual planning session where organizers, volunteers and participants, active or otherwise, get a chance to make their mark on next years sessions. Everything is up for discussion. Bring your ideas and suggestions to make this an even better discussion group next year.