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.

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

1. Goals and objectives
   • Quality goals and objectives
   • Outsourced services
   • Planning
   • Software quality management (SQM) systems documentation
   • Customer requirements
2. Methodologies
   • Review, inspection, and testing
   • Change management methods
   • Cost of quality (COQ)
   • Quality data tracking
   • Problem reporting and corrective action procedures
   • Quality improvement processes
3. Audits
   • Program development and administration
   • Audit preparation and execution
   • Audit reporting and follow up

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.

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.

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?

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.

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

1. Environmental conditions
   • Life cycles
   • Systems architecture
2. Requirements management
   • Requirements prioritization and evaluation
   • Requirements change management
   • Bi-directional requirements traceability
3. Requirements engineering
   • Requirement types
   • Requirements elicitation
   • Requirements analysis and modeling
   • System & software requirements specifications
4. Analysis, design, & development methods and tools
   • Software design methods
   • Types of software reuse
   • Clean room and other formal methods
   • Software development tools
5. Maintenance management
   • Maintenance types
   • Operational maintenance

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?

• 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.
• 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?
• 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?
• 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.

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.

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.

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:

1. Planning
   • Project planning elements
   • Goal-setting and deployment
   • Project planning tools
   • Cost and value data
2. Tracking and controlling
   • Phase transition control techniques
   • Interpreting and reporting cost of quality (COQ) data
   • Tracking elements and methods
   • Project reviews
3. Risk management
   • Risk management planning methods
   • Risk probability
   • Product release decisions
   • Software security, safety, and hazard analysis issues

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.

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:

1. Reviews and inspections
   • 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)
   • Items
     Identify, describe, and use various review and inspection items, including proposals, project charters, specifications, code, tests, etc. (Application)
   • Processes
     Define, describe, and use various review and inspection processes to examine objectives, criteria, techniques, methods, etc. (Application)
   • Data collection, reports, and summaries
     Define, describe, and use terms related to data collection, including preparation rates, defect density yield, phase containment, etc. (Application)

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.

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.

Four basic values put forth in the Agile Manifesto are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• 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.

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.

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.

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.