IceScrum

IceTea Tonic is pleased to announce the latest milestone release of IceScrum, a simple portal to manage Scrum projects. Simple and promising even if it still lacks of documentation and if there are some bugs.
Knowledge of the Scrum method is mandatory for using the tool, even if it is quite intuitive.

The use of mockup for specifying graphical applications

Specifying an application is the corner stone of software development success ; well performed, the end-product has a chance to be compliant with the customer needs, if not, the success is unpredictable.
We've seen in a previous post that the specification phase consists in defining the problem domain, and especially a knowledge model in interaction with the system under study. So we have to focus on formalizing the definitions, the domain rules and the functionnalities the customer need.
Many technics may be used to perform theses tasks, and especially use case diagrams, sequence diagrams, user stories, and so on...
Once we begin to have a good understanding of the problem, we have to ensure that this understanding is in conformance with the customer one. This has to be done before starting any development of course.
The use of a mockup is then highly recommended, especially when designing a graphical application, but obviously not only.
There are many ways to do this :

• word documents or diagrams on paper : it is the old way. It is very uneffective, especially when there are many stakeholders in the decision process
• diagramming tools like visio, smartdraw, ... : it is better than nothing, but we have to face to a static way of presenting the mockup... The dynamic aspect is bypassed... and yet, ergonomics is also a matter of dynamics
• graphics tools like photoshop, paintshoppro, .. : the result is smarter than with the former tools, but the result is the same. We may also introduce confusion while mixing application design, and presentation design, which are two different things in my opinion. We also need some specialists to perform this task.
  
• development tools like dreamweaver, eclipse, visual studio : in that case we can have dynamics and then have relevant advices from the customers. The counterpart is a development time which is not compliant with the iterative and quick process of specification. By experience, it is a very consuming task. The use of GWT or similar frameworks may nevertheless be taken into account to reduce the drawback. But the collaborative aspect of the specification is absent.
  
• wikis like google sites or editme : it is an alternative way of performing the mockup ; it is quite easy to use, it is a collaborative (a major point, we may for instance leave comments on each page), quick to develop. But up to know, we still lack of ready to use components/wireframes to simplify the development. Another alternative is to use powerpoint to do this, but it is less collaborative.
• specialized tools like Axure ones : the goal of this kind of tools is to help the specifier to quickyl develop mockup by combining the advantages of all the former solutions described here. Of course it is not gratis, but I think this approach is the right one.

As said previously, I thing we have to dissociate the functional mockup to the graphical design.
The use of wireframes can be very helpful to do this (another link).

Assembla, a rapid collaborative developpement environnement

I've already spoken about RallyDev, Jazz , Atlassian softs (concluence, jira, bamboo, ...) for the commercial collaborative development environments (CDE), or Trac and consors for the open sources ones.
I would like today introduce a new comer, i.e. Assembla. It is another CDE which aims to fulfill roughly the same requirements than the Rallydev application. With Assembla you will be able to develop several products and projects in an agile manner, eg Scrum. You'll be able to trace issues liek bugs, enhancement requests, patches, requirements, but also to formalize development milestones, and so on...
The tool is in a SaaS mode and is quite affordable. It is also designed to be connected with different tools like Trac, Bugzilla, Mercurial, Subversion, ... You have the choice.

OpenUp, an agile method

Agility has been trendy since some years, but it is not just fashionable ; it is a right way to ensure that software development will produce a high quality software in time and matching the customer needs.
It exists well-known agile methods like XP, Scrum, DSDM, and so on... We won't discuss today about them, but in particular of the OpenUp method which has been developped since 2 years under the umbrella of the Eclipse Consortium, right next to the EclipseWay method, the agile method directly derived from the Eclipse development scheme.
OpenUp states for Open Unified Process, and is based upon an iterative and incremental approach.
In my point of view, this method could match quite well the Change function assertion, which stipulates that the success can be formalized by the following function :

Change Function = F(Perceived Crisis/Perceived Pain of Adoption)

For the Perceived crisis aspect, we all actually know projects which don't end, are abandonned, or don't achieve goals the customer wanted to reach. Industrialization of the sofware process is quite far behind today industrialization in automotive, aerospace or even games domains. Agility is a pragmatic way to industrialize at low cost and in effective manner software engineering.
For the Perceived Pain of Adoption aspect, I find that OpenUp is a good mix between more traditionnal concepts/vocabulary and agiles ones. For someone who understood the agility paradigm and is used to use traditionnal methododologies like for instance RUP, transition will be softer.

OpenUp rests upon three angular stones :

• requirement management through the use of use cases and scenarii
• hazard/risk management
• an approach clearly centered on architecture very early in the life cycle

OpenUp can be used for small projects, but it is best suitable for larger size projects IMO.
OpenUp follows the Agile manifest too, i.e. centered on :

• the team : "people and interactions rather than process and tools"
  
• the application : "Functionnal sofware rather than complete documentation"
• the collaboration : "Collaboration with the customer rather than contract negocaition"
• accepting changes : "React to changes rather than follows a predefined planning"

Moreover, OpenUp proposes the following project life cycle in 4 phases:

• Starting the project (Inception) :the goal is to get agreement of the actors of the project on what we have to do and how
• Elaboration : the goal is to discriminate the technical risks from the non technical ones
• Construction : the goal is to develop at the best cost a full product which can be deployed in an operational manner
• Transition : the goal is to ensure that the software is ready to be delivered to the end-user customers

OpenUp overal process

Inside each phase you have an iteration phase lifecycle, and inside this iteration phase micro-increments (typically daily).
It is not the topic of this post to describe in details the OpenUp method, so I enjoin you to visit the OpenUp web site here for further information.

Team Concert on the Jazz Technology Platform

Rational Team Concert 1.0 was just out on jazz.net one month ago. It is the first collaborative development tool based uppon the Jazz technology platform initiated by IBM to improve collaborative agile development. An edition named Express-C is available for free.

The platform is a mix of tools as Eclipse plugins and web 2.0 pages, and offers all the basic features - as described by IBM- to:

• Support seamless integration of tasks across the software lifecycle.
• Facilitate team collaboration and coordination throughout the software lifecycle.
• Provide an extensible platform.
• Help teams build software more effectively.
• Support globally distributed development teams.
• Provide solutions scalable from small teams up through large enterprises.
• Maintain audit trails and automate bookkeeping so that teams are accountable.
• Support UI integrations (IDE, web browser, etc.) that fit the needs of customers.
• Foster a broad ecosystem of tool providers, including independent software vendors (ISVs).
• Make software development more enjoyable.

The Jazz Platform's principal role is to provide tool writers with mechanisms to use, and rules to follow, that lead to seamlessly-integrated lifecycle tools. These mechanisms are exposed via well-defined APIs. The Jazz Platform also provides useful building blocks and frameworks that facilitate developing new tools.

A diagram is often the best means to quickly understand an architecture :

Jazz is itself developped in an agile way by using the EclipseWay development scheme (which is expressed itself by the ECPF tool). It is called Open Commercial Software Development.

I tested Jazz as early adopter one year ago, and I thought then it was a very promising platform built uppon a solid conceptual model and prooved tools. I've not yet tested the first occurence of Team Concert, but I'll do it quite soon. My opinion is that the platform aims relative big projects with many developpers working together in a collaborative way, i.e. under a customizable agile approach. The result is a relative consequent tool which needs to be administered and planned in the company organization as we have to administer SCM tools in big organizations. It is obviously not a drawback, but you have to take this data into account.