<p>What strategies have you used with Model Based Testing?</p>

<ul>
<li>Do you use it exclusively for
integration testing, or branch it
out to other areas
(unit/functional/system/spec verification)? </li>
<li>Do you build focused "sealed" models  or do you evolve complex onibus models over time?</li>
<li>When in the product cycle do you invest in creating MBTs?</li>
<li>What sort of base test libraries do you exclusively create for  MBTs?</li>
<li><p>What difference do you make in your functional base test libraries to better support MBTs?
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­</p></li>
</ul>

We haven't done any/much I&T and use unit testing almost exclusively, seasoned with a bit of system testing. But our focus is clearly on unit testing. I'm pretty strict on the APIs we build/provide, so the assumption is, if it works by itself, it will work in conjunction and there hasn't been much wrong in it yet.
Our models are focused on a single purpose/module with as little dependencies as possible.
The focus is always to start as early as possible (TDD-kinda), but unfortunately we don't always get to it. The problem is, you always have to sell it to management and then it's hard because while testing improves stability (overall QA), the people from the outside (outside of tech) can't really relate to what that means until something bad happened.
Since we use PHP, we employ PHPUnit for the unit tests. All in all, we do CI with various different tools. :)