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.
Showing posts with label methodology. Show all posts
Showing posts with label methodology. Show all posts
Monday, October 27, 2008
Sunday, September 14, 2008
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 :
The use of wireframes can be very helpful to do this (another link).
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.
The use of wireframes can be very helpful to do this (another link).
Monday, July 21, 2008
Thoughtfulness about specification phase
In the post series about definitions, I would like to focus today on the specification phase, and in particular on viewing this phase according to different perspectives we used to use. It is not revolutionary while we root them out "old methods" like SART or HOOD.
First of all I would like to consider the V life cycle, which is traditionnaly used as reference for every life cycles, under the concepts of Problem and Solutions domains.
We actually can break down the V life cycle into two main parts, i.e.
The goal of the sofware specification is to provide the development team with a set of elements needed to realize in the best conditions a system which is as close as possible from the customer needs.
There are many means to reach this goal. We can envisage :
It is important to notice that the specification model pursues three goals, ie :
Knowledge and Requirement models are part of the Problem domain and the Operational model mainly constitutes the Solution domain.
Knowledge and Requirement models establishment is the goal of the specification phase.
We'll see in later blog messages a deeper definition of thoses models.
First of all I would like to consider the V life cycle, which is traditionnaly used as reference for every life cycles, under the concepts of Problem and Solutions domains.
We actually can break down the V life cycle into two main parts, i.e.
- Problem domain : it is the modelization from an external point of view of the real system under development, and also the requirements wrt the system to be developped. We find in this area three main types of activities, ie establishing system needs document by the customer, describing by IT guys the software specification from this document, describing then running validation tests, and qualification tests
- Solution domain : it is the internal view of the system under development which regroups the following formal phases : analysis, design, coding, verification testing(unit and integration testing)
The goal of the sofware specification is to provide the development team with a set of elements needed to realize in the best conditions a system which is as close as possible from the customer needs.
There are many means to reach this goal. We can envisage :
- simulation
- modelisation
- mockups and prototypes
- free textual expression of the needs
- formal specifications with methods like the B Method
- ...
It is important to notice that the specification model pursues three goals, ie :
- a cognitive aiming, ie understanding the environment of the system under development. We then speak about establishing the Knowledge model
- a prescriptive aiming, ie undertanding interactions between the environment and the real system under development. We then speak about Requirement model also known as Interaction model
- an operational aiming, ie designing an effective system in order to fulfill customer needs as close as possible; it is known as Operational model.
Knowledge and Requirement models are part of the Problem domain and the Operational model mainly constitutes the Solution domain. Knowledge and Requirement models establishment is the goal of the specification phase.
We'll see in later blog messages a deeper definition of thoses models.
Wednesday, July 16, 2008
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 :
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 :
OpenUp follows the Agile manifest too, i.e. centered on :
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.
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 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"
- 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 processIt 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.
Monday, July 14, 2008
What is a method?
It is always valuable to get back to the basics to stand back and eventually change direction. I'll try in future posts to make returns on some notions, maybe the occasion to discuss about them with readers.
So why not start today with the ground notion of a Method?
To make short, the object of a method is to help engineers to design a system under development by garanteeing :
A method must focus on three main aspects to be considered imo as a usable method :
You'll object me that many companies, many people use methods to develop applications without using all this stuff... Sure, but what I describe here is an ideal toolbox designed to guarantee the quality of the application wrt the customer expectations. It is a kind of roadmap. Once you have this roadmap in mind you can choose in conscience what you want to choose, what you can choose to achieve your goals and the ones of your customers. You don't undergo events, you play with them... and it is in fine a big difference.
So why not start today with the ground notion of a Method?
To make short, the object of a method is to help engineers to design a system under development by garanteeing :
- achievement of customer requirements
- quality
- deadlines and costs
- maintenability
- extensibility
- safety
- security
- documentation
- team work
- information sharing
- and so on...
A method must focus on three main aspects to be considered imo as a usable method :
- choice of formalisms, and artefacts
- diagrams
- elements of modelization
- elements of representation
- definition of a process
- phases and steps
- activities of producing artefacts
- deliveries
- follow up
- instrumentation of this process
- modelisation tools
- control of the models
- development tools
- tests handling
- software configuration management
You'll object me that many companies, many people use methods to develop applications without using all this stuff... Sure, but what I describe here is an ideal toolbox designed to guarantee the quality of the application wrt the customer expectations. It is a kind of roadmap. Once you have this roadmap in mind you can choose in conscience what you want to choose, what you can choose to achieve your goals and the ones of your customers. You don't undergo events, you play with them... and it is in fine a big difference.
Subscribe to:
Posts (Atom)