CASoft Blog     CASoft Blog

         Communication Aspects in Software Engineering

7 March 2010

Waterfall, Iterative or Agile?

Filed under: Project Management — Tags: — admin @ 16:33

With a waterfall approach, one wants to have as close as possible to 100% of the requirements up-front. The challenge in this case is fairly obvious. Getting 100% of requirements documented on a fairly complex system is no easy task and is rarely achieved in practice.

With an iterative approach, I will kick-off the development with 80% of the requirements up-front. Knowing Paretto’s (80%-20%) rule, it makes a lot of sense! The rest of the requirements can be elicited during the development, and a lot of time can be saved this way.

If an Agile approach is to be implemented, I will start the development with less than 20% of the requirements and the scope being defined. In this case, on basically unearth the requirements by putting prototypes in front of the Customer and getting feedback. The prototypes are refined as the development goes, and become an application overtime.

12 September 2009

The under-estimated benefits of components

Filed under: UML — Tags: , , , — admin @ 18:02

Components Based Architecture has been formalised and publicised by UML-RUP more than 10 years ago, and the benefits of this approach are still unknown or under-estimated by most.

It escapes me how, in the 21st century, enterprises can ignore the return on investment (ROI) that can be achieved with components.

The most commonly missing piece in the software engineering puzzle today is the architecture document. I keep seeing projects after projects documenting detailed designs after gathering the requirements and no architecture.

When no components based architecture exists, Managers are reduced to finding and selecting solutions at project level.
With well documented components, encapsulating meaningful functionality, it is for example possible to:

  • Find Commercial-Of-The-Shelf (COSTS) solutions for one or several components.
  • Outsource the development of low added-value components.
  • Reuse components from other applications within the company.

Components are however a science and there is more to it than what meets the eye…
See previous article RUP – Component Based Architecture

1 July 2009

Agile Project Management with Scrum

Filed under: Agile,Book Review — Tags: , — admin @ 21:04

About Scrum we like the philosophy and the following practices:

  • Feature prioritisation sessions
  • Undisturbed iterations (called Sprints)
  • Functionality presentation sessions
  • Self-organising teams

In a nutshell, SCRUM principles are as follows:

  • All management responsibilities are divided between 3 Scrum roles:
    • The Product Owner focus is focused on Return On Investment (ROI)
    • The Team is responsible for developing functionality. Teams are self-managing, self-organising, cross-functional and they are responsible for figuring out how to turn Product Backlog into an increment of functionality.
    • The Scrum Master fills the position normally occupied by the Project Manager. He is responsible for the Scrum process. Like a sheep-dog, he’s responsible for keeping the flock together (focused) and keeping the wolves away (undistracted).
  • Each Sprint is an iteration of 30 consecutive calendar days
    • A Sprint starts with a planning meeting, where the Product Owner presents the highest priority Product Backlog (4 hours) and the Team plans out the Sprint (another 4 hours).
    • A Sprint finishes with a Sprint review meeting (4 hours), where the team present what was developed. Then the Scrum Master holds a Scrum retrospective meeting with the team.
  • Artefacts:
    • A Product Backlog lists the features with estimates, associated Sprint and remaining work (days) – maintained by the Product Owner
    • A Sprint Backlog lists the tasks, which the team defines for turning the Product Backlog they selected into an increment of functionality, associated with the Originator, the person Responsible, the Status and the hours of work remaining – maintained by the Scrum Master -No Gantt-chart
  • Rules:

For more information, get the book form Ken Schwaber – Agile project Management with Scrum – click on the image below:

22 June 2009

TFS for Project Management

Filed under: Agile,Project Management — Tags: , , — admin @ 19:31

Team Foundation Server (TFS) is a Microsoft offering for source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects.
It is not just a bug tracking tool.

It is available either as stand-alone software, or as the server side back end platform for Visual Studio Team System (VSTS).

TFS Architecture:


When creating a project, there are 2 project templates to choose from:

  1. MSF Agile:
    • Provide Work items and Processes that support Agile programming approach
  2. MSF CMMI
    • Based on MSF Agile, it stretches the Agile approach to comply with CMMI Maturity level 3.
    • It is 150% larger than MSF Agile, for example MSF Agile has 25 work product artefacts, MSF CMMI has 59.

TFS manages pretty much everything as Work Items:
The recommended links organisation is as follows:

Queries and reports can be developed in order to retreive any data from TFS. There are existing reports, such as Bugs rate and Remaining work.SharePoint Web Access allows web access to all the information in TFS: Work items, Queires, Reports, Documents, Source Control, Builds and also Timesheets. SharePoint can be used by project Stakeholders, including the Customer if you wish.

SharePoint Project Portal provides documents repositories for projects and Wiki features.

