Objektum Solutions - The Technical Diaries

Web Content Life Cycle

noreply@blogger.com (Objektum Solutions) — Mon, 19 Dec 2011 06:31:08 PST

Joe teaches us what he has learnt about Web Content Life Cycles...

After spending some time looking over different people’s views on web content life cycles I have decided to put my own opinion out there.

There have been vast changes in what is thought to be involved in the life cycle of web content. The way that I understand “Web Content Life Cycle” is the different phases that your content goes through from start to finish including the idea of it through to it being replaced.

It all started with the idea of contents life consisting of two phases which were collecting and delivery. This would be writing the content and publishing it, nothing more that. There have been various other suggestions including the humorous suggestion of there being 15 stages to the web content life cycle.

My opinion is very similar to that of CM Pros which is that there should be 6 main stages but each stage is broken down into a few different parts. These stages are:

Plan, Develop, Manage, Deploy, Preserve and Evaluate.

Each stage is then broken down for example Develop, consists of Create, Capture, Collect, Categorize and Edit. By breaking down each stage means that each corner of the process is covered and the best content is delivered.

I believe that not all content needs to be replaced regularly and that if content is good and strong with a few tweaks and updates it can stay good informative and strong. This goes with the stage preserve, updating and adding to existing content is a good way to keep it alive and not having to come up with new content to replace it.

By using this method of updating and evaluating your content you can keep it as up to date, valid and relevant as possible. Having up to date relative content is extremely important as the more relevant your content the better for SEO purposes. Content will become outdated at some point and will need to be replaced to stop it becoming legacy content and it being useless. This is when the evaluation will tell us that it is time to replace the content with new fresh ideas and information.

Christmas List for Geeks and Engineers

noreply@blogger.com (Objektum Solutions) — Fri, 25 Nov 2011 06:06:28 PST

Today is Black Friday in the US. It's the day after Thanksgiving Day and traditionally the start of the Christmas shopping rush. It's the busiest shopping day in the US every year. If you're like me, that will fill you with paralysing fear. The queues, the commotion, the clothes falling off the hangers. It's terrifying out there. But hurrah, technology has saved us once again! Jump online and have it delivered to you whilst you get on with your life.

So, whether it's for a friend, colleague or loved one, here's our list of Christmas present ideas for those software nuts and computer geeks. Don't worry, we're not turning into a shopping channel or GQ magazine showcasing the "hottest and slickest" gadgets no-one can really afford, this is a fun Friday lunchtime post to embrace our inner nerd.

1. CPG6 GRID-IT TM Organizer $9.99

Keep cables, wires and gadgets tidy with this nifty organiser.

2. Wipe T Shirt $89.00

This smart T shirt has a convenient, built-in microfiber cloth to wipe your glasses or mobile phone.

3. Personalised QR Code Christmas Card on Etsy Approx £2.49

Embrace Christmas 2.0 and send a personalised message on a QRistmas card.

4. Binary Code Heart with I Love You Print on Etsy Approx £9.97

Say I love you to your partner in a way that they understand.

5. "Backspace" T-shirt from Threadless $10.00 (Mens and Womens sizes available)

Everytime you hit the backspace key, imagine that the cursor doing the moonwalk. How can you not be smiling?

Now, remember your Paypal password and get clicking. This activity contains no queues, no unhelpful sales assisstants and no need to fight for survival. Enjoy.

Don't Try to Run Before You Can Walk - Understanding Existing Code

noreply@blogger.com (Objektum Solutions) — Mon, 19 Dec 2011 06:28:02 PST

This week, Joe puts on his programming hat and straps his matching trainers but soon learns that it's hard to run before you can walk...

The most important lesson that I have learnt in recent weeks is that before I am going to change something I need to understand what it did before. It all makes sense now, how can you change something and make it better if you don’t understand what and how it did whatever it’s doing before? By not understanding what something does but trying to change it to make it better is the same concept as trying to run before you can walk.

Spending hours reading over the same lines of code trying to put pieces together and understand what it is the code is doing and why has been one of the things I have struggled with most in my journey so far.

I have now realised that I don’t need to spend hours reading over the same lines but I can run through a section of code line by line and just comment in what each bit is doing. Derek and I spent a short amount of time looking at a few lines of code that I had been studying for at least 3 hours. I hadn’t quite grasped what was happening or why. Within minutes Derek had told me just to comment each line of code as we go through saying in English what that line is doing. By doing this I had started looking at a line individually rather than everything together which meant that I could now break the code down and understand it.

I’ve started to deal with SQL queries with some of the different alterations I have been making over the last week. I came across one of our queries in the database which had a huge number of different sections and tables added and linked to it. Looking at a query of this size scared me at first as I had no idea where to start when trying to use it to gain the right information out of it. After actually reading through it, it became quite clear that all I needed to do was to select in the code the correct field of information that I wanted to know from the results of the query.

By taking over a project that someone else has been managing for quite a long time puts me in the position of having to read, understand, edit and add to someone else’s code. From being able to do this successfully means that my knowledge of VB is increasing vastly. I am able to break down different sections of code that once upon a time I would have just shook my head at and walked away to now being in the position to have a quick look at it in a logical way and work out what is going on.

My journey is always changing and always going in the right direction, UP! I am constantly learning and progressing in what has been a short amount of time but large amounts have been achieved. I have gone from an absolute novice to being able to work my way around VB with a little bit of class and make some quite simple but very beneficial programs and functions. I can’t wait to be telling you all in my next chapter in my Programming Journey.

Can you remember your first experiences of programming? Do you have any advice to give to those who are just starting out? Tell us here and let others know and pass on your wisdom to the next generation of enthusiastic software engineers.

Steve Jobs and Dennis Ritchie's Guide to Success

noreply@blogger.com (Objektum Solutions) — Fri, 14 Oct 2011 08:53:35 PDT

Within four days the world lost two of the greatest technology pioneers. Apple’s CEO and founder, Steve Jobs and Dennis Ritchie, an American computer scientist and co-creator of the programming language C and operating systems such as Multics and Unix. Jobs’ and Ritchie’s characters couldn’t be more different. Jobs was known to be fiery and ruthless whereas Ritchie was humble and gentle. Catherine finds that despite being like chalk and cheese, they were both innovators who found a code to success...

Steve Jobs and Dennis Ritchie’s Code to Success

1. Reverse a trend. Ritchie and Jobs went against the grain and created something unexpected and new. They say that Jobs knew what customers wanted before they wanted it. Ritchie and his partner Kenneth Thompson felt that operating systems were too complex and they “attempted to reverse the trend” with the UNIX operating system.

2. Make technology simple. The UNIX operating system was created to make computing as simple as possible and the vision for C was to create a programming language at a higher level of abstraction that people would understand and use. In the same breath, Apple’s intuitive, fuss-free iPods are cited as being one of the greatest gadgets of all time.

3. Create a community. Ritchie explains that UNIX was created not just to be a good programming environment in which to do programming but a system around which a community or a fellowship could form. He said “close communication” was of key importance. Apple on the other hand created devices and a brand so iconic that they created a cult following so loyal they would rather go without than not have the little munched apple stamp on their phone or computer. The world boils down to a defined matrix of two hemispheres, two genders, and whether you’re a part of the Apple movement or not.

4. Make it easy on the eye. UNIX was created to have “graceful facilities for decomposing complex computer tasks into simple subtasks”. Now, who’s to argue that Apple’s operating system isn’t graceful and their apps decompose life’s complex tasks into a small series of manageable subtasks.

5. Let the technology take centre stage. Their success wasn’t about them; it was about what they created. Jobs and Ritchie were both private men. One of Ritchie’s colleagues says of him, "I worked across the hall from him for more than 20 years, and yet I feel like don’t knew him all that well.” Steve Jobs on the other hand was the same but his insistence on leading a private life only fuelled the cult of personality that surrounded him.

