The bigger picture of application development

by Paul Kohler 31. March 2008 08:31

Last week I posted some notes of an Acceptance Testing Framework I started developing. My motivation for this is part of a larger project that is an attempt to "integrate" the typically disparate pieces of a project, things such as requirements, tests and issue tracking.

I find many companies use different tools/systems (I am counting a simple document as a "system" here, e.g. a requirements doc) for each part of the process and there is allot of duplication and converting going on. This in my eyes is a big waste of time and effort.  I am a huge fan of keeping things DRY (Don't Repeat Yourself), applying this to the full SDLC is difficult but I think possible and definitely beneficial. I see allot of importing, exporting, synchronisation and maintenance of data between these systems, even if just a document is used to produce requirements there is still allot of duplication and effort required by the developers for example to keep things in sync (for both the tests and the implementation).

Another area that bugs me is test data. A useful requirements document (I find) contains examples of what its explaining, so why not have an appendix of acceptance tests (or references to test data files)? These tests can be pushed through a testing engine of some sort and complete that difficult customer-developer loop. If a manager (or even a customer) is after a progress update, use the acceptance test results to give a real indicator instead of sitting in a meeting for 2 hours pouring over a Gantt chart making educated guesses.

Instead of a big word processing document why not access requirements via a system that allows you to see the history (diff) on a particular requirement, or link to its defects, or view pending change requests? Developers can book their development time against items that are linked to requirements - the implementation of 1 requirement can span many layers etc. Developers can make attach notes to requirements and tests.

As far as integration of existing systems is concerned, how about each area - requirement, test, timesheet - is accessed through a basic pluggable component. If the company has a bug tracking system already they can create an adapter that provides access to the data (I am thinking a simple CRUD interface), this would allow communication between existing systems.

And what about help documentation, screenshots of those screens!?

Just some thoughts ;-)

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading



Powered by BlogEngine.NET 1.4.5.10
Theme by Mads Kristensen