Ruxandra ChelaruProgram Manager| Luxoft Professional RomaniaBucharest, Sector 3, Romania
Hello,
I'm looking forward to discuss and share thoughts and ideas about acceptance criterias in fix price contracts in the area of software development.
I'm thinking at two specific scenarios (with waterfall in mind):
1) project scope is software development alone (no testing involved)
2) project scope is software testing alone
For 1) in my view, as acceptance criteria one should have at least:
- traceability requirements - architecture - code
- proofs for code review
- no new errors / warnings when compiling
- unit testing (certain percentage of coverage)
For 2), at least
- traceability requirements - test cases
- proofs for code review
Did your fix price contracts include warranty clauses ?
Thank you !
Ruxandra Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Whatever established practices are in place should be utilized. The contract is on delivering the product by a certain date for a specified price.
Best practice software development should already include coding standards, code reviews, unit-tests, etc., and not be to a specific project or customer.
Additionally, testing best practices should be established at an organization level and utilized in all projects.
Is it in the contract to provide proof for code review? What exactly does that mean? What would that look like? I had not heard that before. Saving Changes...
Ruxandra ChelaruProgram Manager| Luxoft Professional RomaniaBucharest, Sector 3, Romania
Hi Andrew,
Thank you for your feedback.
Yes, of course, the established practices are to be utilized, yet acceptance criteria may depend on the project / customer.
I was just curious of such acceptance criteria in your projects.
By proofs of code review I mean the code review coverage and if needed the code review records.
Thanks ! Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Ruxandra, is not about the approach you use. What some people forget, mainly because the name is "acceptance criteria" , are the components of it: the criteria itself and the process to follow to achieve the criteria. Buth must be agreed with the client and that is one place where mostly forgotten requirements have a great impact: non-functional requirements. About the time of contracts, after more than 30 years to work in the field is hard for me to remember when I do work with non-fixed price contracts. Saving Changes...
The one thing to watch for with fixed price software development contracts is that you might lose out on benefiting from the creativity or innovative capabilities of your vendor partner if you make the T's & C's too restrictive.
I'm not saying fixed price contracts are bad, but when doing knowledge-based work like software development you want to add some incentives or measures around the excellence of the solution itself rather than just the bare bones of meeting requirements within quality objectives.
Kiron Saving Changes...
Adam YusufOther| Knowledgebased Services LimitedAbuja, Federal Capital Territory, Nigeria
All well said. What I have discovered in my over 20 years in software development is gradual expansion of scope mid-way as some need were realized by the cstomer until a component is ready and they say just add this. To review cost at that time when it is a fixed price is always difficult.
My approach is define clearly the scope and detail component to be delivered and sign-off at the begining. Any new addition should be noted as additional work (which you may charge for or not) at your discretion. Only spell out deliverables as acceptance criteria else you can be hooked in an endless loop as most client do not have the expertise to review your steps or code Saving Changes...