Steve Jobs' Golden Apple

noreply@blogger.com (Objektum Solutions) — Fri, 14 Oct 2011 08:34:57 PDT

The golden apple is featured in legends and fairy tales as divine food or a source of immortality. Steve Jobs retrieved the golden Apple in this story but it is his legacy which is immortal and lives on. Joe tries to uncover how Jobs shaped Apple...

He's the man that people have been calling a genius in business and an inspiration. Steve Jobs was the co-founder of Apple and ran a very tight organization with high levels of secrecy, going to extreme lengths to live up to his perfectionist way of doing business and being involved with everything to do with Apple.

Jobs was a workaholic who remained CEO of Apple up until 6 weeks before his death. Taking so much pride in his creations and working life meant that he inspired people he worked with. He had very controversial leadership style which made Apple what it is today. Being a perfectionist meant that it was up to Jobs' employees to live and work to those standards. He was all about user experience being the true top priority. This meant that any small visual flaws in design overlooked everything else and would be classed as failure. Employees said “By being both unreasonable and right, he taught us to create products to delight people, not just satisfy them.” Steve Jobs promoted his perfectionist attitude around Apple and forced it into work that was done for him and made people realise that the reputation of Apple was at stake with any work that was being done.

“Loose lips might sink ships,” These are the words that were on the poster in Job’s office. The high level of secrecy within Apple was down to Job’s. He would insist on random phone and computer checks to make sure nothing was being leaked to the press about upcoming products which has meant that when a new product is coming out from Apple it is actually new not something that is awaited by the public.

Steve Jobs is the man that has left an imprint on just about all of our lives in one way or another. He transformed so many different markets such as music and phones forever. Steve Jobs will always be looked at as an inspiration to countless amounts of people for a countless amount of things he brought to the world.

When the Bough Breaks – Alternate Scenarios

noreply@blogger.com (Objektum Solutions) — Fri, 30 Sep 2011 08:52:40 PDT

Alex returns with his blog post series on understanding use cases...

Wow, it’s been four months since I wrote my piece on primary scenarios so this is severely overdue. I choose to blame this on the fact that one of our account managers, Ajay, appears to be offended by the idea that my calendar can have days in it that have no entries at all and does everything in his power, successfully I might add, to account for every minute of every day of my life. This has actually become something of a joke with many of our customers who, when asking me if I’m available to do something, “understand” that I must first get permission for Ajay before replying. Enough about my scheduling situation, were here to talk use cases.

Our previously defined primary scenario details the required behaviour of the system under “ideal” conditions and is useful in the understanding of customer requirements. The thing about customer requirements is that, even the most thoroughly defined, requirements are likely to only specify the nominal behavioural flow. Most of the customer requirements that I have read are significantly lacking in detail when things don’t go according to plan.

The use case primary scenario provides us with a clearer understanding of what it is that our customer requires but what about the things that they didn’t take into account? It is here that the alternate scenario provides answers or, in the case of most requirements, questions that need answering.

The identification of alternate scenarios is a three step process:

Run through each step in the primary scenario and ask yourself; “what could happen differently?” to produce a list of potential alternate conditions
Rationalise the list by removing those that the system cannot or does not need to handle and merging the ones that will be handled in the same way
Write the scenario for each condition in the rationalised list.

During the identification of alternate conditions you should be looking for things such as:

Incorrect behaviour on the part of either the primary or supporting actors
Timeouts; one of the actors failing to provide a required interaction

When writing an alternate scenario the alternate condition becomes the trigger and then all we have to do is write what happens next until one of two things happen; either the primary scenario is re-joined or the use case ends because the goal cannot be achieved.

Typically the documenting of alternate scenarios is where use cases provide the most benefit in highlighting the inconsistency and incompleteness of the customer requirement.

Finally one should repeat the process on each of the alternate scenarios to identify possible alternates upon the alternates. Obviously this could be applied recursively through many levels however I tend to find that if you need more than two layers of alternates you should reconsider the scope of the use case as it is highly likely that you have attempted to include multiple capabilities that should each have their own use case.

Even with only two layers of alternates it is possible to develop far more scenarios than are actually needed, so, be sure to always question if what you are writing is adding to the required understanding of the system under development.

Next time I’ll look at how we model common and specialised behaviour in our use cases.

Model Driven Development: Past and Future

noreply@blogger.com (Objektum Solutions) — Fri, 23 Sep 2011 08:02:37 PDT

In the first in a series of interviews about UML and Model Driven software, Todd speaks with expert Rafael Chaves of Abstratt Technologies to find out his opinion on model driven development...

Todd Humphries: Did you have a 'Eureka!' moment when modelling made sense for the first time and just became obvious or was there one particular time you can think of where your opinion changed?

Rafael Chaves: When I was first exposed to UML back in school it did feel cool to be able to think about systems at a higher level of abstraction, and be able to communicate your ideas before getting down to the code (we often would just model systems but never actually build them). The value of UML modeling for the purpose of communication was evident, but that was about it. I remember feeling a bit like I was cheating, as drawing diagrams gave me no confidence the plans I was making actually made a lot of sense.

After that, still early in my career, I had the opportunity of working in a team where we were using an in-house code generation tool (first, as many have done, using XML and XSLT, and later, using UML XMI and Velocity templates, also common choices). We would get reams of Java code, EJB configuration files and SQL DDL generated from the designer models, and it did feel a very productive strategy for writing all that code. But the interesting bits (business logic) were still left to be written in Java (using the generation gap pattern). It was much better than writing all that EJB boilerplate code by hand, but it was still cumbersome and there was no true gain in the level of abstraction, as we would model thinking of the code that would be generated - no surprise, as there was no escaping the facts that we would rely on the Java compiler and JUnit tests to figure out whether the model had problems, and in order to write the actual business logic in Java, we had to be very familiar with the code that was generated. So even though I could see the practical utility of modeling by witnessing the productivity gains we obtained, there was a hackish undertone to it, and while it worked, it didn't feel like solid engineering.

It was only later, when I was doing research for my Masters, and I was finally exposed to the approach of executable modeling and MDA, that I finally understood there was authentic value to modeling. Real gains in level of abstraction. Validation and execution of models long before a target platform was even chosen. Full code generation, including business logic. Ultimate platform independence. It finally made all the sense in the world. It made so much sense to me that I could not believe that was not how everybody was writing software. Since then, I have been obsessed with building tools to help bring the approach to the mainstream.

TH: What would you like to see in future versions of the UML standard? What do you think UML is lacking that would help MDD progress?

RC: I actually wrote a post about this a while ago which I think addresses that exact question:

http://abstratt.com/blog/2010/02/08/uml-may-suck-but-is-there-anything-better/

TH: You've written in the past about misconceptions and myths you've come across trying to promote MDD, in your experience is it usually experienced software engineers or new graduates who are the most accepting of modelling principles and why do you think that might be?

RC: Talking specifically about MDD (and not modeling in general): I think in general less experienced developers will buy into MDD more easily than more experienced developers. More senior folk will tend to resist more to the idea that the much of what they do (and are very proud of) could be done automatically.

Re: modeling in general - I, for one, will resist to the idea of modeling as something inherently beneficial - unless your models are actually what drive the software development (they are the primary artifacts), I see modeling as superfluous and wasteful.

TH: Do you think MDD is easier to pick up for someone who has little to no 'real-world'/practical experience of software development or for those with many years traditional development experience?

RC: Hard to say - I do think experience is usually beneficial, and a more experienced modeler will in general produce better results than a novice modeler. OTOH, I think it is much easier for a novice developer to build high quality applications using the MDD approach than manually crafting the application (because MDD allows you to encapsulate and reuse skills/expertise).

TH: Are there any books, blogs or other sources that you would recommend for someone new to or inexperienced with MDD? Any tips of your own or those that helped you that you'd care to share?

RC:

Read the MDA Guide 1.0

