Jeff Johnson wrote: > I am putting together a support agreement with another software company. I > am going to maintain their application for their customers (I have been > doing work on the application as a contractor). There are no written > specifications for the application so I figured the source code could be the > specification. If there are any requests for reports or forms not included > in the source code, they would be considered enhancements and not be > included in the maintenance agreement.
I'd say that the source code is the baseline but not that it's the specification. You just said above that there are no specifications, so calling the source 'a spec' doesn't make it a spec. <g> (The old line about 'if you call a tail a leg, how many legs does a dog have?' comes to mind.) > Here is the language I used in the agreement: > > > > """Absence of Written Specifications > > Often times work is performed where there is no documentation or written > specifications and authorizations to do the work are verbal. In the event > there is no written specification both parties will agree upon a release > version of the application as a benchmark of features and functionality. > The source code of the agreed upon version will be considered the written > specification for the project. All reports, forms and processes included in > the application's source code will be included in the scope of this > Agreement and be considered "agreed upon" by both parties.""" I like the idea of specifying that a specific release of the software is the baseline for all future work going forward. I'm not sure you want to call that baseline 'specifications', since specifications has a specific meaning. (Well, to me it does, although others may disagree, and I've had customers like that - who disagree...) > Any ideas on this approach? > > By the way, I use Whil's "The Software Developer's Guide" when putting > together agreements, but he doesn't cover what happens when you enter into > an agreement where there are no written specs. Oh, I forgot that chapter. Back when I wrote it, that chapter said, in its entirety, RUN AWAY!!!!!!!!!!!!! but my publisher told me to whittle down the page count of the book so that chapter ended up on the cutting room floor. Seriously, looks like it's time for a revision, or an update, or a something, huh? I would say that the functionality provided by the mutually agreed-upon version of the app is to be used as the baseline for future modifications. I would also say that there is no such thing as a bug-fix since a bug is defined (I think this is in DevGuide somewhere) as an operation that doesn't function as it's defined to in the spec. No spec, then it's difficult to say what the operation is supposed to do. You get the idea. Of course, if you start writing specs for work you perform, they should indicate what the current functionality is, and what the new functionality is, and then you can call a defect in your new work a 'bug'. Whil _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
