Software development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
So, why have we never thought to build a good domain model of the software projects at the heart of our software development processes? At IJI we started building such a model some four years ago and this model now forms the heart of our process kernel around which we built the Essential Unified Process. One key motivator was to model the value that different development practices and processes can / do / should provide so that we could enable our customers to evaluate and select between different ways of achieving the same outcomes.

Read More

I first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
Read More

How many people know that approximately 40% of the cost of a truck are software costs or that it takes millions of lines of code to develop a mobile phone? The answer is unfortunately, very few. People do not view these things as software products! Software exists in so many things that we touch on a daily basis, but it is hidden under the shells of pacemakers, cars, etc., and the amount of software included in a “normal” product, grows every second.

Is the fact that it is hidden, the reason why so many software projects fail or run over time and budget? Do decision makers realize how much money could be saved if they just cared a little more?

Well, we care! We know that project deadlines can be met, that project budgets can be kept and that the customer can receive what they expected. You just have to be smart and care a little more. Ivar Jacobson International supports an organization called Swedsoft (www.swedsoft.se) whose primary goal is to care about the software industry, the hidden software industry.

Do you care?

I was celebrating my birthday in Japan with a team I mentored. The manager was present and he asked me politely what my birthday wish was. I said I wanted to slim down without thinking much. It was something I wanted, but had not been succcessful. But through the weeks following that,  by being conscious about calorie intake and output, spreading my food intake, reducing portions, adding some exercises, my weight reduced dramatically. I call it "dramatically" because I never lost that much. Within about a month, I lost 8 kilograms, and then another 6 the next month and another 6 on the third. I had to buy a new pair of pants twice. There were no dieting pills, no starving myself, no gym, but just some self-control, having daily stand-up meetings with my weighing scale and food calorie labels and of course some discipline and commitment with encouragement from weight logs. Read More

We in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team  and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”.  The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as: Read More

We all know that Ivar Jacobson is the father of Use cases and that Use cases are a great vehicle for describing requirements. What many developers also know is that Microsoft’s Visual Studio has been a great management tool to enable team members to continuously collaborate providing comprehensive source control, code checkout and bug tracking tools. But what about developing Use cases in Visual Studio as a requirement – not as something you track such as a bug or defect? Read More

I noticed the other day on my local newscast, that the opening ceremony for this year’s Winter Olympics is only a few weeks away. The newscast showed a sports team working together, training to win one of the most coveted prizes in their career. As per Wikipedia, team sport refers to sports where players interact directly and simultaneously to achieve an objective.  When we put this at an Olympic scale, it combines 10,500 competitors from 204 countries. The stakes are high, preparation and training is intense and the cost of failure has tangible and not-so-tangible results. This newscast made me reflect on IJI’s daily interactions with IT teams and I had to conclude that perhaps the similarities are quite strong. Olympic athletic teams, like IT, which includes the study, design, development, implementation, support /management of computer-based information systems, particularly software applications, is all about working together to achieve one same goal, either win the medal or in the case of IT have the software work seamlessly within an organization. Both teams consist of individual experts working together for a common goal to be the best. The stakes are high in both cases and the costs are equally high with real tangible dollars tied to wins or failures. Read More

Our new ‘corporate’ blog has been launched and I think the timing couldn’t be more serendipitous.  As we come to the end of 2009, it is definitely a year that has caused quite a bit of reflection in the business and IT world. The world economic crisis forced many organizations to focus on the basics and ensure that core business was operating effectively and efficiently. Aligning IT to business became critical as every investment dollar was scrutinized. At IJI, one of the ways the business and technical teams align is by ensuring we’re communicating better as a team focused on a common set of objectives – the new blog is just one result of that strategy. Read More