Baron QA

Feed Rss

I’ve noticed that a good way to get (almost) all requirements for a software in one place is to create a mind map about every possible thing what the system needs to do or with what it has to function with. Throwing up all user groups, special cases, integrations and workflows without any pre-determined structure often end up to hold the necessary information required to start working with the actual technical requirements.

When people are not forced to put requirements under certain topics, all the little things get noticed. Don’t have a good group where your idea belongs to? Just create a new one! Completely new ways of working can also be found when ideas can be thrown into the mix without limitations.

After the map is finished, it needs to be properly checked with a smaller group of experts and valid issues are transferred into more readable form (including UML drawings etc.). All “doubles” are removed and issues are categorized logically. After this, the actual work can begin!

Voilá!

Share on TwitterShare on TumblrSave on DeliciousDigg ThisSubmit to redditShare via email

While looking out of the window in Tampere, one might argue it’s not exactly “spring” yet. Still I think this is a good title for quite important issue. I’m currently working with converting a lot of data from a legacy systems into a brand new system and I’m facing the inevitable with all the data stored in the old system that doesn’t exactly fit into the new one.

Job is actually not so terrible, since the difference between storable data was already looked into when designing the new system. For some reason, old systems start to get cluttered like your closets at home. All unnecessary stuff is piled up into the database “in case we need it around year 20xx”. Truth is, it’s rarely – if ever – used. It’s not used as KPI data, job follow-up or for legal reasons. It’s there becouse some part of business once thought that it would be great to store additional information.

Even though new system was stripped of many data columns, I find even more data during the conversion phase that business does not actually need. People can work with less if it’s wisely thought over in advance. More important is to get the really important stuff availble for anyone who needs it.

In life, biggest piles of unncessary stuff are usually found when moving from one apartment to another (I’ve done it ~15 times). I see the same pattern here when changing from old system to a new one. It’s about taking the decision to throw away that extra stuff and getting a fresh start in the new system.

Share on TwitterShare on TumblrSave on DeliciousDigg ThisSubmit to redditShare via email

Nokia has set up a competion where one could win a Lumia 800 by reviewing WRC Live app. I’m all in if I can get some cool stuff for free, so here’s my review with an extra focus on usability.

Before we begin, I should make one point clear: I’m trying the app out with my E6, which hasn’t been playing so nicely with some Symbian^3 apps because of its resolution (Spotify, for example, has big problems). For this reason, my review might not give full picture of the app if you are trying it out for example with E7. I’m also not so big fan of this rally thing, but hopefully that doesn’t matter :) .

Performance & interface

Starting up the app takes a while, but once it’s running, it works quite smoothly. Only actual loading takes place when app is getting new data from servers. This could use some kind of “loading” notification on the screen (there actually is a small icon on the top-right, but not very clear), since now user only looks at half-empty screen until all data has been loaded in the background.

Navigation is simple and even with E6 you can hit the buttons quite well. There is a lot of rally related content which most likely will be very facinating for a fan, but for me it’s just easy to read.

Media playback

Trying to load a video using 3G didn’t work during my test. I got server timeout no matter what video I tried to load. So for this, I can’t give any kind of opinion other than Nokia should probably invest some more into server capacity :) .

Loading photos does work quite well. I would have liked to have a map pointing to exact locations where the pics have been taken. Maybe in the next version?

“Easter eggs”

While loading the special stages map for the first time, map is focused to Vattuniemenranta (Helsinki), where app developer Futirce has its head office.

Conclusion

Overall, the app is quite well made. It’s very good looking and works fast. If only the video content would work, this would be an excellent piece of software for the rally fans out there. It runs very well even on E6!

Share on TwitterShare on TumblrSave on DeliciousDigg ThisSubmit to redditShare via email

Christmas is now out of the way, so I have time to write again :) .

I’m currently in the middle of doing a lot of technical documentation and it made me start to think of different approaches on the subject. In Scrum (well, all agile models), documentation is considered to be less important than working software – which I totally agree. However, having good enough documentation is essential to maintain and develop the product after it’s release.

Documenting just bare minimum of the system – describing only in general how it works – is the least feasible option. This is good if anyone outside the development project group would like to have an overview what the product actally is, but for the future developers (maybe totally inexperienced with this specific product) it places a lot of challenges and will end up being costly.

On the other hand, writing too detailed documentation is both time consuming and bad for knowledge transfer inside your own organization. The developer might be like what we in Finland call “Hangon keksi” (see picture on the right), but there is no one inside your own organization who would want to read about detailed description of how certain parts of the code work. Too complex documentation means less readers, which means less interrest in the software itself and that is bad even if the software itself would be very good. Good things must be shared in a way that makes others want to know more about them.

Coming in the obvious conclusion, the third (and best in my mind) option is to write such documentation that is easy to read, but technical enough for the developer to know where to look for certain things. Use pictures and flowcharts to open up otherwise too complex stuff. It might be even good to describe some of the used technologies so that non-IT people get a picture what’s going on. Having the business understand how software works also makes them realize the potential of what some existing solutions could offer them. Instead of buying and developing new stuff all the time, there might already be working tool already in use.

Share on TwitterShare on TumblrSave on DeliciousDigg ThisSubmit to redditShare via email

Those of you interrested what I’ve been writing for the past year or so – and know Finnish – can check out my thesis. It’s now available in Theseus web library.

Share on TwitterShare on TumblrSave on DeliciousDigg ThisSubmit to redditShare via email