Join the ModelDrivenSoftwareNetwork
Read about Executable UML
Follow @seidewitz on Twitter
H. S. Lahman recent book (Model Based Development)
Markus Volter book on MDSD is a good introduction as well.

Study the codebase of enterprise applications in Java or C# (or even RoR) and look for the implementation patterns

Look at an application and learn to consciously separate problem domain concerns (which are implementation independent) and solution domain concerns (which are implementation specific)

TH: Back in November last year you said "I think we still live in the dark ages of software development And, what is your vision or dream of how software development might look in ten years? Twenty?

RC: We would use a language that is at higher level of abstraction than 3GLs which would allow us to naturally express technology independent solutions, and then target different platforms with ease. The target platform won't put constraints on how we reason about solutions, and the development tool we use won't put constraints on what platform we target.

There will be a market for reusable business applications (which can target multiple platforms), and a market of target platform-specific code generators (which can accept applications from different domains).

This is a great introduction to UML for beginners as well as being interesting to those who are working with executable modeling and been through it all...

Thank you Rafael for such considered answers and creating a great read!

Joe's Database Delight

noreply@blogger.com (Objektum Solutions) — Tue, 20 Sep 2011 03:44:34 PDT


Joe becomes more of a computer nerd with each passing day.

Trainee software engineer, Joe learns about databases and continues on his journey into becoming a real software wizkid...

The last couple of weeks have been a very steep learning curve in my programming process. I have had some intense lessons in things such as databases and VB6. I started to get a little more confident in my programming abilities, being able to make small functional programs that did simple task.

I got to this stage and thought I was clean sailing from there and thought it would just be more of the same stuff for a while. Wow, was I wrong! I was given the on-going task of taking over and maintaining our in-house administration tool. This tool was made in VB6 some years ago and we saw it as the perfect project for me to expand my existing knowledge and give me the chance to work on a project that would actually be very beneficial to the company. The first thing that I did was spend a day just trying to get my head around the tool. It was totally new to me and the project just seemed huge. Once I had spent a day or two studying the code and which paths different functions were taking I started to understand how things were working a bit.

The next step was to actually try and make some changes to it. The first couple of changes I made were very simple but all the same I thought I was doing amazing actually being able to change something for the better in a project of this size! All I was doing was changing the maximum amount of characters that could be entered into a text box. After I had made these changes I was given the task of automatically generating an email and populating it with a subject, a set of email addresses and with a body of text.

My first lesson was a quick but informative lesson on databases. Derek and Todd ran me through how a database works, how they are linked together and how to call information from the database using queries. Once I had learnt that it was then time to try and pull everything I had learnt together and with a bit of help from Derek I managed to make the function that did exactly the right job that we wanted to achieve. I was so happy with the progress that we had made and that I had made a working function that would be largely beneficial to the company.

This was not the end though. Although I had thought it was ready to be published and become part of the company’s in-house tool, I was wrong. We discussed making it into a HTML email. It was like being put back to square one again as I knew absolutely nothing about html emails. After doing some research and spending some time with Fiona we came up with the html email that we wanted to be in the body of the email. We then worked out that if we wanted to change the body of the email we didn’t want it to be hard coded into the function. We decided to make the function take the contents of a document which contained the body of the email so if we ever want to change the email we just had to replace what was in the document.

So, there it was, my first big change to the company’s most important in-house administration tool. Needless to say I am very happy with what I have achieved over a short period of time and I can’t wait for what is next.

Needless to say, we're impressed with how much Joe has learnt since being with Objektum Solutions and proud to have him on the team!

Engineers with a Sense of Humour

noreply@blogger.com (Objektum Solutions) — Thu, 15 Sep 2011 02:43:58 PDT

As Summer fades into Autumn, we bring you a post that we found on the world wide web to brighten up your day...

After every flight, pilots fill out a form, called a gripe sheet which tells mechanics about problems with the aircraft. The mechanics correct the problems, document their repairs on the form, and then pilots review the gripe sheets before the next flight. Never let it be said that ground crews lack a sense of humor. Here are some maintenance complaints submitted by pilots and the solutions recorded by maintenance engineers. By the way, the airline these came from the only major airline that has never, ever, had an accident.

Pilot: Left inside main tire almost needs replacement.

Engineers: Almost replaced left inside main tire.

Pilot: Test flight OK, except auto-land very rough.

Engineers: Auto-land not installed on this aircraft.

Pilot: Something loose in cockpit.
Engineers: Something tightened in cockpit.

Pilot: Dead bugs on windshield.
Engineers: Live bugs on back-order.

Pilot: Autopilot in altitude-hold mode produces a 200 feet per minute descent.
Engineers: Cannot reproduce problem on ground.

Pilot: Evidence of leak on right main landing gear.
Engineers: Evidence removed.

Pilot: DME volume unbelievably loud.
Engineers: DME volume set to more believable level.

Pilot: Friction locks cause throttle levers to stick.
Engineers: That's what friction locks are for.

Pilot: IFF inoperative in OFF mode.
Engineers: IFF always inoperative in OFF mode.

Pilot: Suspected crack in windshield.
Engineers: Suspect you're right.

Pilot: Number 3 engine missing.
Engineers: Engine found on right wing after brief search.

Pilot: Aircraft handles funny.
Engineers: Aircraft warned to straighten up, fly right, and be serious.

Pilot: Target radar hums.
Engineers: Reprogrammed target radar with lyrics.

Pilot: Mouse in cockpit.
Engineers: Cat installed.

Pilot: Noise coming from under instrument panel. Sounds like a midget pounding on something with a hammer.
Engineers: Took hammer away from midget.

A load of old Cobol...

noreply@blogger.com (Objektum Solutions) — Wed, 07 Sep 2011 01:54:09 PDT

Todd, Software Engineer at Objektum Solutions, discusses what he has learnt about the legacy language, Cobol...

Having just started my career as a software engineer, I was only really peripherally aware of Cobol; my knowledge only extending so far as knowing that Cobol is a programing language and that it’s ‘quite old’. A quick search told me that Cobol is around 50 years old, which lead me to think that its use must be fairly small, probably only for a handful of mainframe applications or unimportant systems that aren’t worth migrating and probably haven’t been run for years or perhaps decades.

Now before you snort in (well deserved) derision, I’m more than happy to hold up my hands and admit that I was as ignorant as they come. Imagine my surprise then, when during the course of doing background research for the CobolExplorer I came across the following figures in an article about employability of Cobol developers

70-75% of the business and transaction systems around the world run on COBOL
The average American still interacts with a COBOL program 13 times a day
90% of global financial transactions are processed in COBOL

(Sources available at the foot of the linked article)

Even taking into account the age of some of the figures it was clear to me that there is a LOT of Cobol out there, much more than I would have imagined. This new revelation forced me to start wondering who exactly is maintaining all this code, and more importantly why?

A 2008 report by Forrester Research titled ‘Software and Services Data Overview’ shows that maintenance accounts for around a third of the total-cost-of-ownership of any piece of software. It isn’t obvious if that figure includes the cost associated with having to train people in the legacy systems well enough to continue maintaining/supporting them, but I’d hazard a guess that it doesn’t.

In our recent work here at the office we’ve seen first-hand that maintenance costs aren’t the only way that legacy systems can harm organisations ability to generate revenue. How many potential wellsprings of profit have been left untapped because the current system wasn’t able to handle the required changes, or people qualified to carry out the work were unavailable? If you aren’t able to engage a new audience or expand into a new area it’s certain your competitors are more than happy to do so.

Automatic extraction and reporting of business rules directly from legacy Cobol source is just one of the ways CobolExplorer is able to help your organisation save time and money when estimating and tracking your legacy migration project.

Do you have legacy Cobol applications? Contact us today to arrange a discussion or webinar and find out more reasons that CobolExplorer is indispensable to your business.

Objektum Solutions partner with Samsung Crescent Racing

