Know more and connect with me on [Linkedin Profile].

Monday, November 26, 2007

Software Reuse, an Integrated Approach

>>This article is published at SEPG Egypt at

Software reuse is a comprehensive issue; without taking into account all perspectives, it could fail. Here we are trying to look at different angles and highlight several issues.

Business View:

First, senior management should take reusability into consideration. Loading technical team alone with the reusability efforts will not normally succeed. It should start from top management. As opposed to seeing the business as developing a certain product for some customer, senior management should look at the business as developing an application family to satisfy different client’s needs. The business focus here will affect all efforts after it. As example, HP shifted their thinking from developing a new printer driver for each new printer to developing a reusable family of drivers. The result was a huge saving in cost and improved quality.


After focusing on a new business perspective regarding what is really required, reusing is shifted to create requirements with focus on reusability. Requirements even could be restated to match certain reusable components features. Requirements analysis phase will follow by creating use cases focused on variability points. The following example will explain the concept of determining variability points:

Vacation Request:

1. Employee requests vacation from his direct manager

2. Direct Manager retrieves balance from Human Resources

If there is no balance

3. The vacation request is rejected

If vacation is more than 3 days, Direct Manager forward to Senior Manager

4. Senior Manager approves or rejects the vacation request

If vacation is more than 3 days

5. SM needs to receive email notification

6. Direct manager approves or rejects the vacation

In some companies they don’t escalate to senior manager the vacation for whatever reason. The Direct manager always has permission to approve or reject the vacation request. We will mark variability with curly brackets {}.

1. Employee requests vacation from his direct manager

2. Direct Manager retrieves balance from Human Resources

If there is no balance

3. The vacation request is rejected

If {StrictSMFollowUp}

If vacation is more than [ApproveLimit] days,

4. Direct Manager forwards to Senior Manager

5. Senior Manager approves or rejects the vacation request

If vacation is more than {NotificationLimit} days

6. SM needs to receive email notification

7. Direct manager approves or reject the vacation

The StrictSMFollowUp is variable; it could be true or false based on the way the organization work. In our example, we classified the businesses that will use our application, some have strict SM follow-up, and others have not.

ApproveLimit states the max number of days Direct Manager allowed to approve without consulting Senior Manager. NotificationLimit states the max count of days that need no notification.

The above is just an example to identify variability points in the requirements. We can use many ways to mark variability in the requirements that makes sense for our own applications.

Variability Implementation:

  • Inheritance: As an example, in a typical application we wanted to support different database servers. You can select the basic reference dbase and create classes to implement it. Each other new dbase could inherit from the base classes and override essential operations. As the basic SQL construct are the same between databases, you should centralize the variability in specific classes.
  • Parameter: You can have pages or screens with customization parameters. Administrators have the permission to customize the system. As example, the timeout of waiting the response from the external bank server.
  • Configuration: In many cases you can use extensive configuration files to adapt the behavior of the system. In some systems you can even specify a complete alternate component through the configuration file. As example, specifying another XML parser. In this case, your application should use standard XML parser interface and the new parser should implement the same interface.

Architecture and Design:

Building the architecture and design in a way that makes configurability and reusability easier is an important issue. Layered architecture and components based design make it easier for you to achieve better designs.

Focusing on using known architecture and design patterns will make it easier for you to build state of the art architecture and design. Explaining patterns is outside the scope of this article, but some references will be listed in the references section.

Reusable Asset Library:

Having a reusable assets library with processes that define how to reuse a certain component, how to add new component and how to update existing component is important of reuse success.

A traceability table that traces each component version with which products are using it is required to guide in updating the applications with new components updates if necessary.

Asset library should be organized so that each one item should has:

  • Version number. A unique version number to the library item.
  • Status: is it ready for reuse or still in beta state.
  • Bin reusable component (if exist) such as DLL files or OCX files.
  • Documentation: A simple document that specify how to use. A sample code will help component users to use it effectively.
  • Release notes: This can specify what bugs are solved, new features, or knows issues compared to the earlier version of the same component.
  • Source code: if applicable.

Process Support:

We will describe basic processes to help managing the reusable asset library. We will not state the details of each one.

  1. Add new reusable code item: The steps needed and standards that should be satisfied in the new reusable code item.
  2. Delete reusable code item: Remove a typical item as it is no longer used nor supported.
  3. Update reusable code item: A new revision is created and needs to be available in the repository.
  4. Use typical reusable code item: reusing should be organized to know the full dependencies between reusable code items and applications that use it.
  5. Requirements development process should have activities for requirements development to guide in stating techniques and methods to state the variability points.
  6. Architecture and design process should be stating using typical techniques to help focusing on reusability.
  7. Testing processes should take into account testing variability points comprehensively.

Before adding a new version to the library, an extensive test and peer review is done to make sure the component is meeting quality requirements.

A common challenge is what to do with a large set of reusable code, should we create a project to organize them and add them to the new empty asset library? Or just focus on the new reusable components?

Without first closing the sink that continuously diminishes reusable code, we will always have the case of old code that need cleaning to be added to the reusable code repository. So first establish a system to close all waste holes and in parallel clean up and restructure old code.


Whatever your company size and experience are, you can not simply order reuse or install it at once and expect it to happen. Rather, you should encourage reuse by following many steps as described in this article. Although reusability conceptually is a simple idea, many efforts should be done to realize its benefits. This article was an attempt to highlight many of these issues.


  • Software Reuse, Architecture, Process, and Organization fir Buisess Success by Jacobson, Martin Griss, and Patrik Jonsson
  • Design Patterns, GOF, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
  • Pattern Oriented Software Architecture, a system of Patterns, Volume 1 by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sornmerlad, and Michael Stal.
  • Patterns of Enterprise Application Architecture, By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford.

