I haven’t come across any recommended method of deploying a theme with a SharePoint solution, but here’s a suggestion that should work: Simply deploy all the theme files to their relevant location in 12\TEMPLATE\THEMES using the TemplateFiles element (ok, maybe this is the recommended way .
You’ll also need to deploy an updated copy of 12\TEMPLATE\LAYOUTS\1033\SPTHEMES.XML. I’m not sure if this would be supported as you’re overwriting a core SharePoint file in your deployment, but it’ll do the trick. You would have to modify this file manually anyway I suppose (although there’s the risk that your deployment could overwrite previous themes added manually in this file by someone else).
As far as I know, there’s also no out-the-box method of applying the theme automatically to a site. You could write a feature event receiver to do this though via the SharePoint API.
I stumbled upon this brilliantly simple yet informative post titled ‘The Future of Software Development’. It gives a brief background of the waterfall model and why it failed, an overview of the best methods for building software today, and what changes we can likely expect in the future.
Here’s an extract:
“We have come a long way since then and learned a lot about making software. The Waterfall Model is now considered a flawed method because it is so rigid and unrealistic. In the real world, software projects have ill-defined and constantly evolving requirements, making it impossible to think everything through at once. Instead, the best software today is created and evolved using agile methods. These techniques allow engineers to continuously re-align software with business and customer needs.“
Read the full article…
“So what does the business expect from its development teams? Deliver the agreed business requirements, on time and within budget, and of course to an acceptable quality. All software development professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. Something must be variable in order for the project to succeed. In Agile Development, it is always the scope (or features of the product) that are variable, not the cost and timescale.
Although the scope of an Agile Development project is variable, it is acknowledged that only a fraction of any product is really used by its users and therefore that not all features of a product are really essential. For this philosophy to work, it’s imperative to start development (dependencies permitting) with the core, highest priority features, making sure they are delivered in the earliest iterations.“