I’m taking a few weeks off, so I’m in holiday mode enjoying the sun and reducing my time in a dark room of computers, but although I won’t be doing many experiments I had it in mind that one job I should do is to review my list of candidate experiments ready for me return.
Every time I look at my list (infrequently), I get a sense that there is so much in EA and however much I explore there will always be more. I guess this is no surprise as the tool evolves to meet users needs faster than I can explore, so my candidate list is just a guide to some of the areas I could explore when I next get idle.
I would guess that there are 3 hot topics:
- Scripting _ If I look back over the last 6 months I’ve spend at lot of time looking at scripting. And judging by what seems to me an increasing number of queries on scripting on the Sparx automation forum I guess this could be considered a hot topic.
- AddIns – There continues to be a steady stream of issues with AddIns and from the questions raised indicate more people are developing their own AddIns (my advert – we can help with AddIn developments!) as well as more being added to Sparx own list.
- Documentation and reporting – I have noted an increasing number of questions relating to producing documentation/reports in a variety of formats.
How accurate my observations is unclear so I may have missed a major topic; it would be interesting if there were statistics available (Sparx are there?). What do you think I have missed?
Some of the topics that I don’t see much (or I’ve just missed) that were on my list are:
- Application development
- Model transformations
Perhaps that’s because those using fully understand.
What else for my list?
In starting to review my candidate list what came to mind was a post on the Sparx forum on testing AddIns last week. It prompted me to think about what we use EA for?
We know that EA could be used throughout the development cycle whether modelling, analysis, design, coding, testing and maintenance. (I could possibly add project management but I guess that this will be a small number of users, not least based on the level of interest we have received for our MS Project and TeamPulse AddIns!)
From my experience the majority of users fall into the first 3 categories – modelling, analysis and design. I think this observation is further supported by the topics covered at EA user Group meetings I have attended. Yes, there are a few well documented exceptions such as embedded code development but not much else.
Does this mean that like other tools I can think of such as Microsoft Word, EA is positioned by a few key features, and even though it continues to evolve the major use remains the same. If we think about Word most users only use a small number of the product features; there are power users who can demonstrate some amazing stuff that can be done, however this requires awareness and knowledge of how to perform the task, and all too often users don’t go looking. It was this thinking that was part of the reasoning behind EXploringEA, the opportunity to go where others have not gone before…
So are there parts of EA that we are failing to use that could make our developments easier? better? quicker? cleaner? more maintainable? ….
It was the post on testing AddIns that reminded me that one of my goals with EXploringEA was to be able to fully understand the viability of managing the whole software lifecycle from product concept to its ongoing maintenance within EA. I had a vision that one tool containing the “knowledge” would help the overall process and its management.
Yes, there will be a need to call other tools – compilers, linkers, database tools, documentation tools … but no major distraction and if EA could truly be the kingpin to manage our world, would our developments be better? or am I just trying to push all into a “box” which is just not the right size for the problem in hand? And if there are too many other tools with which we need to interact are we just complicating the process?
So is my desire to manage and orchestrate the development in a clear and clean way getting in the way of a realistic development process? I hold my hand up and say I don’t use EA for the majority of my coding but somehow wish I could, and maintenance that’s another story.
So imagine that EA were the primary tool for our developments, with a few associated specialist programmes to do the detail, how would each of us feel whether we be business analysts, project managers, developers, coders, testers, supporters?
This approach raises a lot of issues, but for the moment here are a few questions:
- Is EA only suitable for the modelling, analysis, design?
- Is it sufficient and able to perform these tasks?
- Is it viable to use EA in other areas such coding, testing, maintenance and if so what reliance is there on other tools? (Just seen the draft agenda for the EA User group meeting in London – with a talk on using EA for Full Project Lifecycle, which could shed some more light on this)
- Can we use it to produce all the documentation that we need, not only for our up front design activities but documents that meet the needs of testers, supporters and maintainers?
- In what areas are there are good case studies? (I need to look out for some, and if you have one let me know if I can add a link to it to help others?)
- What additional tools are needed to support general purpose windows development?
- And always – what questions should I be asking and I haven’t?
I also mustn’t forget to ask again – what are the hot EA topics?
I hope that is thought provoking – it has got me thinking – but then with the sun on the terrace …
I’ll be back soon.