Migrating your project to Maven 2 – Part I
Posted by Lars Vonk late at night: February 26th, 2006
Hibernate Collection-Mapping Collection
Posted by Maarten Winkels just before lunchtime: February 20th, 2006
Non-invasive Audit logging
Posted by Jeroen van Erp just before lunchtime: February 16th, 2006
Non-invasive Audit logging
Which developer hasn't worked on a project where, at some point in time before the final delivery, some guy from maintenance wakes up and asks the development team whether they can perform audit logging... Specifically he wants to have a "detailed log". It should contain the IPAddress of the user, his login name, and some information about which actions he performed and what the results were...
(more...)
Align your software practice with your business
Posted by Michael Franken around lunchtime: February 9th, 2006
The Software Development Process (SDP in short) defines the way business ideas are put into software practice. It covers the entire process from requirements definition through to using the software in production. Many projects simply fail because of the fact that the business and software development processes are not aligned. It is a known fact [Standish98] that the most important factors that make or break a software development project are:
1. User Involvement,
2. Executive Support and
3. Clear Business Objectives.
These factors are more important than an experienced Project Manager. This is clearly evidence that stakeholders outside the IT department should be represented in the Software Development Process. To emphasize this even more, research has shown that 45% of all features implemented are never used at all. Therefore we can’t stress the simple point enough:
The software development process should resemble the business process.
Often this is not the case and the SDP has remained a mere IT asset or, even worse, a pure development instrument that has originated from team or developer preference, theory or vendor promotion. This can seriously hurt business as projects are more likely to fail with an inadequate process, and if they succeed they may be twice as expensive as needed.
Model your attributed sets as maps!
Posted by Maarten Winkels in the early afternoon: February 6th, 2006
At my current project we have a very detailed analysis model. Actually, detailed doesn't begin to describe it. the model describes over 200 classes. One of the many problems with such an extended analysis model is that there is no room for the developers to interpret the business model and figure out the technical design that fits it best. Implementing the classes that the analysis model describes with their properties and associations is complicated enough, and then the operations and services that are based on these classes will still need to be designed and implemented. This leads to developers simply typing out the classes as the Analysis model describes them.
One striking example is where a many to many association acquires attributes. Let's look at an example.
Archives
Xebia Sites
Categories
- Java (235)
- Agile (101)
- General (50)
- Performance (37)
- Hibernate (35)
- Podcast (31)
- Testing (30)
- Scrum (28)
- Spring (24)
- Project Management (22)
- Architecture (22)
- SOA (19)
- Flex (17)
- Maven (15)
- Eclipse (14)
- JPA (13)
- Quality Assurance (12)
- Groovy (12)
- Articles (11)
- Grails (11)