This is going to be more of a lively discussion than a presentation where we will propose a number of points and participants can point out their believed fallacies in what is being said. The presentation/discussion will start with some agreement on definition of terms (e.g. verification vs. validation, assurance vs. control, etc.) and then dive into some interesting discussion points including:

• System development views;
• What a good professional developer actually does all day;
• Structured vs. object oriented development;
• Brief overview of various software development processes/techniques used since the '70s through to today including all the various agile techniques and how they compare;
• What a good project manager needs to be doing; and will end with;
• How any technique out there must be customized to the company culture and developers to be successful.

The question is no longer. "Will Agile Work?", but "How do we implement Agile in our organization?"; and, for the purposes of this presentation, "Do agile processes address quality issues that many organizations face today?"

At Agile 2006 in Minneapolis, experience reports included such topics as the "Cost of Code Quality", "Agile Metrics", and "Embracing CMMI". All of these certainly sound like quality issues! Methodologies like Lean Software Development talk about eliminating waste, building quality in, and creating knowledge. We will explore some of these ideas in a little more detail.

This presentation will explore how we can use dynamic project management techniques to manage quality expectations in software development.

• The Tool: The SMART Priority Triangle
• The Result: Sponsor and team understanding of how quality and other decisions are made
• The effect: We get the right balance of quality, scope, cost and time.

Over twenty three years ago, Exploratory Testing was defined by Cem Kaner as simultaneous test design, execution and learning. The concept isn't new, and all testers engage in some sort of exploratory testing at least some of the time. However, it is often misunderstood, and sometimes dismissed as "ad hoc" or "unstructured". This discussion will shed some light on the topic, from the perspective of an exploratory testing practitioner.

In the software development community few topics are debated as hotly as the choice of programming language. In this talk we'll explore the potential impact of language choice on software quality - if there is any impact at all. Is it true that that skill level of the programmer matters more than the language used? Is making languages easier to use lowering quality because they are enabling lesser skilled developers to build software? What if we compare developers of equal skill level? How does language choice affect quality in that case? We will explore these questions and more.

In recent years, organizations have refocused on their business processes in a way we haven't seen since the heyday of Business Process Reengineering in the early 1990s. In 2006, enterprise software is increasingly process-oriented, Business Process Management suites are gaining in popularity, Business Process Outsourcing is becoming commonplace, and, of course, everyone knows that business processes are crucial to organizational performance. Business analysts and software developers alike need skills in working with business processes in order to participate in and support these exciting initiatives. On a more day-to-day level, a clear and understandable workflow model provides a great framework and is a great way to encourage business involvement in discovering application requirements.

After a quick review of "process orientation," and how we got to where we are now, we'll turn our attention to modeling the workflow of a business process. The essential techniques will be illustrated by looking at some of the problems that arise again and again in process modeling and analysis efforts:

• Missing the point about what a "business process" really is -- what goes wrong if you define your processes incorrectly, and how to identify true business processes
• Getting lost following threads in all directions -- why modeling begins with scope, and how to clarify and manage the scope of your process modeling effort
• Choosing the wrong process modeling technique -- what some of the available process modeling techniques are, and what particular strengths are offered by workflow models ("swimlane diagrams")
• Choosing the wrong technique again! -- how it's easy to settle on the wrong variant of a workflow modeling approach, and why complex or rigorous techniques that are great for technical implementation are often less effective than simple techniques. This will be backed up with guidelines for turning less detail into more information
• Inaccuracy and inconsistency in workflow models -- the basic structures in workflow modeling, managing detail, knowing when to stop, and how to avoid some of the most common pitfalls.

Other topics we'll touch on along the way will include the six critical factors in a business process, Six Sigma vs. BPM vs. BPR, and how use cases and service specifications fit in. Throughout, key points will be illustrated with real-life examples and short tutorials on the techniques.

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're meeting at the Auburn Saloon again this year, since our two previous outings here were hugely successful. The Auburn is located 119 9th Avenue SW. It's on the south side of 9th Avenue, on the west side of the Palliser Square office tower, directly across from the Glenbow Museum.