noreply@blogger.com (Objektum Solutions) — Tue, 30 Aug 2011 04:04:46 PDT

Objektum Solutions are proud to announce that we are the new sponsors of the British Superbike Racing team Samsung Crescent Racing.

In-line with the exciting nature of British Superbikes, Objektum-Solutions is not your run-of-the-mill technology company. We provide software migration, rapid engineering and training services for a wide range of high profile organisations, including BAE Systems, Brembo and Capgemini.

There are many members of Objektum Solutions team who share the same passion for motorcycle racing as Samsung Crescent Racing and this passion is what we believe will lead to a great partnership. Derek Russell, Founder and CEO of Objektum Solutions says,

“I have seen first-hand the level of professionalism shown by Crescent Suzuki at both world level, with MotoGP and national level, with BSB. This, along with their affinity with other high-technology leaders and innovators such as Samsung, makes them the ideal partner for Objektum Solutions, who are currently paving the way in the legacy migration and modernisation arena. I look forward to a long and successful partnership with the Samsung Crescent Racing team.”

Derek Russell on the track with his Suzuki

Samsung Crescent Racing team manager Jack Valentine adds: “It’s great getting yet another team partner on board in the shape of Objektum Solutions heading towards the latter part of the season. Having backing from a further non-industry partner is great exposure for both sides and should open up opportunities for a lasting relationship.”

Objektum Solutions is very excited about this new partnership and look forward to working with the team at Samsung Crescent Racing.

Interview: Overcoming Migration Challenges

noreply@blogger.com (Objektum Solutions) — Fri, 26 Aug 2011 08:07:09 PDT

Companies across the globe are continuing to allow legacy technology negatively impact their business because they either don’t know what to do or feel it is too risky or costly to modernise their applications. The reality is that there will come a point when they cannot ignore it anymore and they have to do something about their legacy systems.

Using the Legacy Bridge technology, one of our customers carried out a HOOD and Ada83 migration in to UML and Ada95 so that they could enhance existing their safety critical systems. We asked them about the migration and how they used technology to overcome their challenges they faced.

What was the main reason for migration?

There were three main reasons:

To have a single toolset for both Software Analysis and Software Design work
To reduce the number of toolsets in use on the project (thus reducing maintenance renewal costs)
To move to a company preferred toolset
To increase integration with other company preferred toolsets (i.e. DOORS and Dimensions CM)

What were the alternatives to using Legacy Bridge?

The Rhapsody in Ada inbuilt reverse engineering tools or to develop our own in house migration tools however this was deemed early on to be too expensive.

What was the deciding factor to choose Objektum Solutions and Legacy Bridge to migrate?

Objektum Solutions had already been through similar exercises of migrating from CP-HOOD to UML albeit to a different UML toolset with another organisation similar to ours. Legacy Bridge has the facility to bring across our HOOD artefacts, as well as synchronising the design with the current code.

What time savings did Legacy Bridge bring?

Once it had been proven that Legacy Bridge could correctly analyse our HOOD and our Ada, the process of migration and synchronising with the code took only a couple of hours per model.

And, how was it working with the team at Objektum Solutions?

The support provided by Objektum was excellent, with most problems being resolved with days (if not hours) of being reported. This enabled us to keep up the impetus of the migration process without have to wait too long for tool updates

Another colleague also commented saying "The turnaround time for problem resolution was exceptional. This has been possible with the tremendous knowledge the team have of the product including HOOD, UML and Ada."

What benefits does migrating to UML give you for the future?

We now have both our software analysis and software implementation models in the same toolset; with both of these models integrated with our requirements database and our configuration management system. All three toolsets are “current” toolsets widely used across the company and across industries.

Will code generation be a consideration going forward?

Code generation has to be ultimate aim; but for now we are happy that what is in Rhapsody can be shown (via the compare functionality) to be a reasonably accurate representation of the code.

Tales of the Team Building Day

noreply@blogger.com (Objektum Solutions) — Tue, 16 Aug 2011 01:23:29 PDT

Now, we’ve already built a strong team that work well together so for us it shouldn’t really be called a “Team Building Day”. It should be called “See-your-team-mates-outside-the office-and-what-they’re-really-like Day”. Needless to say, we all became closer and it was a worthwhile day to strengthen the team, but boy did we have fun as well.

We decided to book a day of team challenges and tasks with Priory Events in a wonderful spot in the country in Nutfield, Surrey. Our first task was to keep our fingers and toes crossed the whole of the day and night before, wishing that the torrential rain would clear and that the sun would reign and cast its rays on the fields and rolling hills of Nutfield. Mission accomplished. It was a glorious day.

We failed on the second task: finding the right place. However, we did ALL end up at the same incorrect spot so in the spirit of the day at least it was a team effort.

We followed the smell of sizzling bacon and went in our cars on convoy to The Barn where we were divided into our teams and briefed on the day. Rest assured the smell we followed was bacon sandwiches and not a pig rubbing in tanning oil with its trotters and basking in the scorching sun. (I apologise to vegetarians now)

The first (real) task was an icebreaker in which we had to pass each member of the team through a loop of rope. Apparently we could do it in 1 second less than the number of people on the team. So for a team of 5, we should be able to do it in 4 seconds. We deal with complex problems every day, but this blew our minds. How on earth where we going to do it? I know you’re meant to encourage your team members in scenarios, but the first suggestion on our team (and I shall mention no names) was utterly ridiculous. There was no way that if we sat on each other’s shoulders and passed the rope over two people at a time that it would work, especially bearing in mind that we’re a bunch of people working in a technology company and certainly not gymnasts. I didn’t want anyone to die (although this almost happened again, read on to find out how…) and another minor worry was what our insurance would cover and wouldn’t cover if we accidently formed a noose with the rope and inadvertently strangled a staff member. As we’re now in the Magic Circle of Team Building Events, I can’t share with you how we did it but with the whole team working together we managed to complete the task in 2 seconds less than the number of people.

Then it was the Nuclear Reactor challenge. The aim of this activity was to place the highly sensitive core (plastic tube) inside the nuclear reactor (barrel). The core’s alarm was triggered if moved suddenly or tilted too far. The layout of the activity has an inner, & an outer square. And there are items the group can use to get the core into the nuclear reactor.

Right, they told us all that information beforehand. What they didn’t tell us was that when you’re in the outer square, building the contraption to somehow deposit the core into the reactor in the inner square, you’re blindfolded. So, only two people were in the outer square at one time in the dark and the rest were guiding them. Now the lesson learnt here was that it is very hard to guide someone when no-one knows what the solution is. There were so many items to choose from yet we knew there was a simple solution. That was the most frustrating thing. That and the fact that most children succeed in this task but only a small percentage of adults do. The time was up and we were on our way to building Sputnik but the core still sat next to us. The simple solution incorporated two pieces of rope and an elastic band that has been tied to a jug. Most adults think that the elastic band and the jug have to be used as one. As soon as we were told, there was a Mexican Wave as everyone lifted their hands and smacked their forehead.

A few slurps of tea and we were back out in the fields. This time we were building bridges. We all thought we build Bridges as our business, albeit migration Bridges, and if there’s any task we should be able to succeed in, this was it. Turns out, it wasn’t so easy. I won’t go into the details of the task, but this really showed us that we had to decide on a plan of attack as a team and then if the plan was revised, it had to be communicated to the whole team. Something I know we do in the office, but in the field, literally, it all fell apart; as did Team 2’s bridge. Team 1 was slightly better but a little unsteady. Confidence knocked and worrying that if the floods came we wouldn’t even be able to build a bridge never mind an arc, we went back to the barn for lunch.

