From The Academe to Industry: Context-Driven Software Engineering Matthew Heusser Excelon Development – xndev.com - Presented to CS 611 at GVSU, 4/6/2005

Our story so far … 1950 & 1960’s – Code and fix 1970’s – First Large Scale Software Dev –Evolving Systems 1980’s – Personal Computers 1990’s – Web-Based Standards

Meanwhile … back at the ranch ‘Best Practice’ Fever ‘Maturity Model’ Mania Symptoms: –Factory Mentality –Loss of innovation –Lots and lots of paperwork –Process, Process, Process –People referred to as ‘resources’ What’s going on here?

About prescriptive models Summarized in the phase ‘Just do it this way and you’ll be fine’ Based on past history Past history as a corn field Past history as a personal exercise

Reality: Many “best practices” with a large, proven body of experience are based on projects developed in the 1970’s when: –Specialized training in development didn’t exist –Developers were mostly physicists and mathematicians –Hardware delays made it impossible to write code during initial development (system/360, etc)

Reality: What does “best” mean? –Best for who? –Best for when? –Ignores concept of context What’s a practice?

A walk with DeMarco … Do people matter? Have you spent five minutes talking about the implications of that?

Manifesto for Agile SWDev We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. -

Agile Principles … Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.

More Principles … Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Simplicity--the art of maximizing the amount of work not done--is essential.

The medical guy meets the microsoftie... … and vice versa

Context-Driven Testing The value of any practice depends on its context. There are good practices in context, but there are no best practices. People, working together, are the most important part of any project's context. Projects unfold over time in ways that are often not predictable. The product is a solution. If the problem isn't solved, the product doesn't work. Good software testing is a challenging intellectual process. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products. –

Software Engineering Universalism … and other completely bogus ideas

Context Driven Software Engineering What is Software Engineering, exactly? What is context-driven SE?

In conclusion: “The only legitimate purpose for process is to solve a problem. What problem are we trying to solve?” –James Bach Think for yourself. Be wary of universal standards.

Discussion