As always, this is an informal affair. We can start congregating around 5:30 pm and wrap up any time we want. Food will be served starting shortly after 6:00.

This presentation describes EnCana's IT co-sourcing strategy, one that is distinct from out-sourcing, including the results to date, and lessons learned. It includes information on how EnCana determines which services to cosource, what is retained in-house, and expectations of the service provider. There is information on what has worked well, and where there is still work to do in various types of cosourced service, including client services, ERP support, infrastructure support, and middleware support and development. Finally, some lessons learned will be presented which are being applied to make future cosourcing projects run more smoothly.

A "model" is a representation of something we are trying to understand. Software testers use models so much in their work, we sometimes model software unconsciously. Using different models reveals different kinds of information about the software we are testing. As a result, developing modeling skills, and developing the ability to model software in different ways aids testing. Different testers have their own favorite models and ideas, so sharing knowledge with each other is important.

Testers aren't the only people involved in software development and maintenance who model. Some analysts, architects, database designers, and developers model, some more formally than others. In this session, we will share ideas, and want to hear your ideas on modeling.

How do you model? What sort of models do you develop or use? What kind of modeling tools do you find helpful? Two testers with different backgrounds discuss the types of models they prefer, and some of the modeling tools used in software development. In an experiential segment, we will create a model as a group.

This is our first open discussion session this season; the topic is Software Estimation. This is your opportunity to hold forth on what Software Estimation means to you; how you go about estimating software development efforts, and what success you're having; what you're doing to improve the effeciency of your estimating process, and, ultimately, your success ratio; and how, in fact, do you define "success" in the context of Software Estimation?

Earned Value Analysis (EVA) offers a way of tracking project progress and forecasting likely completion costs. It compares actual progress to date against projected progress and allows the calculation of performance indexes that help indicate how the project is progressing, and how much ahead or behind it is. However it relies upon the quality of the baseline plan, and herein lays the problem with its use on Agile projects. On Agile projects we know that initial plans are likely to change, they will evolve and be refined as project velocity and true requirements emerge. So then, how can we employ EVA on Agile projects to track how we are doing?

Fortunately we do not have to; there are Agile metrics that can replace each of the earned value variance and index measures. We can answer the same, "when will it be done?" and "how much will it cost?" questions by applying Agile alternatives to earned value measures and this presentation will show you how.

After an explanation of traditional earned value the Agile alternatives will be introduced along with examples of how to apply them. Backed up with case studies and links to the Agile 2006 conference research paper that this presentation draws from, the Agile replacements to earned value are explored and explained.

How do you effectively extract customer needs and turn them into a product solution without burying your team in complex and rigid process? The key focus areas of requirements engineering and how to get consistently good results with minimal process overhead will be discussed. The essence of the requirements elicitation methods and what you can do to ensure that you extract the customer's true needs will be covered. Also we will look at requirements development basics and a simple approach to ensuring you don't miss anything in the process of turning customer needs into a product solution. The appropriate use of checklists and 'simple' flow diagrams can vastly improve the effectiveness of your requirements activities. The premise is: if you can't capture the heart of a process or method in less than 3 pages then you don't understand it well enough to be explaining it to others.

The Petroleum industry is spending more money than ever before to make information complete, correct, current, reachable and usable. This is, as anyone who has tried it knows only too well, not a trivial undertaking. In a typical Oil and Gas company, information is stored in digital silos that are not easily integrated and correlated. Financial information and electronic documents are not stored in the same systems as other business and technical information.

Users rarely care where and how information is managed. But they do care about problems such as data errors, inconsistencies, duplication or incomplete data. We need to constantly improve our policies, practices and procedures to ensure that our user's needs are being met. Business rules are emerging as powerful tools that can help your company create and manage high quality data and information.