The Integration of TFS and Excel allows to extract any data from TFS into Excel, using queries. The data is copied in the spreadsheet and can be refreshed from TFS at the press of a button. The data can also be edited in Excel and be published in TFS. Charts can then be developed in Excel.

It is also possible to develop pivot-table that access the TFS database directly (instead of running a TFS query).

There are also plug-ins to TFS, such as:

  • Calibre VSTS Add-in, which allows synchronisation of requirements with the tool from Borland
  • Test Director Synchronisation Engine, which allows synchronisation of bugs with the Quality Centre.

Also TFS Power Tools, to be downloaded, offer very interesting features, such as:

  • Process Template Editor
  • Work Item Editor
  • Custom check-in policies
  • TFS Server Manager
  • TFS Client Tool
  • Alert Editor

Finally TFS 2010 will offer the following additional features:

  • Architecture Explorer, which is a graphical visualisation of code
  • 7 diagrams UML supported, for design and share diagrams
  • Tools for test cases management, such as tooling for better documentation & test
  • Test Impact View, which allows to run tests impacted by a code change only
  • Enhanced Vision Control, with gated check-in, branch visualisation & build workflow

5 June 2009

Code Quality – Preventive vs Corrective actions

Filed under: Project Management — Tags: , — admin @ 15:27

When it comes to quality in general and code quality in particular, I very much believe in prevention prior to correction.
When asked about code quality, people tend to offer corrective type solutions. Corrective type solutions are good and necessary, but they are more costly and are worth being minimised by implementing a number of preventive solutions up-stream. Example of preventive actions:

  • Ensure quality of requirements – implement a continous requirements development and recording
  • Ensure quality of architecture and design – implement methodologies for concept and documentation, such as UML and RUP
  • Ensure quality of staff – implement relevant and continuous training programs and recognition programs – manage pressure intelligently
  • Ensure quality of project processes – implement methodologies for project management and software engineering, such as PMBoK, CMMI, RUP and/or a recognised Agile approach.

I have worked for companies which spend a lot of time on the preventive side of things, and other which spend none whatsoever. Experience shows that when time is spent imlementing preventive solutions, the overall time of developing software is no significantly shorter nor longer…
The time normally spent fixing bugs at the end, is instead spent up-front insuring quality. But then dividends pay in the maintenance phase, where things get much easier. One case study demonstrated that 50% less staff were required in the first 5 years of maintaining a software solution re-engineered using proper design and UML approach.
In my point of view, the frequency of total re-engineering needed is also significantly decreased.

As a conclusion, in my experience people implementing Agile approaches often tend to dismiss or minimise the preventive activities in the name of agility, while this is not an Agile requirement and it is undesirable for high quality outcomes.

11 May 2009

RUP – Software Component Architecture

Filed under: RUP,UML — Tags: , , , — admin @ 09:11

What is Architecture?

  • In computer science, Architecture is the nature and structure of a system that determines the way it operates.

What Architecture is not:

  • Architecture is not a Framework: While an architecture can take into account the use of a framework, the definition of a framework is not sufficient! A framework is just one component.

The Technical Architecture (or Model of Architecture) is the nature of the system. For instance, it could be:

  • Monolitic
  • Client Server
  • Distributed
  • N-tier

Paradigms can be integrated, such as:

  • Model-View-Controller
  • Software Components
  • Design patterns

A framework can be defined, as part of the technical architecture.

The business architecture defines the structure of the system.
It should outline the different parts of the system, their role and their relationships, as for instance:

What Does Component Architecture Mean for RUP?

  • Components are cohesive groups of code, in source or executable form, with well-defined interfaces and behaviours that provide strong encapsulation of their contents, and are therefore replaceable.
  • Architectures based around components tend to reduce the effective size and complexity of the solution, and so are more robust and resilient.
  • In the examples below, there is the same number of objects, but a different level of complexity:


Definition for Software Component

  • A Software Component is an independent portion of code that is accessed through a defined interface.
  • Software Components may be just imaginary, and can always be defined whatever the technology used!
  • Software Components may also be physical entities, such as a library (e.g. DLL) or a distributed component (e.g. EJB, CORBA, DCOM, Web Services, etc.)… but not necessarily… and it is not because EJB are used that it is a well-thought Software Component Architecture.
  • Physical Software Components may be reused, purchased and/or replaced.

Business components are those that implement the functionality specific to a business.
A “Computation Engine”, which provides specific computation services, is an example of a business component.
Business components are more difficult to reuse than technical components, due to their specific nature.

Technical components are those that implement generic functionality.
An example of a technical component is “Document Printing”.
Technical components can be designed in order to be reused. They can be part of a technical framework.

