Steve's Blog on Rational Requirements and Design
SteveArnold 270000T4JF Tags:  shoring off continuous agile outsourcing uml architecture delivery devoid 2,694 Visits
Well it's a new year, and what with the usual new year resolutions - getting fit, learning to play the guitar, and blogging regularly ! - I thought I'd also have a go at that other new year tradition - some technology predictions for 2013!!
As I'm a software engineer, they really come down to an optimistic, and somewhat biased view of some software development trends I've seen in 2012 that I hope will continue in 2013....so here they are:
Continuous deployment becomes common place - I think there is a perfect storm of desire to improve development-operations, improvements in virtualisation/cloud and in the software tools to enhance current build practices to make continuous deployment practical. So I'm looking forward to a year where this starts to become the norm rather than the exception.
Architecture comes back in fashion - a lot of organisations are struggling with agile, and in response to this I'm seeing a lot of teams turning back to doing more architecture and design. They are using the models in a very collaborative way - to communicate how the software works and seek improvements via colleagues' feedback, so that the software is as good as it can be. So 2013 will be the year when architecture cements itself into teams' agile practices.
Software development comes home - Is offshoring development really cheaper and faster? Well from what I've seen, a lot of organisations struggle to get a model that works - and they end up with a waterfall, highly contractual model, which doesn't deliver what they want in a timely fashion. So while there is definitely a place for global delivery and off shoring, it's not the panacea that some organisations thought. So in order to get better visibility, more agility I see more organisations reversing the off shoring trend and growing their software development capability in 2013.
Well my first experience of using jazz hub – was wow – that was easy J.
If you missed the announcement at innovate a few weeks ago, and are wondering what jazz hub is – then it's an open, free, RTC instance in the cloud, with a self-service management layer over the top for creating projects. So think github, but with RTC's planning and task management capabilities and a built in orion editor for coding in the web.
Anyway so after navigating to hub.jazz.net – I saw the launch page – with options to either create or search the open projects.
I provided the project name, I wanted to keep it public ( currently you can do private projects for free, however when jazz hub goes live - its currently in beta3- it will be a paid for service), and I chose to have scrum features added. Then I hit create project. This created my project area ,and dropped me straight into the project overview page- it couldn't be simpler.
From the project screen, I set up my iterations, added a task, and also found the invite to connect to the project from eclipse. So I quickly grabbed the invite, connected to jazz hub, and shared the Reqpro connector projects. Within 5 minutes of starting, I had my code stored in RTC on the cloud.
Once the code was up there I could access it either via my desktop eclipse editor, or through the web based orion editors.
And then finally - I found all the usual RTC goodness off the Track and Plan tab - where I found I can setup dashboards, plan and create work items and queries etc
So yes - my first experiences were really positive, and it seems really simple and easy to setup and get going.
Have you ever been on a software project and asked yourself "where has all the time gone" ? Often the reason why a project is late, is because of all the time being spent on stuff that doesn't help get to the end goal of a deployed system. On an average project some 70-80% of the time could be classified as waste (waiting, hand offs, extra processes, extra features, defects, motion, partially done work). So although automating tasks is a great thing to do, in order to deliver software faster you have to work out how to reduce the waste. For most projects a 20% reduction in waste is easier to achieve than a 20% increase in automation, and has a much bigger impact on when the project is delivered. If you're interested in understanding more about how IBM's collaborative lifecycle management tools can help, then Paula White and I have just published an article looking at how the tools can help with the various forms of software development waste.
SteveArnold 270000T4JF Tags:  collaboration uml modelling agile collaborative architecture 1,046 Visits
I'm an unashamed modelling fanatic - but in the last few years it's become a topic I'm almost afraid to mention. Why ? Well in the fad focused industry that is IT, modelling (with tools) has become deeply unfashionable. There has been a lot of misunderstanding about why modelling with tools is useful, not least because agile is often misinterpreted as anti-tool ( ofcourse it's not, you still use compilers, editors, src control, continuous integration tools etc). So where does modelling fit, in an iterative/agile world and why do I think it's starting to become popular again?
Well firstly, I tend to think of two broad uses of models -
Modelling for communication and collaboration, and modelling for specification (i.e. Code generation ). Now it's the former that is absolutely vital - even in agile/iterative development.
One of the benefits of agile is that you produce working software regularly - but while this guarantees that the code works, it's still the first version - like the draft of a document. So the question is how do you make the software as good as it can be - so that it delights users - rather than just satisfying a spec ? Well the answer, just like improving the first draft of a document , is that you need to communicate how the software will work, and then collaborate on that with your colleagues to improve it.
Obviously you could write the code, peer review it, and then change it - however this introduces rework and waste. So a better approach is to produce a high level model ( not a detailed specification )showing the key information, not too much detail, but enough information to enable someone to understand the high level approach and offer suggestions for improvement. This kind of modelling takes a few hours - so very possible in a short iteration project - yet still allows for others to comment and suggest improvements before the code is written - resulting in improved software that delights users.
"Im an agilist, and I do agile modelling on a whiteboard" I hear you cry. And if you're in a small colocated team this works perfectly, and exemplifies what I'm talking about. However in my experience, as teams scale and become distributed, they tend to forget about modelling altogether - rather than focusing on it more.
So why now ?? And why do I think modelling is coming back into fashion? Well according to Gartner agile is going though the valley of despair on the hype curve - and in my experience more and more organisations are starting to look at modelling as a possible approach to improve their software delivery.
Secondly the tools around modelling have improved significantly in recent years, transforming modelling tools from single user desktop tools, to collaborative team tools. This is vital as it simplifies modelling as a team, reviewing and commenting - making it possible for this to be very lean and to minimise waste.
So perhaps modelling isn't such an anachronism after all. And given the current trends towards distributing agile, then modelling for collaboration will, I think, become critical for successful projects.
Great news, we’ve beaten Visual Studio overall in the Evan’s user satisfaction survey, and we came out as best in application modeling, requirements management, quality of technical support, support for remote development, frameworks, and breadth of language support.Check out the article in computer weekly here
SteveArnold 270000T4JF 741 Visits
Ok so I'm biased - as I wrote the code!! For the last two years I've been pestering the RAD development team to build a RTC advisor for code coverage - so that you can prevent deliveries if the code coverage of the files being delivered is not sufficient. So back in december I built a prototype, which the RAD team really liked - however didn't have time to develop it further. So after a few evenings and weekends, I beefed up the code, and its just been released as part of RAD 8.0.3 !!
Its a pretty simple feature- when you switch it on, and try and deliver code, it checks that the coverage information is up to date, and that the coverage of the files you are delivering exceeds the levels you've specified in the process configuration.
Some of the motivation is two fold - it helps good agile teams maintain their code coverage and unit testing levels with gentle reminders about running their tests and getting the required coverage, and for other teams it provides a mechanism for incrementally improving their unit testing and code coeverage. i.e. for a project with poor levels of coverage and unit testing, you can incrementally improve it as you modify the code - so the modified code will have good levels of testing, and the overally quality of the code and tests will improve over time.
So hopefully this integration will provide something for everyone - for good agile teams it will help them maintain their existing level, and for other teams it will support them in creating some incremental improvements.You can see the other details of whats new in 8.0.3 here
SteveArnold 270000T4JF Tags:  rsa software architect system ea architecture enterprise 725 Visits
Historically, many organizations develop enterprise and software architectures in isolation from each other, or they try to reconcile them manually. This isolation causes several problems:
By using IBM® Rational® Jazz™ technology (see jazz.net), it is now possible to link elements in an enterprise architecture stored in IBM® Rational® System Architect with model elements stored in IBM® Rational® Software Architect extension for Design Management (sometimes called Design Manager). This capability has several benefits:
If you'd like to see how to set it up - then I recently wrote a developerworks article with Jas Atwal - which walks through the steps, and also shows some of the analysis you can perform once it is set up. The article can be found here.
SteveArnold 270000T4JF 554 Visits
When I first heard about collaboration for development teams it seemed to have very soft benefits, and was hard to quantify. But I've been thinking about it in the context of lean, and realized collaboration is critical to improving a development process - and collaborative tools may well be the key to unlocking that improvement.
When you think about software development in terms of a lean process, then an average team will have a process efficiency of about 20% ( i.e. only 20% of the time taken to deliver a feature is spent on useful work or another way of thinking about this - 80% of the time is wasted in waiting and hand offs).
So when you start applying tooling to this environment you have to ask yourself what is going to give you the biggest improvement - either automating tasks for the individual practitioner, or trying to tackle the waste and hand offs ?
Just looking at the numbers, it's obvious you're going to get less return by focusing on tools that just help individual productivity e.g. If you implemented a set of non-integrated tools which boosted individual productivity by 20%, then the piece of work which was taking 100 days is now taking 96 (you still have 80 days waste, and you've reduced the 20 days to 16). Contrast this with tooling and process changes which focused on the hand offs and waste, and which reduced that by 20%, and that 100 day task is now taking 84 days instead ( you're still doing 20 days work, but you've reduced the waste to 64 days).
The diagram below gives a view of what happens when you dramatically reduce the non-productive time – naturally the time to market/ development time is dramatically reduced too.
Now in reality you obviously want to automate more (to reduce the time taken to do the work), and also collaborate more to reduce the waste and hand offs. But these numbers make it apparent why collaboration is so critical - to make a significant impact on your process efficiency and delivery time, you have to really tackle the hand offs and other sources of waste - and collaborative, integrated tools are what help you and your team to do that.
If you're interested in how IBM Rational's tools can help - then you might be interested in this article I wrote a couple of years ago http://ibm.co/steve_lean.