Ivarblog

The Kernel Journals 7: SatNav for Software Development Projects

In the last Kernel Journal we looked at the problem that Barry Boehm was aiming to solve back in 1995 when he first proposed his three standard process milestones (which later gained industry prominence as the milestones in the Unified Software Development Process and the Rational Unified Process), namely that “the proliferation of software process models provides flexibility”, but leaves us “with no common anchor points around which to plan and control.” [Barry Boehm, November 1995]. We looked at how a small set of domain entities with simple state progression models (which we call “Alphas”) can make these common anchor points much more practical and useful while ensuring that they remain process-neutral and do not become “document-driven”.

The alphas, when used with common milestones such as the Unified Process Milestones, can actually give us much more than this – they can provide a project status and health dashboard that can be used by the customer and supplier organizations to assess the current status and health of any / all projects, irrespective of which processes or practices they are following. The graphic below shows just such a dashboard, with a set of kernel alphas and a traffic-light status for each alpha, which is derived by comparing where the project is now (the state machine to the left of each traffic light) with where it needs to be to achieve the next project milestone (the state machine to the right of each traffic light).The Kernel Journals 7: SatNav for Software Development Projects

In Kernel Journal 5: “Making the Invisible Visible” I described how we can easily “skin” a process kernel, by providing a portal for projects to capture, share and agree the essential project information that is needed to achieve each state progression (for example, using a set of templated Wiki pages). Once we have done this, we can make the alpha dashboard much more useful to the project teams themselves, by flagging which sections of the project portal need to be updated and agreed to get the project to where it needs to go next.

This gives us the equivalent of a Satellite Navigation System for our software projects project that enables us to:

  • Set our journey destination and waypoints (milestones)
  • Track where we are now, compared to where we want to be
  • Get guidance on what to do next in order to progress towards our destination.


 

What Drives Me by Ivar Jacobson

What Drives Me

“The best way to predict the future is to invent it!“ (Alan Kay)

A few days ago, a very simple but thought provoking question was raised to me: “what it is that drives me?” The simple truth is that I do not know. But I do know what it is that does not drive me. It is not about money. Actually, never has it been about money. Neither is it about power. I am happy to step aside and I am happy to delegate both up and down. It is not about popularity – but I do like to be appreciated for what I do.

No, it has to do with helping others improve themselves over and over again. I get a kick out of seeing others become successful because I helped them. It was like that in the late 1960s and the ‘70s when the Ericsson AXE system beat all competition and won every contract thanks to being component-based. Similarly, when Rational was successful because of UML and Objectory. And Telelogic because of SDL. I am happy when people are successful thanks to use cases.

Read More

What is an Iteration?

What is an Iteration?

Iteration: A self-contained mini-project, with a well-defined outcome: a stable, integrated, and tested “release”. Let’s look at the three aspects of this definition in more detail.

A software development project produces a new release of a software product by transforming a set of users’ requirements into a new or changed software product. With an iterative and incremental approach, this process is completed little by little, step by step, by splitting the overall project into several mini-projects, each of which is called an iteration.

From the perspective of the development team, each iteration can be considered to be a self-contained
project. This approach is very powerful because it enables the development team members to focus on meeting their immediate objectives and ensures that the results generated are frequently and objectively measured. The management team needs to ensure that the iteration objectives form
a credible part of the larger overall project.

The management team needs to reinforce this way of working by ensuring that each iteration has the following:

Read More

How to stop thinking about business as “the customer” and IT as “the vendor” by Ivar Jacobson

How to stop thinking about business as “the customer” and IT as “the vendor”In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.

It will not be an easy journey, but here are some steps along the way:

Read More

SEMAT (Software Engineering Method and Theory): A Call for Action by Ivar Jacobson

We are some people who have observed software engineering theory and practice of the past decades and have realized that it is now time to revitalize this discipline. We have been quietly planning a “revolution”.

For those who have been following my columns may know that, for a very long time, I have been talking about that we need a theory of software engineering. See my two blog entries, “A problem to fix: We don’t understand the nature of software engineering” February 2009, and “Someday we must become professionals!” March 2009, which describe my thoughts on this issue when it all started over a year ago. Read More

Closing the Gap between Business and IT by Ivar Jacobson

From almost the dawn of the age of software more than 50 years ago, there has been a communication gap between business and IT. For almost as long we have sought solutions, but they always seem to elude us.  Meanwhile, the gap has grown into a chasm that now needs a fairly substantial bridge.

From the business you may hear that ”we have no confidence in IT’s ability to deliver useful solutions”, or “we have limited visibility of progress, risks and problems”, and “we don’t know how we should measure the value of our investments in IT.” Read More

There are practices and then there are Practices by Ivar Jacobson

The software development community has been talking about practices in an informal way for a very long time - more than 50 years. In the way the community talks, a “practice” is just something that people do, a habit they have that may be good, or perhaps not good. Talking about practices in this way makes for good conversation, but it is hard to figure out how to combine good practices into something meaningful.

I like to talk about practices in a more precise way, so I will refer to these as Practices (with a capital ‘P’). With a more precise definition we can do some interesting things: we can combine them (or compose them) in interesting ways, and we can separate them to allow us to replace a practice with a better one. Read More

A Day of Honor by Ivar Jacobson

Lima, Perú, October 21, 2009

This time I have something to tell you about my visit to Peru. I had been nominated to receive an honorary Doctorate degree from the University of San Martin de Porres (USMP) in Lima Perú. USMP is one of the most prestigious universities in South America. Thus, when I got the offer from USMP and saw people who previously had been awarded honorary degrees, I felt I was in great company. James Martin (the father of case tools and much more) and Nick Negroponte (the founder of MIT’s Media Lab and the “One Laptop per Child” Initiative) received the honorary degrees in 1997 and 2007 respectively. Read More

Taking the temperature of UML by Ivar Jacobson

More than twelve years have passed since UML, the Unified Modeling Language, became a standard. During these years the perception of UML has ranged from the heights of the heavens to the depths of the earth.

At the beginning of the 1990s there were 26 published methods on object-orientation, most methods with its own notation. It was to address at least the notation problem that UML was conceived. As most of you probably know, Grady Booch, Jim Rumbaugh and I initiated the design of what became UML, but very quickly many other great people joined the effort and OMG undertook to launch the result. UML quickly made most other notations superfluous. Along with the notations many methods also fell by the wayside, leaving the Unified Process, which had embraced UML, as a de-facto standard along with UML. UML’s adoption spread like wildfire. Read More

In need of a theory for software engineering by Ivar Jacobson

To an external observer it would appear that the consensus about the way software should be developed changes dramatically every second or third year, more frequently than the whims of fashion. Trends seem to come and go with no rhyme or reason, and it seems that the label you adopt is more important than the results that you get or the things that you actually do.

Are we working in engineering or in a fashion industry?

Have you ever taken the time to investigate a new method or practice only to find that it is just the re-branding and re-gurgitation of ideas that you have seen many times before? Read More

Page 2 of 812345678