Often, there are tens of systems holding critical decision analysis information hostage. Sometimes the same kind of information is stored in more than one system; all too often they are incomplete or even contradictory! Our job as data managers is to ferret these systems out, figure out what kinds of information exist, determine where it's being stored, and decide how to make it available to a user community in a meaningful, easy to understand way.

Standards set the stage to make these processes easier and more effective by enabling consistent, integrated, high quality business practices within our industry. This discussion will examine some of the issues related to developing policies, practices and procedures in an Oil and Gas company. We'll talk about the importance of business rules, semantics and good communication. Based on PPDM member feedback, we'll lay out some standards based recommendations for data management best practices that will help prepare your company to succeed and set the stage for the future.

Maximizing IT Value Through Operational Excellence provides a practical, process driven approach based on 12 established best practices in ASM. This presentation will review our ASM 12 best practices that help attain a state of Operational Excellence within IT organizations where the installed base of computer applications run with the predictability, reliability and quality of a utility. Learn the organizational, strategic and cultural differences between ASM and application development, including its focus on problem solving and continuous improvement. Learn the IT Governance and Integrity of ASM from change control rules to the role of steering committees. Learn how to take control and accountability over all your IT applications and make sure they work.

Maximizing IT Value through Operational Excellence is brought to you by RIS, the Applications Support and Maintenance Company. ( www.ris.ca) For more than 25 years, RIS has supported, maintained and enhanced mission-critical computer applications for some of North America's best run corporations. During these years, RIS has sustained a comprehensive research and development program into best practices in Applications Support and Maintenance (ASM). The results of this practice-based research is RIS' refereed papers, published books, ASM-specific software, university-level management courses, plus a formal ASM certification program for IT professionals.

The success of any software project starts with a sound plan. The software industry has a long history of late delivery and overspent projects. Interestingly enough, very few companies keep this history in a retrievable form. As a result, each project starts without the learnings of the previous. This presentation will first outline the benefit of having history information available for project estimation, describe the inherent complexity of estimating medium to large software projects and then demonstrate a tool that assists in developing estimates. At the conclusion of this presentation, the attendees will discover that software projects are really similar in nature and that a little math with some industry history information can go a long way to developing credible defensible estimates.

This session will provide an overview, from a business user perspective, why the implementation of business process management (BPM) sets the stage for effective information management within today's organizations. Data creation, storage and management have no value to the business user if they do not enable and support the business activities and processes they are involved in. We must move from being "data centric" to "process centric" to effectively meet and sustain the strategic objectives of an organization.

The session also will define what BPM is, its current state, a framework for implementing BPM as a cultural and management philosophy within an organization, and the opportunities for data management and IT to act as an enabler and supporter of this critical shift in business management practice.

User Experience is an umbrella term used to describe all the factors that contribute to a site user's overall perception of a system. The user, rather than the system, is placed at the center of the design process. This approach, called "user-centered design" incorporates user concerns and advocacy from the beginning of the design process and dictates that the needs of the user should be foremost in any design decisions.

The design of a strong User Experience includes tasks and elements surrounding the creation of the presentation layer of a system: business objectives, user needs analysis, functional specification, content requirements, interaction design, information architecture, interface design, information design and visual design.

Usability refers to the measurement of the User Experience. Usability concepts and principles can be used to measure the quality of the User Experience. Usability analysis can be conducted by any person who is trained in assessing screens using usability principles. Usability testing implements more formal methods of using usability principles to measure the user experience. There are many different types of tests that can be used, from simple paper prototyping to comprehensive user performance testing.

Usability testing can sometimes be conducted in collaboration with QA cycles and, certainly, QA personnel can be trained to help identify usability concerns. In an effort to produce the best product possible, the symbiotic relationship between User Experience and Usability must be utilized as much as possible. Collaboration between teams will go far in supporting this goal.

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.