There was sense of determination in the afternoon as we gathered for the brief on the next activity: The Satellite Challenge. Great I thought -we’d already built Sputnik in our previous task. We were in our two teams and armed with sat-navs and a list of waypoints and sent off into the Surrey countryside to find different clues and collect various items on the way including something beginning with K, which kept me thinking “K, K, K…” the whole of the task. I desperately wanted caterpillar, cone, clump-of-mud all to begin with K. Team 1 had a lovely stroll over the meandering hills and down country lanes finding the different clues. I’m sure at one point butterflies were dancing round us. It was a peaceful walk to walk off lunch and we chatted and laughed. The only moment we really sped up was when we discovered we’d walked onto the shooting range. It only felt like a slight twist in our Famous Five adventure and then we were back on track. Team 2’s, who had slightly different waypoints, trip was less like an Enid Blyton novel and more like something out of Lost.

Treacherous terrain, nettles grabbing at their ankles, hiking up and down hills, mysterious bits of rope leading them to the clues… It was amazing that we all got to the same area at the same time, looking for the penultimate clue. Both teams kept quiet about finding our clues as we walked surreptitiously back to the car park – the known end point. We could see Team 2 across the field and the turened to walk behind a dividing hedge. They were slightly ahead and so we seized the opportunity to gain some ground and so we started running back to the car park. But they spotted us as they emerged into the clearing and started running too. The race was on. Team Building? Screw them, we were getting in first. Sprinting over the fields, the Chariots of Fire music started only interrupted by shouting on at our team mates to run faster (I can only apologise, I was caught up in the moment). Team 1 won the task and gained a head start on the next task but it didn’t help us at all as Joe explains…

The funniest part of my day was the transport up the hill section where we had two sets of huge ski-like paddles which had foot loops and handles. Each team had 5 members on the skis and we had to march our way up the slight hill. I found this hilarious due to the fact the Ajay on the other team was falling over every couple of seconds and the fact that me laughing was putting Fiona off. The more she shouted at me to stop laughing the harder I laughed. I ended up laughing for the whole duration of the task but of course we still won! Needless to say Ajay spent more time on the floor than he did on the skis.

Now, the finale task was the most adventurous. The stakes were great and the risks were high. We were the Pirates of Priory and we had to reclaim some treasure which was the other side of the large pond. Yep, it was the good ole raft building challenges where teams pull together the skills they have learnt from the day to build a raft and then fly their flag to the other side of the pond get the key and come back to a hero’s welcome as their team claps and woops them in so that they can run to the treasure chest and open the box. Soo, didn’t quite work that way for us.

Both teams worked out a plan. We communicated ideas and bound the barrels and wood together to make a raft. I was chuffed when the instructor told us ours looked “structurally sound”. Turns out, it’s not the quantity of rope you use, it’s how tightly you tie it. We put our raft in the water and Ajay (who eventually realised he had put on a child’s lifejacket) and I were the nominated and willing members of Team 1 who followed the raft into the pondweed and sludgy waters. We were on the raft for about 4 seconds when it started to dismantle. Now, if a Team Building day doesn’t bond you to your team mates, untangling them from rope as they see their life flash before their eyes will do. So moral, of the story – bond with your team mates but don’t bond them to the raft.

Meanwhile, the other team had put their raft into the water. Fiona, our Product Delivery Manager for training, showed a different side by firmly telling our apprentice Joe not to be a wimp and get his trainers wet. Alex and Derek had jumped in and mounted their upside down raft. It seemed to work but not as buoyant as one might expect a raft to be. So instead of a dash to the key, Alex and Derek punted over to other side at such a pace, their team member’s sitting on the bank almost forgot about them. Team 1 built an “emergency raft” (no emergency biscuits available – The Apprentice fans will get this) with the help of the instructor which was finished just as the other team came back to “shore” and opened up the treasure chest. All that hard work for nothing; I took the raft out for a spin anyway.

A couple of people wet, a few burnt and all smiling. It was a brilliant day and although not a model team building day, we definitely grew closer as a team.

The Journey Continues – Developing a Work Process

noreply@blogger.com (Objektum Solutions) — Thu, 04 Aug 2011 08:19:42 PDT

We needed to re-structure our website and make some drastic changes. Taking on the challenge, Joe, our webmaster and apprentice, worked with the rest of the team and learnt a lot on the way....

After spending the last two weeks working on transforming our website’s overall look as well as improving the descriptions of the products and services that we deliver, I have learnt rather a lot in a short amount of time about working with CSS and ASP. For example, making classes in the CSS to change the way images are being shown and where they are positioned as well as how text is being displayed.

I have been working alongside Todd, our software engineer and Catherine, who’s responsible for marketing, to bring the new look of the website and the new content together. My knowledge for Dreamweaver has increased vastly in this short period of time as I have had to do things that I had never done before, from things that I have learnt from starting to learn programming I have been able to complete a lot of the processes that I have needed to do a lot quicker. I am now able to look at a web page in code form and know exactly what lines of code are doing certain things. I now understand how our database is connected to the website and how it deals with queries and what it is doing to return the correct results.

I spent the first 3 days constantly asking questions “How do I do this?” “How do I do that?” I’m not sure how I didn’t drive anyone crazy! After listening carefully and a bit of trial and error I picked up on where I was making my mistakes such as in CSS forgetting to put a semi colon at the end of a line and then wondering why the new class I had created was doing absolutely nothing! These small mistakes have helped me a great deal and have made me create a mental process to go through every time I need to make a new class.

There are valuable lessons like this which have made working on the website a massive part of my journey to learning how to program. I have been shown that there is a logical answer to everything, and that if I spend a bit of time and put in the effort the answer is not always as far away as I once thought.

Friday 22^nd July was an interesting day. This was the day the website went live with all the new changes that had been made. Meetings were had to discuss what was left to be done and who was going to do it. I am lucky enough to have the role of implementing all of the work everyone else is doing such as writing the content. This means that I don’t have to sit there copy writing, which I don’t particularly like doing.

Some problems that we came across were simply due to different browsers not liking our changes which of course is always a pain when you have made a change that works perfectly in one browser then you test it in another and it comes out completely different. Todd had this with one of the changes he was making that even in the same browser but on a different machine he had different results! A nightmare to figure out but as always, he found the solution.

When the pressure to get something done is there the day always seems to fly and Friday was no exception to this. Before I knew it, the end of the day was closing in and everyone was concentrating hard trying to get their last bits of work done ready for the website to go live.

I had spent the last two weeks learning ASP and CSS almost non-stop while developing the website into its new state. The difference in my knowledge of ASP and CSS from the start of the two weeks to the end of it is unreal. One of the main things I have learnt from these couple of weeks has been not to ask every time that I come across something I don’t know, spend some time and work it out for myself because I actually know more than I sometimes think (not always though!)The answers can be found rather quickly if I think about what I am trying to find out. I have surprised myself with the amount that I have been able to get done in this short amount of time as some of the changes that have been made to the website are huge.

I believe that this has been a great achievement for us and I know for a fact it wouldn’t have been achieved if the team didn’t work so well together and each and every one of us was dedicated to getting the job done. A big thanks from me to the team!

Our website changes are all live and you can find out more about our products and services here: www.objektum-solutions.com

The Start of a Programmer’s Journey

noreply@blogger.com (Objektum Solutions) — Thu, 21 Jul 2011 03:06:52 PDT

Joe Gates has kick started his software career with us at Objektum Solutions and in this post he tells us how it all began…

I first came to Objektum Solutions with next to no knowledge of software or programming. I spent the last year working for a small web design and development company building different type of websites for clients. I moved to Objektum Solutions with the intent to learn and further develop my skills in web design and development.

This took a huge turn when I spent the first week at Objektum Solutions surrounded by programmers and software engineers.

My interest for programming started from there. I was amazed with everything that they were talking about even though I had almost no idea what they were on about! I had a conversation with Derek, our Technical Director, about what I was going to do over the coming months and I mentioned that I was very interested in learning a programming language and would love to get involved with it. He had no hesitation in giving me his personal books and said where to start. Since then I have been continuing with the web design and development but also learning Visual Basic.Net. So far in my first month I have learnt how to make small but functional programs such as a program that simply adds numbers together, to what I learnt today was my first recursive program. I was given the task of creating a program which would work out and give the result of the factorials of a number.

