First, let me say I completely sympathize with your position. It can be frustrating when you have a lack of understanding or a communication breakdown between different parts of the business. Having said that, I don't think you should try to keep them out. Instead you should show them the numbers about why this is a good idea. What facts do you have that justify unit testing is worth the effort you put into it? If you don't have any, then you should start to gather those figures, or show some research to back up your claims.
I have had to deal with similar scenarios myself and I answered this question on a similar topic. I also blogged about how I dealt with it here:
http://practicalagility.com/show-them-the-numbers-its-results-that-matter/
In case you don't feel like link chasing, I'll repeat my summary from the related question:
To summarize, I compared our estimated
hours against actual hours for the
project and then compared our defect
rate against other teams' defect rate.
In our case these numbers compared
favourably and there were no more
concerns.
My conclusion based on this experience is:
...the best way to convince anyone that your approach to doing something
is practical and pragmatic, is to do
it and measure it against other
approaches. People don’t care about
dogma, or why you think something
should be the best way. Only by
showing people the numbers and
measuring the effectiveness of your
approach can you truly show that your
practices are effective.
If your management team don't agree to investing what they see as an additional 150 hours on unit testing, perhaps you can convince them to invest in one small area of the product (or even agree to suck the hours up yourselves to provide some data). Do unit testing in that one area of the product then gather data about the defect rates in that area of the product and the cost to find and fix those defects compared to the defect rates in other areas of the product. Hopefully you'll gather some data to back up your case and this will be a non-issue for your next project.
From what i gathered and understood about The distinction: Most Simply Put
It can be Differentiated by the Nature of Goals
Development Goal
- : Getting It done under pressure and on time.
Production Goals
Keeping it running ( always under pressure)
Needing development on call ( development and bug fix parallelism)
Tackling issues before code goes live.
An Enlightening Chart
from Kanban Applied to Software Development: from Agile to Lean
shows change of Success repeatability,Problem Approach,Process Control,Process Improvement from development to production
Difference based on the Consequences of mistake,Failure
Production : Real-time Immediate loss of hard cash and Potential future opportunities.
** Development:** These cost the company in the long term.
As Péter Török so aptly about production
The latter is where the real, live
company processes are run. So when you
deploy stuff there, it is live, and
any mistake costs hard cash.
Best Answer
The Software Life Cycle is any process model that has specification, development, validation and maintenance phases and these can repeat in cycles so it's sort of the structure of the development processes:
Software project management considers the practical limits, risks and deadlines and forms a complete plan for the entire project and the maintenance of its progress.
see Wikipedia for more details about Development and Management