Why using Software Components?

  • They usually manage to reduce the complexity of a software, by identifying well defined interfaces and independent portions of code.
  • While it is rather inefficient to give Use Cases to develop to Programmers directly, it is much more effective to give components to implement. ==> Would you envisage to outsource the development of a use case? It is easy to outsource the development of a component, or to buy an existing one.
  • This approach eases and improves workload estimations, planning & task assignment.
  • To reuse components is an efficient way because they are already developed and tested.

Components can be developed in order to be reusable, especially the components that provide common solutions to a wide range of common problems.
These reusable components, which may be larger than just collections of utilities or class libraries, form the basis of reuse within an organization, increasing overall software productivity and quality.
Before promoting furious reusability however, ensure that great experience and knowledge has been acquired in the domain of software components.

Because they are well defined, Components can be refactored with less pain than in a not-so-well structured / organised Architecture.
The interface of the component may be mostly unchanged, while the implementation is entirely reviewed.
Even if the interface is changed, finding the impacted code will be easier than finding what is using the multiple classes and methods that compose the component.

In the beginning of Software Development, documentation and system integration were usually poorly undertook, the Architect was often asked to contribute to the development effort, and the Customer would get to perform most of the testing.

RUP recommends to implement “Use Case Packages” as components for requirements, in order to gather requirements by type of functionality.
Indeed this approach will ease the following analysis and design of the application with software components.

Identifying components may be performed this way:

  • Identify different modules, packages, subsystems and layers, e.g. Billing and Subscription modules.
  • Try to find common features, e.g. printing out.
  • Split modules, define interfaces and relationships with other modules.
  • Iterate and go deeper to find as many components as possible. Use top-down approach, from Graphical Interface towards Data, and bottom-up approach at the same time.
  • Then apply patterns such as Model-View-Controller.

The Components specification will provide a brief description of the components and their relationships.
The result is usually described with Composite Structure or Component Diagrams and accompanying text, providing a high-level description for each component.

The Components Analysis will provide a brief definition of each component, and a detailed definition of its interfaces and relationships.
At this stage, Components are black boxes.
The result is usually obtained and described with Sequence Diagrams and/or Collaboration Diagrams. Class Diagrams can be used to describe the interfaces.

The Components Design will provide the detailed description of what is inside each component / inside the box.
The result is usually obtained and described with Sequence Diagrams, Collaboration Diagrams, Class Diagrams, State Diagrams, etc.

The implementation of the components can now easily be performed by a Developer or a Team.
The team will be responsible for maintaining the design of the component and for unit testing the component.
The team might be the supplier and/or the customer for another component/team.

Components can be individually tested and gradually integrated to form the whole system.When performing unit tests of a component, moke components (giving fake answers) can be used to form the test-bench of the component to test.

Note also that Service Oriented Architectures (SOA) are necessarily based on Software Components Architectures. Components are then implemented as services (Web-services, CORBA, RMI, etc.), which provide the benefit of being loosely coupled.

23 April 2009

Describe Business Processes with UML

Filed under: UML — Tags: , — admin @ 08:32

When describing requirements using UML, any attempt to order use cases or provide sequence information amongst use cases is bad practice, and can only lead to misuse of the UML use case diagrams.

One need to describe the Business Processes for the system under study, as this will provide the order in which things shall happen in much details.
Business Process can be documented in the Overview/Context section of a Product Requirements document.
OMG defines a BPMN notation to describe Business Processes (see http://www.bpmn.org/), which is basically based on a UML 2.0 activity diagram with a number of additional icons / features. This notation however doesn’t add much other than confusion for the non-expert. I am indeed very much in favour of self-explanatory / unambiguous diagrams, as in my experience UML diagrams must be reviewed and approved by subject-matter-experts who usually are not UML experts. So, unless you have a very good reason for using BPMN, just use activity diagrams to describe Business Processes.
BPMN, while based on UML 2.0, is still in need for a consolidation with UML notations.

Otherwise, it is important not to undertake UML without a methodology. In order to be highly successful in documenting a system of any complexity, it is important to follow a formal methodology.
I personally like to use a methodology based on RUP, especially for the documentation of the requirements and the architecture, while agile approach principals can be used for the design and the development…

31 March 2009

Unambiguous and understandable UML

Filed under: UML — Tags: , — admin @ 17:59

The original and fundamental phylosophy of UML is to be unambiguous and understable by most, without requiring an in-depth knowledge of a complex semantique.
This phylosophy had for objective to facilitate the communication in between the different stakeholders of Software Engineering projects and to federate the notations to promote common understanding and shared vision.
It is obvious to me that the original phylosophy is getting diluted progressively amongst the different additions that have been made to the standard over the years.

I do find myself very much in tune with this presentation umlbooch.ppt made by Grady Booch, and which promotes the need to address the increasing complexity of the systems to develop.
My personal vision is to try to keep UML unambiguous and understandable by most, in order to get as many people on board as possible and to address the problematic of the increasing complexity.

Older Posts »

Powered by WordPress and Writeup.com.au