Derek then gave me a short but very beneficial lesson on numeral systems, teaching me the basics of how binary and hexadecimal systems work. Derek and I believe that knowing how these systems work is a fundamental part of my learning and knowing how to use them will be extremely beneficial later on in my journey of learning how to program.

Obsolete Programming Languages

noreply@blogger.com (Objektum Solutions) — Fri, 21 Oct 2011 03:40:58 PDT

Fiona provides us with another insightful post on programming and where we go next once a language has become non-existent....

With technology changing and advancing so rapidly, the programming languages which sit behind the gadgets we love are also evolving and changing. Languages often become out-dated and begin to cover less and less of technology’s needs, for example the widespread use of the web has led to the influx of new web languages which have differing features than the languages developed in the 70s through the 90s. So what is the lifespan of a programming language? When does a programming language become obsolete? And also where do we go next once a language has become non-existent?

Currently, it seems that Pascal, Turbo Pascal and VB6 have been completely written off as redundant. The languages which could presently be described as in decline or progressing towards another language include C, C++, Perl and Delphi and perhaps even Java maybe losing pace to Ruby. So why when languages are in decline do we still find developers vigorously maintaining and coding using the same languages? Well a manual software migration process is costly and time-consuming to say the least. In fact it is the laborious and repetitive task of rewriting lines of code which frustrates developers and prevents them from programming in the language they truly desire.

So let’s explore the likely advantages of an automated model driven approach to language to language software migration. Aside from the previously mentioned cost and time involved in a full manual migration there are often other issues and failings with this type of process. The scope of the project is difficult to contain, new requirements often present themselves replacing existing requirements, and eventually the new system differs from the existing legacy system. An automated approach enforces rules and consistency which will preserve the quality of the code.

However, a move to a model-driven development environment is an effective alternative to this process. Using this environment will result in faster software migration which may well show which languages are actually redundant and lead to future obsolescence of languages at a much faster rate. Perhaps, this will radically change the way we view programming languages as they become more progressive and adaptable. Will we begin to see the days of teams of programmers battling with boundless lines of code as an ancient practice? Watch this space…

Happy 100th Birthday IBM!

noreply@blogger.com (Objektum Solutions) — Mon, 27 Jun 2011 09:28:44 PDT

100 years old is an impressive age to reach for a company. As IBM point out in their essay on the occasion “Of the top 25 industrial corporations in the United States in 1900, only two remained on that list at the start of the 1960s. And of the top 25 companies on the Fortune 500 in 1961, only six remain there today.”

They have launched a website to celebrate their 100^th birthday and their journey up until now. It is inspiring to know what a company can achieve in a century and how much technology has advanced since their conception in 1911.

For our own company and growth, this quotation from Samuel J. Palmisano is especially poignant...

“ If your business is based on
moving to the future, you
can’t be emotionally tied
to your past.”
— Samuel J. Palmisano,
Chairman, President and CEO, IBM

We have been working with IBM technologies and personnel since our incorporation and our consultants have worked with the tools in various industries for even longer. We are now Authorised Training Partners and not only work with IBM as a reseller but we also use our expertise to deliver a wide selection Rational courses.

So all that remains to say is that we hope that we will be working with IBM for many more years to come and that we hope that our British IBM colleagues receive a telegram from the Queen (or does she send texts now?).

And if you have a little more time, watch the IBM video they have created for the occasion...

Day 2 Exhibiting at The Ada Connection

noreply@blogger.com (Objektum Solutions) — Wed, 26 Oct 2011 06:51:16 PDT

Day 2 for us at Ada Connection and there was a few more new faces, and after the ice-breaker whisky reception the night before, a more relaxed atmosphere. The talks focused on code generation in the morning and the people we spoke to in the coffee break were keen for the presentations to start.

As people started to filter back into the conference rooms, we had a rare sighting. The sun. Exactly what those in the marquee wanted. In the tropical exhibition area, we made use of the quiet periods by tapping away on our laptops until the sandwiches were laid out on the central table in the marquee and we were all immediately distracted. We ate our share before the masses arrived and were able to talk to people about training and software migration. We were on a roll and gave several presentations on the Legacy Bridge Suite. It’s not all about sales though; for us it’s also about using these opportunities to find out views and opinions of various technologies and markets. I had a great conversation with a University lecturer from the US about student attitudes to programming mission & saftey critical software and Ada. (This will form an entirely separate blog post!)

Lunch finished and we were on the final straight. The man of many hats, Ahlan Marriot, treasurer of Ada Europe and next year’s conference organiser, came to our stand to talk about next year’s conference in Stockholm, Sweden. “Would we be interested in being at the conference next year?” I think so I replied. It’s been a well organised and well attended conference and we’ve met some interesting people whom we hope to work with in the future. Ada is a specialism of Objektum Solutions and so we will continue to support mission and safety critical software development.

The second and last coffee break came and went with more discussions happening around the room. As the last delegate left, all the exhibitors dragged their boxes out from the behind the stands, pulled the plugs out and started to pack up their camps.

Our official duties as exhibitors had ended and after short power naps in front of the Wimbledon coverage, we grabbed our jackets and bags and made our way to the spectacular Signet Library in the centre of town. We turned in to Parliament Square and right on cue, we followed the piper’s bellowing tune to the entrance of this grand building.

Enclosed within the columns and walls of law books of the Lower Library, the Ada community delicately sipped on a glass of bubbly (thanks to AdaCore) and craned their necks to take in the splendour of the surroundings. A man with a big wooden hammer (I’m sure he has an official title) did his thing – namely hitting the hammer on another wooden object - to gather people's attention and he grandly called us into the Upper Library where dinner would be served. So, we made our way up the majestic staircase to the breath-taking setting of our banquet. Professor Les Hatton gave us an entertaining pre-dinner speech; one track of which was “Why programmers are monkeys?”. I am not a programmer myself but I work with many of them so I wish I had made notes to prove this theory when I return to the office on Friday.

I’ll quickly mention the starter, pea and mint soup, but the plate that stole the show was the haggis. Man carrying hammer (aka MC Hammer) did his bit and welcomed the haggis. We clapped the haggis in as it was accompanied by the piper and made its way to the front of the hall (on a tray, not on legs). Tom Anderson loudly broke into Scottish verse and we thought he’d gone mad. It unfolded that this was in fact Scottish tradition and Tony Elliston of Ellidiss Software pointed out that there were some “wee drams” of whisky at the front which would go to those who played a part in the Haggis performance that evening; the Piper, The Artist Formally Known as Tom, MC Hammer and the Haggis. The haggis had rave reviews that evening and one critic said of it, “It’s the best I’ve ever tasted”.

Main course of sea bass and desserts were laid down by the silver service staff and the speeches started. There was a tiny bit of chocolate torte left on my plate but the speeches were all entertaining enough to distract me from it for a short while. The colourful John Barnes stood on his seat and addressed the dinner guests with tales of Ada Europe from 20 years ago which celebrated a solicitor’s help to receive some money which was rightfully theirs. That solicitor, now a sheriff, was tracked down and invited to the dinner and gracefully received a round of applause and some flowers for her efforts all those years ago.

The clock struck 11.00pm and it was time for us to call it a night.

I conclude these posts from bonny Edinburgh, with a big thank you to all those involved with Ada Connection, both organisers and attendees, for making it an enjoyable and successful few days. It’s been great and as I am starting to feel a little weary, I wish I had asked the DHL chap who just picked up our stand to deliver me back to leafy Surrey too.

Day 1 Exhibiting at The Ada Connection

noreply@blogger.com (Objektum Solutions) — Wed, 26 Oct 2011 06:52:29 PDT

