Approach
Software engineering seems hard compared to other engineering disciplines; building a robust bridge that lasts for centuries seems an altogether simpler task than making a software project successful.
Here is my take on the software development life cycle:
Gathering requirements
Gathering requirements is hard; the written word is essential for nailing down what is required but most people's eyes glaze over when faced with a document that is more than 10 pages long. It is also essential to use language that is jargon free; the user of the system needs to understand what you are saying.
Focusing on the user interface is probably the best way to drill down into an application's complexities and with interactive tools you can keep users interested. If you use a wireframing tool like Denim that generates a clickable html interface, it is something that the user can play around with.
A specialist consultant who has a background in psychology and design and uses a sophisticated wireframing tool, can save a great deal of time and money; a wireframe (picture) is worth a thousand words.
The only question mark with wireframing tools is their relationship with the development process; it is wasteful that wireframe tools do not appear to produce code that can be reused in development.
Specifications and design
Once the user interface requirements are tackled, it is much easier to write a functional specification and define the data model and service layer.
I tend to prefer to define the data model in a lower level, abstract language such as SQL DDL or preferably XSD; an XSD compiler integrates well with the development process. I plan to take a look at UML modelling tools such as AndroMDA to see what the code generated looks like.
WSDL is a good way to define a service layer but I hope that one day there will be a uniform way of defining service layers for a variety of protocols. Enunciate is worth a look.
Given an XSD data model and a WSDL service layer, a short explanatory functional specification that describes the model and the service layer is often enough to complete the specification of a simple application. Where the business logic is complicated, use of a DSL (Domain Specific Language) is often a good choice.
Development
There are various techniques and tools that speed up development enormously.
Choosing a set of software tools that you are comfortable with is a must. In the Java world, the choice is very wide; I prefer open source tools from the major open source projects like Apache Jakarta.
Rapid Prototyping tools and techniques can move a project forward very quickly.
The use of Declarative techniques helps to reduce the size of a code base. The major problem in software development is the sheer volume of code. Declarative techniques enable you to get a overview of an application quickly; they save you having to wade your way through a mountain of code to get the plot of a system.
Testing and iterative development
In the last few years, test driven development has become popular; the eXtreme Programming and Agile methods proponents have introduced lots of useful tools and techniques, though there is the slight implication that nobody tested anything before the year 2000! A lot of the XP and Agile books concentrate too much on the low level tools; I strongly recommend Scott Ambler's book Agile Database Techniques.
There are two really good themes in Agile methods. Designing tests at the beginning of a project as part of the specification phase is a really good idea. An iterative development cycle that involves the users is also eminently sensible; it helps to prevent developing a system that nobody wants.