How to choose a UML modeling tool?

Choosing an UML tool is a complex and time consuming task. The decision on the tool to be selected should be based on an in-depth analysis of the present and future use of the tool. The following list presents the criteria that are commonly used when evaluating an UML tool.
1. collaborative use of the tool
Real-life projects usually require several engineers working together on the same UML mode, so the tool must have support for collaborative work. The support for collaboration can be achieved in several ways, most common being the following two: repository support
UML models are stored in a repository that provides model sharing and concurrent model development.
- integration with configuration management tools that support collaborative work
The support for sharing and concurrency is deferred to a configuration management tool. This alternative is preferred because the model is stored “close” to the code and other related artefacts (test cases, documents, etc). Additionally, the overhead required to manage the UML models repository is eliminated.
The support for collaborative use of the UML tool requires support for versioning model elements, for comparing different versions of a model element and for merging concurrent versions of the same model element.
2. integration with configuration management tools
Best practices for software development require the development artefacts (documents, code, tests, models, etc) to be stored using a configuration management (CM) tool. The level of integration may range from exporting the model in XMI format and storing the XMI under configuration management control to advanced integration that allows direct connection between UML and CM tools (usually based on plugins), including check in/check out of model elements, model synchronization between workarea and CM tool database, model elements versioning, etc.
This criterion should be analysed in conjunction with collaborative use support criterion.
3. round-trip engineering

Round-trip engineering is the ability to generate code from UML model (forward engineering) and to generate the UML model from the code (reverse engineering). There are multiple levels of support for round-trip engineering, ranging from generating method stubs from class diagrams or updating the method description in the model when the method signature is changed in code, to full automatic synchronization between model and code.

Most of the UML tools offer an intermediate level of support for round-trip engineering, some tools offering one way engineering only. Full automatic synchronization between model and code is provided by highly specialized tools only; the model and the code have to adhere to restrictive rules to allow this type of synchronization.

4. generation of documentation from model

Many engineers working with an UML model require only read-only access. The UML tool should provide the capabilities for generating easily accessible static views of the model (usually HTML and PDF formats are used for generating the static view). These static views should be as close as possible to the tool view of the model from the point of view of navigation, display and informational content.

An UML model contains a significant amount of information that usually has to be presented in other documents like requirements documents, design documents, etc. Some of the modeling tools have the capability to generate documents with customisable format and content. This feature is valuable when the model contains enough information so an almost complete document can be generated.

5. UML standard support

UML standard is vast and complex and although most of the tools claim full support for an UML release, probably no tool really does it. Real life shows that full support for UML standard is not required. Therefore, when conducting an evaluation for an UML tool, the evaluation team should decide on a subset of UML standard that is required to be supported and the evaluation should be conducted for this subset.

6. diagramming features

Ultimately, an UML tool is used for drawing diagrams and the ease of creating diagrams is of top importance when evaluating the tool. Features like auto-completion, quick-pick lists, tool-tips, copy-paste for model

elements, etc should be considered for assessing the diagramming capabilities.

The criteria described above should be considered in the context of the forecasted use of the UML tool. One criterion of the above ones may not apply, other may apply partially, others may be weighted differently. This list describe only the most common criteria, but other relevant criteria for selecting the UML tool (e.g. data modelling, multi-platform support, model analysis features, etc) should be considered too.

How to define a software development life cycle?

Defining a software development lifecycle (SDLC) is a complex task, but it can be done by following several simple steps:
1. clearly define the scope and purpose of the SDLC
The scope and purpose should be documented and presented to the management of the organization and to the people that will be affected by the SDLC. Getting a wide acceptance for the initiative is probably the most important factor for success.
2. establish a strategy for SDLC definition using one of the following commonly used ones:
- SDLC improvement
- SDLC reengineering
- new SDLC adoption
The strategy should be chosen based on the desired magnitude of the change (SDLC improvement has the lowest change magnitude, new SDLC adoption has the highest magnitude), on the people available to drive the initiative, on the time constraints, on the acceptable risks for the SDLC definition project, etc.
3. define and document the SDLC
Whenever possible use graphical notations to document the processes that make up the SDLC.
4. validate the SDLC for several pilot projects
It’s a good time to see what is working, what have to be fixed or enhanced and to get the success storied to be later used for marketing the new SDLC.
5. release the SDLC
All the people that will be affected by the new SDLC will have to attend extensive trainings to get both a general understanding and a job specific understanding of the SDLC.
6. continuously improve the process
SDLC definition is a never-ending task so it should be continuously improved an d adapted.

