Stakeholders Don’t Just Kill Vampires – Sometimes They Talk

Alex continues to blog valuable insights into the art of capturing requirements...

Typically requirements analysis begins with some sort of user requirement document (URD) and often engineers consider this to be the only source of input. In modern development, however, customers are producing fewer requirements but, instead, becoming more capability driven. What this means is that, rather than identify a long list of “The system shall…” statements, customers are identifying gaps within their capabilities and asking industry to propose an appropriate solution. In order to effectively handle this absence of a URD it is vital that engineers take the time to identify and investigate the needs of the system stakeholders.

 So what is a stakeholder? As my title suggests, in this context, it is not Buffy the Vampire Slayer; nor is it the waiter at your favourite restaurant. A stakeholder represents anyone who has an interest in the system for some part of its development or operation. The obvious stakeholders are those who are paying for its development and those who need to use the system but is that where it ends? What about internal stakeholders? I know that whenever I develop anything that Derek looms over my shoulder wanting to know if the deadline will be met and whether I’ve blown the budget or not (naturally I never do). As a requirements engineer I have to take into account, not only those whom the final product will be delivered to but also those who will take my work and further the development; designers, implementers, testers – they are also my customers.

Successful development is based on good communication. Regardless of how your system functions, the project has failed if it doesn’t meet the needs of your stakeholders and the only way to guarantee that it will is to involve them in the development process all the way through. Learning how to ask the right questions is as important a development skill as understanding the technology on which the system is going to be based.

Alex

Progress with Strategic Alliances

Cat writes about how we can achieve more through Strategic Alliances...

The world is making such technological advancements it is sometimes hard to comprehend, never mind keep up. How do technology companies do it? Are employees akin to elves and work all hours of the day and night to create this high-technology magic? Quite possibly. But more commonly, technology companies are forming strategic alliances to not just stay ahead but lead the way.

Strategic alliances are all about the collaboration of companies, or even individual people, with complimentary resources and capabilities to achieve, together, more than they could separately. It is important that the relationships formed are in line with an organisation’s own strategy and direction and the potential benefits are huge. Market entry, risk sharing and expenses are among such benefits. In terms of innovation, the shared expertise, with each organisation bringing different skills and ideas to the table, is where the most extraordinary shifts can be made by strategic alliances.

We have focused on creating strategic alliances this year and the results have been greater than any of us could have imagined. The key is to find the mutual opportunities and create win-win situations. The parties are then dedicated to the relationship and working together to push the boundaries. It is important to keep pushing forward too.

Meetings are not meant to get longer nor the decisions slower. Strategic alliances are about being fast thinking and rapid moving to be innovative and gain competitive advantage. It is about setting the standard, the creation of new ideas and leading the way. The approach particularly suits fast growing companies but long established companies, such as Toshiba, often have a company culture of collaboration that has proved sustainable.  

Toshiba‘s main business is infrastructure, consumer products, electronic devices and components. They firmly believe that a company cannot achieve everything by itself. Their approach is to develop relationships with partners who have different technologies. For example, they formed a relationship with Apple to develop multimedia computer products. Whilst Apple’s strength lay in software technology, Toshiba had a great deal of manufacturing expertise. Interestingly, even on a local level in Japan, Toshiba is a part of group of companies whom all have interlocking business relationships and shareholdings. This set up became incredibly common in Japan post World War II and is known as a keiretsu.

Whilst the true keiretsu model hasn’t appeared outside Japan, many non-Japanese businesses are described as keiretsu such as the Virgin Group, Tata Group and Cisco Systems. These companies are always associated with innovation, breaking boundaries, and prosperity. And I’m sure Mr Branson doesn’t employ little elves to achieve all that success. 

Cat

Putting the System in its Place – Context Diagrams

Alex continues discussing capturing requirements, this week looking at Context Diagrams and how they can help us understand the environment in which the system under development can operate... 

Although not strictly related to use cases, which I have previously stated as the theme of my series and upcoming posts, the development of a context diagram is an excellent first step in understanding the environment in which the system under development (SUD) will operate.

While some might consider this an unnecessary step in development I find that the development of a separate context diagram has two major benefits. Firstly it allows you to model elements which do not directly interact with you system but indirectly affect it and secondly it allows you to consider different system usages.