Wednesday, November 21, 2007

Presentation Skills Observation

This is my hints and observations after attending a one day ITIL awareness session and saw many speakers at the same day.

  1. Don't ever joke or even smile. Be very serious. People expect being very serious.
  2. Don't read slides. You are expert in the area of presentation, isn't you?
  3. Keep a distance between you and the audience. You are the teacher and they are the students, at least in this session. Don't let them feel your are friends or you are their servant.
  4. You are educating your audience. You many even challenge them by questions to keep them awake.
  5. Asking questions should be at the end only.
  6. Don't ask after each slide, "Is it OK to move to next slide?" Move on, you are the teacher. Some attendees are not prepared enough to follow you, you can't slow down much for them. The other good guys will suffer.
  7. Use attractive images from nature and may be human pictures, of course if related.
  8. Use wisdom quotes. It will inspire people.
  9. Don't ever show you are tired or disappointed. Be very confident and serious. If you feel that, show the reverse.
  10. If you are asked to give them the presentation (i.e. PowerPoint presentation file) (and there is no problem). Give it to them but let them feel a favor. I mean, let them feel they are getting a valuable asset.
  11. Don't ever slow down. You should move on to keep the flow of conversation. and to keep time. Keeping time is your own responsibility. Everyone will blame you if you did not.
  12. Don't ever give a speech in a subject you feel you are not expert in it.
  13. You own the slides. Even if prepared by someone else, you must tailor it, practice it and test yourself before the training session.

My hints focused on giving training or session to strangers that most of them you are seeing them the first time. Many of these points are not applicable to in-house sessions/training where everyone know everyone else.

ITIL Awarness Session by SECC

Yesterday, SECC organized a session about ITIL in ITIDA building in Smart Village, Cairo, Egypt.

Here are some of my personal notes, I just wrote it as it may be useful to someone else.

  1. ITIL have certified training for individuals, no certification per the organization. However, you can be certified by ISO20000. ITIL will help you in your certification. See
  2. HP helped Microsoft to has its own framework, called: Microsoft ITIL based framework (MOF), see:
  3. HP has their own efforts based on ITIL, "HP ITSM Reference Model v3.0".
  4. HP provides ITIL help and automation tools: Service View tool that let you understand your infrastructure dependencies. They have also Service Level Agreement monitoring software. I expect them to have many other tools.
  5. HP has their own way to assess ITIL implementation level.
  6. The importance of proper training. The presenter presented a very nice graph representing the transformation of data, to information, to knowledge to wisdom through professional training. He assumed written words in books like data and the experienced talented trainer help move the audience very fast to wisdom.
  7. Start (ITIL implementation) with the part in your organization that has the most pain. I generally like pragmatic approach!
  8. Let process drive the tools not the reverse. The tool buyer can push you in the wrong direction, be careful, I warned you.
  9. Deployment planning is so important to avoid service interruption.
  10. For me, the real experience of Mansour Auto and Orascom was exciting, more than the theoretical description of ITIL.
  11. In a big organization, agreeing on service level between internal dept is important in your excellence journey.
I recorded many notes about presentation hints, but I will post it in a separate post.

Amazing Iceberg

Many problems that could seem simple actually very big and requires a lot of efforts to be resolved. In some other cases, complex problems could have simple solutions.

I saw this picture, or some one like it, at a presentation about ITIL organized by SECC at ITIDA building in SmartVillage yesterday. See

> The image is from :

Sunday, November 18, 2007

A Definition of Best Practice

  1. The application of common sense; not rocket science
  2. Proven and practical activities which are in common use
  3. Replace "Chaos", "random results", or "best effort" with "order", "predictable quality" and "optimization"
  4. And by the way, when was the last time you needed an ROI justification to apply common sense?

Copied from public presentation.

My New Nokia N800

I am fond of Nokia N800 Internet tablet, but it is not yet available in Egypt. I asked friends in KSA, Dubai, and Kuwait with no success. I finally decided to buy one from but amazon does not ship outside USA.

Look at Nokia N800:,n800

The solution came finally few days ago from one of my friends. Aramex has a service called Shop&Ship. They will give you two addresses, one in USA and the other in UK. If you ordered any thing from USA, give the seller your address in USA. Once Aramex receive your shipment, they will re-ship it again to you at your home country. Look at:

The service was very exciting and finally I got my Nokia N800 Internet tablet.

As Nokia N800 is Linux based, you can download the source code and find tons of free open source programs at

Fired or Not?

In the case of a manager leaving his position, if you want to know if he is fired or moved to a better position, notice his speech in his farewell:

If he is not fired:
  1. He speaks about his past achievements with pride.
  2. He speaks about his future with enthusiasm and excitement.

If he is fired:
  1. He speaks about past achievements with a pity tone.
  2. He speaks about his future with doubts and almost have no concrete or exciting plans.

Process Improvement, a Parallel Documentation Project

One of the pitfalls of applying process improvement is to stay using the same old process and having a parallel project that just produce the required documentation. Project documentation is actually important but it is just documentation.

To make things clear, here is an example. If you developed a design document early as opposed to documenting the design after the actual implementation. The process improvement approach will change the way you do your work and will direct you to think and plan using design document. You will make reviews and inspection on time per the defined process. The other approach lets you developer design in the same old way and before QA audit or before appraisal, you will create a design document.