Throughout the SDLC definition project, communication plays a vital role for the overall success of the initiative. All the people that will be affected by the new SDLC should be kept in-loop with details on the progress and on the new SDLC. They should be constantly asked for feedback.
Whenever possible, reuse! A lot of things have been discovered and documented about software development processes so instead of re-investing the wheel check if it’s not already available. ISO standards like ISO12207 and ISO15288, standard process models like Waterfall Model, V-Model, Agile Models, etc process improvement approaches like CMMI, etc, should be consulted while defining the process.

Please check some SDLC secrets in SDLC 100 Success Secrets - Software Development Life Cycle (SDLC) 100 Most asked Questions, SDLC Methodologies, Tools, Process and Business Models.

The "unknown" and effort estimation for a software projects

The definition for effort estimation that I like the most is the following one from Wikipedia:
"....effort estimation is the process of predicting the most realistic use of effort required to develop or maintain software based on incomplete, uncertain and/or noisy input"
Starting from this definition, it's obvious that any estimation is based on "unknown" - sometime it's a big "unknown", sometime it's a small one, but it's always present (if it's not present it's not an estimation). Mathematically speaking, the reliability of the estimation is inversely proportional with the size of the "unknown", so to determine the reliability of the estimation you have to quantify the "unknown".  
Like the devil, the "unknown" has many faces - it may be a missing or incomplete requirement, a new technology,  a set of open points and assertions that have to clarified/confirmed, a changing project team, etc.
One thing to remember is that the output of the estimation process must be represented by a prediction for the effort accompanied by a list of factors (the "unknown") that influence the predicted effort and a reliability indicator of the estimated effort.

Effort estimation for software development - the agile way

Estimating how long it will take to develop a software product is hard task. There are several approaches to be considered for effort estimation:
1. expert estimation: the figures are produced through a judgement process by experienced people
2. formal estimation methods: the figures are computed in an algorithmic way, usually based on historical data and on the parameters of the project to be estimated
3. a combination of the previous methods: some activities and tasks are estimated by experts, other using formal methods.
Historically speaking there are no studies that prove beyond doubt that one approach is better than the other or a method that is superior to others. Ideally each organization should choose the estimation method(s)that best fit the types of projects to be estimated.
I personally prefer expert estimation methods because are lightweight and additionally I tend to give credit to a person instead of an algorithm. On the other hand I don’t like "wild guessing", even if an expert is guessing. Considering this, my favourite estimation way of estimating is the following agile method:
1. decompose the project into phases, activities, tasks (i.e. work break down structure)
2. classify each task by complexity (e.g simple, medium, complex) and size (e.g. small, medium, large)
Note: there may be more complexity and size levels, but usually 5 is the upper limit.
3. define for each complexity-size category the estimated time for completion ( this should not be "wild guessing", but an estimation based on experience :) )
4. aggregate the estimations for tasks in a bottom-up manner to get the project estimation.
One thing to remember is to revisit and refine the estimates as the project progresses, assumptions are clarified, open points are closed and more information is available.

What is sofware development?

Software development (SWD for short) is the technical and artistic act of creating software. Althouhg many people think of SWD as beeing the same with computer programming, it is a more complex human activity that ususally includes research, development, training, maintenance, re-engineering, overall management, etc. SWD is ususally conducted based on a development methodology that best fits the purpose of developing the software product . The development methodology defines proceses and methods that, when followed, ensure the successful completion of software product creation.

It's alive ... my blog!!!

Today I've started my blogger life, few clicks and I'm free to share my thoughts with the citizens of the blogosphere. Mathematically speaking, the set of citizens interested about my thought is probably an empty set today :), but, who knows, probably the situation will change over time!


PS: I hope my blog will not die young