Wow - I am amazed at the amount of models there are out there, both ISO and non-ISO, for software design and development processes.

I am particularly intrigued by what is termed 'agile' software development.

To me this appears to be an attempt to justify and methodise (if that is a word) the normal ad-hoc approach to software development.

Also techniques such as XP appear to attempt to 'inspect quality in' to the software product.

The boffins appear to claim that software design cannot follow traditional design processes that have been employed in mechanical and construction design, in particular things like design planning cannot be done.

This sounds very lame to be, what do others think ?

Martin, it's been ages since I have written any code. FORTRAN ring a bell?

Still, I'd have to agree: lame, lame lame.

But, with software, instead of finding the time to do it again, all too often they find the time to fix it in the next version. Shame, shame, shame.

Agile software development is one of those buzzwords that can work if you play it right. The traditional method of software design known as the waterfall method doesn't work in the "real word". With the traditional method you would make a plan and then execute the plan and when completed there would be a finished software product. To compare this to a building project imagine hiring a firm to build your new facility and saying you will come by next year to move in. You will not be able to see the project at all during construction. If this is fine with you then yes “lame” is the proper response.

This doesn't work though because requirements change, and they change fast. By the time the software is finished and delivered it may very well be irrelevant and the feature set completely wrong. If on the other hand releases happen more often the software can be changed as the underlying requirements change.

The problem I have found in my software development work is clients pressure me for software. The software they want they needed last month. As such clients want code that works, and just works. They do not specifically care for mundane things such as security, documentation, software testing and benchmarking. Most of the time this doesn't matter, but when it does matter it really matters. When this happens it is always my fault. It doesn't matter if I warned the client and said that this is possible or if you want it by tomorrow we can't do full testing.

Agile methods are the solution for these problems, the hardest part though is training everyone on the methods. The client needs to understand it along with the development staff. One of the major changes I have made lately is working with unit testing. Once a client understands that the unit testing can save time and money over time they are usually fine with it.

...it's been ages since I have written any code. FORTRAN ring a bell?It does for me - About 1975 for me... Not to mention cobol... :mg:

I cruised a bit and found Roadmap to Agile Methods and Tools (http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm) What Is Agile Software Development?

In the late 1990's several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.

Early 2001 saw a workshop in Snowbird, Utah, USA, where various originators and practitioners of these methodologies met to figure out just what it was they had in common. They picked the word "agile" for an umbrella term and crafted the Manifesto for Agile Software Development, whose most important part was a statement of shared development values:

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.

Hmmmm maybe I have been doing agile programming and not realizing it. I just have been thankful I know how to do my own programming (currently in Visual Basic) to get the data I need for my charting. If I had to deal with our CIO office and software "provider" I'd have been either committed as insane or fired years ago.

I found this link today: Agile software development (http://en.wikipedia.org/wiki/Agile_programming)

I definitely agree that a lot of software development these days is rushed and needs extensive rework post-production. It can be seen often in the computer entertainment industry. Some companies, especially if not under constant pressure from the publisher, put out extremely good product, while others produce kludges that need patching right out of the box.

The software industry has some serious challenges though that make creating bug and vulnerability-free products extremely difficult.

The biggest challenge is designing software that will work as intended on practically unlimited variations of hardware configurations. It's not the same as, for example, producing a component for vehicles.

The variety of vehicles, even taking into account make, model, and accessories, is much smaller than all the varied internal components of a computer. Particular components for vehicles are also specifically designed for particular models of vehicle, limiting the overall variety that the component is required for.

With computers, software developers have to deal with a range of motherboards, memory, video cards, sound cards, etc., from multiple OEM's and resellers, and also with a huge variety of operating systems and other installed software, any combination of which could conflict with new products being added.

The other significant problem for software developers is designing the product around the human element, i.e. hackers, virus writers, and end users that are not as adept with computers. As smart-phones and other similar devices become more prevalent and programmable, consumers are finding that even these things are not safe from outside attack. In comparison, most other consumer products are not attackable in the ways that computers are..at least not at this point in time.

Maybe in the future when we get those Win XP toasters. :tg:

I would like to look at any available AGILE examples?
I have recently though about adopting a more process oriented format for further development of a software program I'm heavily involved with.
My issue:
I'm one of the developers but, my main team are located overseas (Europe) and, we have a language issue regarding translating with clarity; English to Norwegian and Vise versa. Adopting a more AGILE process is my main focus though.
Wallace.

Wallace,

I would start simple and look into Test Driven Development. Here's one link out of about a gajillion available on the web:

http://www.agiledata.org/essays/tdd.html

And depending upon your language of choice, look into some of the unit testing frameworks: JUnit, NUnt, RUnit, VBUnit, etc.

For what it's worth, about 95% of the people I know who do agile development, 2 things are true: (1) they pick and choose what elements of agile development will work for them, and adopt just those; (2) the are doing enterprise database development.

(2) is true because many have worked their entire careers on projects that start out with a huge functional spec, from which a huge design spec is created, then the project is developed in a top down approach using a waterfall lproduct development lifecycle model, with all the testing done at the end. The problem is that the requirements *always* change, the spec changes, and previous design decisions have been crippled at their knees. Meanwhile, documentation upkeep becomes such a gargantiuan task that maintaining it is often too prohibitive from a cost and timeline perspective, so it falls by the wayside. These late term changes result in timeline misses and excessive software defects.

The agile approach is to pick one piece of functionality, develop it in close conjunction with the customer, with iterative development and testing along the way. Only when that one bit of functionality is complete to mutual satisifaction do you move onto the piece of functionality.

The goal is not to eschew quality assurance mechanisms. It's to build them into the process at a small scale that's maintainable, cost efficient, and realistic.

Thanks nickh,
Thanks for the link.
I have recently experienced a potentially embarrassing program version release and, the repercussions are dynamic enough to be classed as a commercial failure.
The creation and implementation of processes that zone in on program functions that need to be stable enough and conform to customer required specs, is my primary focus at this time.
Wallace

I can give you an agile example. This is the SCRUM framework.
Here is a very good link that shows the idea: http://www.scrumforteamsystem.com/ProcessGuidance/Process/Process.html
I would really hope that some of your brave heads out there could share some experience with this framework with respect to software quality engineering.

Reviving an old discussion...

It seems these agile development practices have matured and are generally accepted. I'm wondering if anyone has any experience with requirements management in an agile environment, such as Scrum. I grew up learning that in order to control software development the requirements had to be well researched and nailed-down before writing a line of code. My software development process shows requirements being gathered, reviewed and approved before the design process starts - making for a clear and clean process.

Arguably, Scrum appears to hark back to the old days of cowboy software developers that just start coding with minimal research or understanding.

How have you defined your process when the developers are using agile techniques?