A speedy boarding (and disembarking) Ajay Patel and I stepped down off our easyJet flight in Edinburgh on Monday night ready for The Ada Connection the next day. The conference was already in full swing and the marquee (or tent for our American readers) was ready for the eager exhibitors to fill on the Tuesday and Wednesday.

Tuesday morning was an early rise and we headed to the John McIntyre Conference Centre on the city’s university campus. Thanks to the taxi driver’s directions, we had a brisk morning walk around the campus and made sure that the delivery entrances were in full working order before finding the correct entrance and a warm welcome from Joan Atkinson and Tom Anderson, from the University of Newcastle, the conference organisers.

Our stand was erected and the table adorned with data sheets, flyers and the like. Whilst we waited for the delegates to wander in for their morning coffee and pastries, we had a chance to chat to fellow exhibitors - LDRA, Resource Engineering Projects, IPL, Ellidiss Software, AdaCore, Rapita Systems, Verocel and Wind River to name a few.

The delegates filtered in and avoided us until they had their first hit of caffeine. Once they were all well-oiled, we were good to go and within 30 minutes had two companies interested in the Legacy Bridge Suite migration technology and asking for webinars. Legacy migration and obsolescence is a serious challenge facing most organisations and so there were plenty more cards swapped and details taken down throughout the rest of the day.

Lunch was in the student cafeteria but it could have well been a decent restaurant. As one observant exhibitor pointed out, the only give-away was the copious amount of baked beans available.

And then came the rain. Lots and lots of it. Being positioned in the marquee, a short dash from the main conference building and through the waterfall above the door, a couple of us were asking whether the delegates would venture outside or whether they would remain in the dryer foyer area leaving us out in the cold and all alone. A few, including myself, were asking if there were any more heaters were available… The organisers, Tom, Joan and Steve Riddle explored all the options with Edinburgh First, the venue’s conference team. A few options had to be discounted because of health and safety regulations (there were stairs we might throw ourselves down) but they persisted and kept us all informed. Meanwhile, at the four o’clock coffee break, the Ada community braved the elements for a couple of seconds and made it into the marquee, much to our appreciation and satisfaction. As the coffee break ended, it was decided that Ada developers were in fact made of strong stuff and we would stay put. I’m sure it would be a different story if we we’re exhibiting at the Miss World competition. Those who were cold found a spot inside and everyone was happy. I’m sure all the exhibitors would join me in thanking Joan and Tom for keeping everyone that way.

The thought of the whisky tasting session in the evening kept everyone warm as we waited for 6.15pm to approach when we were allowed to take the lids off the bottles and let the aromas drift amongst the crowd. Each of the exhibitors had a bottle of the finest Scotch whisky on their table and stacks of tasting cups. I was most relieved to have Highland Park as our resident whisky. Not because it is a perfectly balanced 18 year old single malt with a toffee sweetness and a mouth-wateringly smokey finish. I was happy because after a whole day and evening exhibiting, I didn’t fancy trying to pronounce Aberlour a’bunadh or Ardbeg Uigeadailthe. The whisky inevitably got everyone chatting and moving around the exhibition tasting what was on offer. I snuck off to have a quick look at the foyer area to see how that was going and when I came back a crowd had formed around our table. I thought Ajay must have pulled out the Legacy Bridge presentation and people had swarmed round to see this so called wizardy. As I approached the crowd, I realised that it wasn’t the Bridge that was dazzling the audience. It was Tucker Taft, one of the chief designers of the Ada language. It was 8.30pm and we knew we weren’t going to compete with Mr. Taft for attention so Ajay and I gathered our belongings and called it a day. And a successful day at that.

Use Case Based Project Estimation

noreply@blogger.com (Objektum Solutions) — Mon, 27 Jun 2011 03:16:45 PDT

We have looked at how to capture requirements with Use Cases, but once this is done, how do you progress with the project? Derek tells us in this post about the Karner's Use Case Points Method...

How long would this UML project take to develop?

As we have seen from our series of posts on use cases, they are an excellent way of capturing our user requirements. Before commencing development, it makes sense to estimate how long the development should take. It also makes sense to base that estimation on those use cases, given they are the requirements we are going to implement. There are several techniques we could use, but I would like to introduce you to the Karner method which was developed on 1993 by Gustav Karner. This method involves the studying of the system actors and use cases, weighting them according to complexity and then applying technical and environment factors. This process follows a number of steps:

1.       Weight the actors
2.       Weight the use cases
3.       Calculate the unadjusted use case points (UUCP)
4.       Determine the technical complexity factors
5.       Determine the environmental factors
6.       Calculate the Use Case Points (UCP)

1. Weight the Actors

The first step of the process is to analyse the complexity of your actors. The level of complexity is divided into 3 Actor Types:

Assign an actor type to each of your actors and then use the formula to calculate the total weighting

Σ(Number of each Actor type * Appropriate Factor)

Simple actor represents a separate entity which can be communicated with via an API. This means that interactions with the actor should be simple top implement. The multiplication factor for a simple actor is 1.

Average actors represent an entity which communicates by a defined protocol such as TCP/IP or RS232. This represents a more complicated interaction and thus the multiplication factor is 2.

Complex actors represent a person interacting with the system through a user interface. Obviously this interaction process is very complicated and therefore warrants the highest multiplication factor of 3.

Once you have weighted your actors you need to add up the total number of each actor type and then multiply the 3 totals by the appropriate multiplication factor. These values then need to be added together.

2. Weight the Use Cases

The next step is to analyse the complexity of your actors. The level of complexity is divided into 3 use case types:

Once you have weighted the actors we need to weight the use cases themselves. For each scenario in our use case we need to calculate the number of transactions. A transaction is described as the completion of a request from a primary actor by information being dispatched to all relevant supporting actors

Σ(Number of each use case type * Appropriate Factor)

3. Calculate the Unadjusted Use Case Points (UUCP)

Once the number of transactions for each use case has been determined, you should weight them as described in the above table. We then follow the same equation which was presented for the actor weighting.

Once we have this total we can calculate the unadjusted use case points (UUCP) by adding the two weighting totals together.

Unadjusted Use Case Points = Actor weighting + Use Case Weighting

4. Determine the Technical Complexity Factor

Now we need to determine the technical complexity of the project, this process involves us analysing each entry in the table and assigning a rating between (0-5) for each row.

Tfactor = Σ(Rating * Factor)

Now calculate the Technical Complexity Factor using the following formula:

TCF = 0.6 + (0.01 * TFactor)

5. Determine the Environmental Factor

We now need to consider the people working within our team. They will have different strengths and experiences. This factor is called the Environmental Factor (EF). To calculate the EF we follow a similar procedure to that discussed for the TCF. As before we have to analyse each entry in the table and assign a rating between (0-5) for each row.

A rating of 0 indicates that we have no experience in the field. A value of 5 means that we are experts in this area. Again, once you have justified your decisions you can multiply each element by its weighting factor. The summation of these values gives you the EFactor for your project:

Efactor = Σ(Rating * Appropriate Factor)

Now calculate the Environmental Factor using the following formula:

EF = 1.4 + (-0.03 * EFactor)

6. Calculate the Use Case Points (UCP)

Once you have calculated the 3 factor readings (UUCP, TCF and EF) we can multiply them together to give us the use case points (UCP) for our project.

UCP = UUCP * TCF * EF

We can use this value to estimate how long the project should take to develop. The Karner process suggests a value of 20 man hours per UCP for this estimation, so to estimate project duration use this formula:

Project man-hours = 20 * UCP

With experience, this figure can be refined, personally I believe people this figure should be increased when dealing with large teams as team cohesion becomes a bigger issue.

For a more accurate estimate you can add the number of environmental factors 1 to 6 that are above 3 to the number of factors in 7 and 8 that are below 3. If the total is 2 or less the figure of 20 hours is used. If the value is 3 or 4 a value of 28 should be used to calculate the project man hours.