With regard to the former you might ask “why would I want to model things that don’t directly affect my system?” Take, as an example, the command and control (C²) for a complex weapon system (credit must be given here to my colleagues who worked with me to develop the example I am using – I’d tell you who they were but then I’d have to kill you). On a use case diagram you would represent things that directly interact with you system but at no point does your C² directly engage the target, it is the weapon itself that does that and it would be illegal UML or SysML if you modelled the interactions between the weapon and the target as it is out of scope. Not modelling this, however, does not accurately represent the system purpose as you end up with a model that explains what your system does but not why. A context diagram showing the larger scope of system usage is the perfect place to communicate this.

In my title I refer to context diagrams (plural) and have done so deliberately. A good system (or software) model considers more that the, obvious, operational context. There are many other points of view to be considered; as an example I cite the defence lines of development (for the purposes of not defence developers I have attempted to demilitarise them – the MoD definitions can be found at http://www.aof.mod.uk/aofcontent/strategic/guide/sg_dlod.htm):

•  Training - the provision of the means to practise, develop and validate, within constraints, the practical application of a capability.
• Equipment - the provision of platforms and systems needed to outfit an individual, group or organisation.
•  Personnel - the timely provision of sufficient, capable and motivated personnel to deliver outputs.
• Information - the provision of a coherent development of data, information and knowledge requirements for capabilities and all processes designed to gather and handle them.
• Concepts and Doctrine - a concept is an expression of the capabilities that are likely to be used to accomplish an activity in the future. Doctrine is an expression of the principles which guide actions and is a codification of how activity is conducted today.
• Organisation - the organisational relationships of people.
• Infrastructure - the acquisition, development, management and disposal of all fixed, permanent structures in support of the required capabilities.
• Logistics - the science of planning and carrying out the operational movement and maintenance.

Remember that your first attempt at context modelling is likely to be based on a limited understanding of the system and is therefore merely a starting point. Further analysis of the requirements will result in a refining of the system boundary and is likely to cause the context to change. As with all good development, producing a system context is an iterative activity.

Alex

Timeboxing

 Fiona, who has to manage her time incredibly well as Product Delivery Manager at Objektum Solutions introduces the concept of Timeboxing...

Everyone is familiar with the phrase “so much to do, so little time”.  In today’s busy world we are trying to balance multiple lifestyles, wishes and aspirations.  As people of the 21^st century we are always looking for ways of managing our time more productively. The workplace has especially become more demanding with shorter deadlines and increased workloads. We’ve all experienced that feeling of being completely overwhelmed by the sheer volume of work and effort needed to complete a task. 

One technique available to us is timeboxing. I first learnt of timeboxing at a University lecture discussing effective time management for our upcoming final year. I later studied timeboxing in terms of software development and its usefulness in delivering iterative and incremental system designs. Timeboxing necessitates that schedule deadlines determine the project features. Put simply, falling behind on the programme is not an option. 

Timeboxing means allowing yourself a limited amount of time to complete a task and ensuring that under no circumstance will you go over this time. We can use timeboxing effectively in our everyday lives. For example, you need to buy a present for your mother-in-law and you know that this could lead to a great deal of procrastination with little to show for it. Instead, allow 30 minutes to find the perfect gift and commit to putting in the effort to achieve this goal. 

 Timeboxing is an equally useful technique to use on a project. In fact, I stuck religiously to my timeboxing schedule during my final year project at university. I also had a great motivation technique to use when feeling lost under piles of notes and diagrams and not really knowing where to begin to tackle the task ahead. Just 30 minutes of allocated time to embark upon a particularly difficult task can really make a difference to the completion deadline of the project. 

Here is my list of why timeboxing really works:

• It makes a project less off-putting as the content is reduced down to realistic goals
• It assists in determining what is actually achievable in a task or project
• Timeboxing eliminates procrastination which swallows so much of our time   
• It facilitates incremental software development reduces the risk associated with large scale system development 

With the help of time management techniques like this we’ll soon find ourselves saying “So much time, and so little to do”.

Fiona 

The Path of Most Resistance - Discovering Use Cases

Systems and Software Lecturer Alex starts to teach us a thing or two about use cases in his second post in the series on Use Case Diagrams...

Having recently ranted (OK so rant might be a bit strong but it’s a favourite word of mine) on the inappropriate application of use cases it seems to me that I should, at the very least, offer an opinion (not that I’m opinionated, just ask my colleagues) on how they should be written.

  As a subject that is considerably more involved that the UML notation implies, as well as being one that is close to my heart, I hope I will be forgiven if I make this a series of posts rather than trying to tackle the subject in a single monologue. The effect of such an attempt would undoubtedly spiral out of control and be likely to require a publishing agent.

Many years ago our Technical Director, Derek, introduced me to use cases as an analysis technique. After listening to everything he had to say I, like the petulant child I was, set out to prove I could do it better. Though I didn’t realise it at the time, I was well on my way to making the first of many mistakes that I now try to guide people around.

Using an example that we had for one of our training courses I set out to improve the use cases I was given, smugly believing that something had been overlooked. Over the years I refined and remodelled until, eventually, I ended up with a use case model that was so close to the one I had inherited that it was almost impossible to tell the difference. It’s been several years since that moment but I’m still reeling from the blow to my ego.

   

Writing good use cases is an art; no-one can teach it to you. That might sound strange coming from someone who makes a living teaching people how to write use but it’s a fact. People can give you the benefit of their experience in use case development and provide you will a solid foundation but, like I did, you will discover that this is only the beginning of the journey. Good use cases are written by those who are humble enough to accept the guidance of those who already undergone a journey of retraining their analysis paradigm.

 

In the coming weeks I would like to present an approach to use case modelling that is not my own but rather the distilled wisdom of everyone I have learned from.

Alex 

Make sure you subscribe to our blog (on the right hand side) so that you can read Alex's next post in this series...

How to Market A Technical Company (and Be Taken Seriously)

Cat, who works on the strategy and communications of Objektum Solutions, gives us a refreshing look on how to market within the technical world...

Over the last few years I have been working with technical experts and something I have noticed is that there is often a misconception of ‘Marketing’. In a world of models and code, I understand that marketing can sometimes look a little “fluffy”. Whilst ‘Social Media’ has opened up avenues for millions of people across the globe, the jovial nature of a lot of the tools hasn’t helped marketing folk to be taken seriously. Let’s face it, Twitter ain’t mission-critical.  

Whilst working on the marketing of the company, I’ve been talking to colleagues about what we’re doing and why we’re doing it. Everyone who works here is intelligent but sometimes it is not easy for them to see why we’re doing something that doesn’t produce a tangible (or even measurable) output.

So, over the years I’ve explained elements of marketing to the team and vice versa, they have helped me by explaining the technology behind it all. Understanding marketing as a function is important even if you’re not directly involved. The team here have found it interesting (they say that anyway, but that might also be to shut me up!) and so I’ll be occasionally blogging marketing ‘bites’ for you, such as this....

How to Market a Technical Company (and be taken seriously)

Marketing is about telling a targeted market what you have to offer and why they should come to you to solve their problem. It’s finding the customers and then, when you’re front of them, what is it that you say. Here are some pointers:

1. Plan and measure – marketing isn’t just about writing fancy words and pretty pictures. As with any strategy or project, there must be objectives and although it’s hard, one needs to measure return on investment. Planning is of prime importance so that you can be consistent with your message.

2. Be consistent – all the best brands in the world are kept visible and consistent. This is the message, the tone, the way you interact with customers etc. Customers will only get to really know and trust you when you have a consistent image. They will also remember you.

3. Relevance – keep your message relevant. Know your audience and whilst your key points should remain the same, your message needs to address the concerns and areas of interest of those who you are communicating to.

4. Be concise – one of the paradoxes of our age is that there is more clutter and less time to sift through it. People will be eternally grateful if you can keep to the point.

5. #don’tjustfollowtrendsforthesakeofit – for those of you not on Twitter, this may look like my keyboard has malfunctioned but, as with my last point on consistency, think about how your message is being carried across and what the perception of your company is. If Twitter, Facebook, Ning (the list goes on) doesn’t fit in with your company, leave it. Don’t do it because everyone else is doing it; do it because it works for you and your customers. LinkedIn works well for us because of the forums and the business focus, so that’s what we use.

 

6. Product Demos – now this is something we’re working on at the moment. We frequently do webinars but we have all this brilliant technology, but can anyone see what it does by looking at our website? No. Do they have to read paragraphs and paragraphs of text to work out what it does? Yes. Make sure your work is showcased so people can see how you can solve their problems.

7. Show off a little - respect your client’s privacy but show off your successes with case studies. Case studies have a beginning, The Problem; a middle, The Solution and an end, The Result. It is such a simple formula but it is one of the most effective ways to show what you can do.

8. Remember, it’s not all online - get out there and meet people. Now, I’m not the biggest fan of the ‘elevator pitch’. I’ve attended so many networking sessions where I have heard too many pitches that I just switch off. Have a clear understanding of what you do but most importantly listen and have interesting conversations.

9. Collaborate – work with partners, suppliers and customers to achieve more than you can could if you were all working in isolation. 

10. Practice what you preach – you can come up with the best marketing strategy, the greatest website and the slickest tag line but if you don’t deliver what you promise, that’s the message that will spread and the marketing really does all turn into fluff. 

 Cat

Use (less) Cases

Alex travels around the world teaching organisations about creating systems and how to use Use Case diagrams effectively. A huge percentage of people are sceptical about Use Case Diagrams but in this new series of posts he is going to be teaching us how to use them to make a difference in our work...

I love use cases. I love teaching them, writing them; in fact I love everything about use cases, well almost. What I really don’t like about use cases is the frequent way in which they are poorly introduced into an organisation. 

At Objektum Solutions we talk about the “use case hoax”; the fact that many people focus on the “stick men and bubbles” while failing to understand the underlying concepts of use case development. For us use cases are not about the notation but about the thought processes that are employed in their development.

One of the problems that I often encounter is the inability of engineers (particularly those who have spent years at the detailed design or implementation level) to abstract their thinking in order to express how the systems they develop will be used in the real world. All too often I find use cases that are developed purely to “tick” the relevant boxes and therefore add little or no value.

As with any new technique (and by new I am speaking from the relevant point of view of the deploying organisation as use cases have become an old friend to many of us), careful consideration has to be given to how to introduce use case driven development.

In order to successfully apply use case modelling to a project, engineers must first be taught why they are doing it and what the expected result is. For me use cases offer more than just an understanding of how the system under development will be used. They are a means of discovering what questions need to be asked of the stakeholders in order to ensure that a project is suitably equipped to move the development effort forward.

Over the years I have taught many aspects of software and systems engineering but there’s still nothing more gratifying that the look, at the end of a use case course, which clearly says “wow, I never realised how powerful this technique is”.

As a consultant it is my job to teach people modelling languages but as an engineer it is my mission to teach people how to model.

Alex

The Evolution of Code Generation

Derek, our Technical Director, has been working in software development over the last 25 years and set up Objektum Solutions over 10 years ago. He reflects in our latest post about whether we have learnt from the past with regards to code generation...

 When I started my software career, it was common place to develop code in low level assembler languages such as Z80, 6502, 68000 etc.  We had little or no design methods, development tools or strict processes to follow. Ensuring we met even what requirements we did have, was difficult and code reviewing was a labour intensive task that often resulting in a “ticking the box” exercise?  

I remember working for a company that introduced Ada83 for the first time and being involved with the compiler vendors, helping to pick the bugs out by looking at the assembler being generated.   I remember people saying “I don’t trust this code generation” way of doing things; that seems so long ago nowadays we trust the compiler put in front of us.

As software systems become even more complex, there is an increasing need to find alternative development techniques compared to the traditional low level methods and high level programming languages we have become used to.  This is necessary to ensure we maintain quality, adhere to requirements, increase productivity and do not increase the workload of project managers. 

Model Driven Development

Model Driven Development (MDD) is the next step of abstraction in writing software applications which are traditionally written in programming languages such as Ada, C++ and Java.   If we look back in the history of software development, we will find that each higher level of abstraction adopted has offered improved productivity and ease-of-writing complex applications i.e. moving from assembler to high-level programming languages.

MDD focuses on creating models, or abstractions, more closely related to domain concepts rather than computing (or algorithmic) concepts.  Typically models are constructed to a certain level of detail, and then code is crafted (even sometimes by hand!).  With the introduction of the Unified Modelling Language (UML), MDD has become very popular today within many industry sections such as Telecommunications, Finance, Defence etc. and there are now a wide variety of practitioners, supporting tools and processes.

• The advantages of MDD include:
• Improved communication of the design(including to the customer)
• Increased understanding of design elements
• Enhancing the consistency between design and code
• Traceability within the software design
• Increased productivity through efficiency 

Code can be generated from the models, ranging from system skeletons to complete, deployable products.  However, I am experiencing déjà-vu. Once again I can hear people say “I don’t trust this code generation”.  I wonder if in ten years we will simple trust the code generators put in front of us.

I have been working with UML for the last 10 years and in the subject of code generation and reverse engineering intensively for the last 5 years, and I’m looking forward to writing my next post and sharing my experience in developing reverse and roundtrip engineering tools. 

Derek

The Long Term Consequences of Short Term Solutions

In the first official post of our new blog, Alex, one of our Systems and Software Engineering Consultants and Lecturers steps up to the mic to share thoughts he had after going to IBM Rational's Innovation 2010 event... 

Shows and exhibitions form part of any industry so it’s hardly surprising that the software and systems engineering community has so many of them. I’m not usually a fan of these events which seem to involve an excessive amount of currying favour and flogging products – which really isn’t my style. 

Once in a while, however, I find a reason to attend a show and am pleasantly surprised by the outcome. It was to see a presentation, by a customer that I’ve been working closely with, that I attended IBM Rational’s Innovation 2010. I was interested to see how he would present the work we’ve been doing in applying a model based approach to systems engineering (a subject of intense interest to me at the moment). 

As expected, the presentation was both entertaining and informative; to the point where I felt compelled to restrain myself from adding the occasional joking heckle from the front row (something I’d been light-heartedly threatening all morning). Even when the presentation glossed over some challenges in the chosen methodology (something that we’re still working out with the client) I kept mum although I did comment on my observations during the team ‘post mortem’.

It was during that discussion that we were approached by a software engineer who wanted to learn more about how we had overcome the challenges of introducing modelling within the company. It transpired that the company of said software engineer had introduced object oriented software development and had invested money into a tool without providing any process, methodology or training in the use of UML modelling. Naturally this approach was not as successful as was hoped and they were starting to doubt the approach.   Having invested considerable personal time and resources to training himself, the engineer in question was bordering on becoming distraught, fearing that his company would see OO as inappropriate and that he would be trapped in a world of functional decomposition for the rest of his career.

When asked my opinion on how to prevent a failure to move forwards I was reminded of the Agile Manifesto which states, as one of its tenants, “we value individuals and interactions over processes and tools”.  It has made me wonder how many other organisations believe that throwing money or technology at a problem is a magical cure all and fail to understand that it is investment in training and the correct application of methodology that is the key to success.

In this era of economic uncertainty and cut backs it is easy to understand how people adopt a quick fix approach to problems but someone has to spread the word that investing in improvement now will reap rewards in the long term.

Alex

Permission to Launch

Cat, who looks after all our marketing, kicks off the blog with our first post...

 Firstly, I have a confession to make. I am the least technical person in Objektum Solutions. To give you a gauge on this, I got overly excited the other day when I was able to map a network drive to my computer without having to call out pathetically for one of the team to help.  So yes, it is a little strange that I should be writing the first post in The Technical Diaries, but whilst the rest of the team are coming up with ground-breaking, never-done-before, problem-solving technology and solutions that make clients say (and I quote, verbatim) “It’s like all my dreams have come true”, I look after the communications for Objektum. 

Now, over the last month our internal communications have gone pretty much like this:

Cat, “Derek, you need to get involved with this discussion on LinkedIn, its right up your street”

Derek, “Yes, alright, I’ll do it later.”

Cat, “You said that last time I asked. Do it now.”

Please don’t feel sorry for Derek. I’ve been picking on everyone.  Slowly but surely, everyone has started to see the value of LinkedIn. As much as I was excited about mapping that network drive, whenever somebody now uses the word “connecting” in the office they look over at me and smile as if to say “Get me talking this marketing lingo!” 

It wasn’t easy to explain to a group of very practical people that we needed to be “spreading the message” and you can imagine the blank expressions when I mentioned “thought leadership”. But there was a turning point that shocked me to my very core. After a training session we had on Search Engine Optimisation and Marketing, Alex and Derek turned round to me and both said in perfect harmony “I think we should start blogging”.  I asked them whether they would actually write the posts. They said yes. I asked them whether they would be committed to writing interesting content even if they were really, really busy. They said yes. I asked them if they would resent me nagging them about it. They smiled. This is obviously yet to be discovered but I’ll let you know... 

As indicated in the name of the blog, The Technical Diaries, this will be a collection of posts and stories for those in the technical world. I’ll try to make sure that it is not too dry and it will cover a wide variety of topics including more human factors.  If you subscribe to our RSS Feed you’ll be able to see when there’s something new to read and comments and suggestions are most welcome. 

Thank you for reading the blog thus far. 

Cat