Based on the above, I would be interested to hear what people think could be done to improve reduce a projects estimated cost?

We have developed a Use Case Estimation Tool to assist you in successfuly managing your projects.

Go to our website to find out how this could support you and your project...

Model Driven Software Modernization

noreply@blogger.com (Objektum Solutions) — Wed, 26 Oct 2011 07:48:29 PDT

We’ve created an innovative solution to Legacy Migration and we’re going to let you in on how the our model driven software modernization technology works…

He just learnt about the Bridge Technology...

With the ever growing need for organisations to develop robust software in a more rapid and cost effective manner; many projects are seeking ways to protect the investment in the existing software systems that are critical to the success of their projects. Over time external influences such as hardware, platform or skills obsolescence create a substantial risk to a company's on-going success. In addition, many legacy tools do not provide engineers with the ability to keep the design and implementation synchronised, which results in the code base deviating from the design, making the design obsolete.

Migration is a daunting task full of risk and projects are increasingly demanding solutions that can be deployed at a fraction of the cost of developing a new system from scratch and that reduce the risk.

We have employed and model driven approach and developed a suite of innovative migration solutions to address this growing need.

Using our intuitive rules based parser, which uses standard Backus Normal Form (BNF) notation, engineers can quickly and easily adapt our technology to analyse the syntax and semantics of any source model or legacy code. A meta model is then automatically constructed to provide an accurate representation of the source information which forms the basis on which any transformation can be performed.

Using our model to model (M2M) transformation technology the meta model is used to automatically produce a UML model in virtually any toolset. This approach provides the opportunity to refactor the legacy application as required by the needs of the business. Many modern UML tools provide the ability to generate customisable code. By automatically migrating the legacy application into UML a code generation strategy can now be adopted to leverage the benefits of modern programming languages.

If refactoring is not a project requirement then our unique model to text (M2T) transformation capability provides a direct path to language translation without the need for an external UML modelling tool.

Our revolutionary model driven approach to legacy migration provides several benefits:

Easily configurable analysis of legacy applications using a rules based parser
Elimination of human error inherent in manual migration strategies
Significant reduction in time and cost for new technology adoption
Removes dependency on legacy skills and tools
Reduction in future software maintenance costs
Mitigates obsolescence issues
100% automatic code generation

Our tried and tested approach has already been successfully deployed on several major pan-European safety and mission critical projects. When it comes to building bridges between legacy data and modern technologies we at Legacy believe that we are miles ahead of the competition and that’s why we’ve called our solution the Legacy Bridge Suite.

At Objektum we are committed to model driven development and so all of our products are 100% code generated from UML models as we believe that we have no right to promote a technology that we haven’t proven ourselves.

We will be running live demos of the Bridge technology from this month, so contact us to arrange one for you and your team...

Myths that give Model Driven Development a Bad Name

noreply@blogger.com (Objektum Solutions) — Thu, 26 May 2011 03:01:48 PDT

We are proud to introduce the first blog post from our new guest Blogger, Rafael Chaves, founder of Abstratt Technologies...

It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.

Model-driven development myths

Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.

Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).

Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.

Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.

Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.

What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?

Rafael has been writing code since he was in high school (20 yrs ago), and with time he discovered he was way more interested in how software was built than what the software actually did. For the last 8 years, he has been focusing on model-driven development, and as a result, he has built two products out of that: TextUML Toolkit, a UML modeling tool for Eclipse that uses a textual notation, and AlphaSimple, an online modeling environment that supports prototyping and code generation (currently in beta). Rafael is a keen blogger and also has a blog as he aims to stop people writing so much code... We collaborated because Objektum Solutions are also on this quest.

Adding Flesh to the Bones – Primary Scenarios

noreply@blogger.com (Objektum Solutions) — Wed, 25 May 2011 08:33:28 PDT

Alex, one of our Systems Engineering trainers, continues to share his wisdom in another post in his series on Use Cases.

Having defined the structure of the use case it is now time to describe the behaviours and interactions that occur during the execution of the use case; the flow of events if you like.

For this we will write use case scenarios to document the dialogue between the system and actors as the use case achieves its goal.

A scenario is an instance of a use case, i.e. it is one flow through the use case. Each use case will have many possible paths through. We first write an easy to understand description of a typical scenario in which the use case delivers the primary actors goal, i.e. the actor gets what he/she wants. This main scenario is frequently known as the primary scenario. All other paths through success and failure are described as extensions to the primary scenario, sometimes called alternate scenarios.

Let's bring in the ATM example.

Use case scenarios are normally captured using simple text. Each scenario captures a specific path through the use case in a single flow of events that contains no branching. There is one primary scenario and several alternate scenarios documenting all of the relevant success and failure cases.

It can be difficult to describe iterations, branching and/or concurrency using text, and therefore scenarios can be also described using sequence, state machine or activity diagrams. For now let us concentrate of the text.

Textual scenarios are written as a sequence of goal-achieving actions by the various actors. Each action step will describe one of the following:

An actor interaction - “Customer enters PIN”
A validation step - “System validate PIN code”
An internal change - “System deducts amount from balance”

There are a number of useful guidelines for use case scenario action steps:

Use simple grammar and vocabulary
Write everything in the same tense
Show clearly who is involved in each step
Write from a consistent perspective
Show the process moving forward
Show the actor’s intent not how he does it
Limit each scenario to between 3 and 11 action steps
Number each action step

As with all modelling your first draft is unlikely to represent the final incarnation of the primary scenario and may need to be modified once the alternate scenarios have been written. That, however, is a discussion for another day.

National Technology Day

noreply@blogger.com (Objektum Solutions) — Wed, 11 May 2011 09:46:58 PDT

It's National Technology Day in India today! Fiona takes a look at why this day is so important...

On May 11^th 1998 India set a precedent for the world of technology by declaring the date as the National Technology Day. The naming followed India’s rise on the international scene by becoming the sixth member of an elite group of countries in the ‘nuclear club’. The day is now celebrated annually across the country. In acknowledgment, an event is arranged by the Ministry of Science and Technology and includes a lecture session, a demonstration of new products released and a prestigious award ceremony which honours all those who have generated technological innovation. But how relevant is Technology Day is to the development of a country? And is technology important enough for other countries to adopt a similar celebration?

India’s rapid emergence onto the global economic market can be viewed in terms of their acceptance of technology as one of the fastest growing sectors, and a sector which we are all increasingly reliant upon. The growth in the IT industry over the past decade can be attributed to a highly skilled and motivated workforce. In particular, India has benefitted from Business Process Outsourcing. The Technology Day is celebrated as a symbol of the innate pursuit for scientific advancement and technological innovation and how this also leads to improvements in society and industry. It is without question that India recognised and seized the importance of technology resulting in the country becoming a major player in the global market.

So do we all need to take heed of this lesson and declare our own appreciation of technology? The importance of technology for all countries is evident by observing the most important challenge for the future, the green energy technology race. China is currently second in the world as a producer of green energy. The Chinese government recognised that investing in green technologies is very much the future in financial terms. They have become a mass producer of solar cells and wind turbines not only for their own internal use, but also to export to the international markets which are under increasing pressure to invest heavily in green technologies. The US and UK are now realising that they need to increase and renew efforts to capture some of the green energy technology race to resist being left behind by the market. The competition is about to accelerate and an acknowledgement of the importance of technology such as a celebration National Technology Day can only help with awareness of the importance of scientific creativity and productiveness.

At Objektum we have always embraced technological changes and we are continuingly looking for new ways to improve software development and plan to use our appreciation of technology to its full advantage. And why not celebrate it?!

The Truth of Motivation

noreply@blogger.com (Objektum Solutions) — Thu, 05 May 2011 07:56:17 PDT

Here's a video that we've been watching at Objektum Solutions HQ about motivation. We all found it fascinating (and fun to watch) and so we thought we'd share it with you. So, spare a little time to find out the truth about motivation...