Software Analysis through the Eyes of a Professional | Technology Blog

Software analysis is often considered to be a technical activity and software development is generally said to be an overwhelmingly male domain. However, in today’s blog with Andrea Haverlová, the manager of ANASOFT’s analyst, consultant and tester teams, we discover  that things are not always as they seem. Join us as we take a peek into the technical world through the eyes of a woman who will offer us an interesting view of software analysis.

How do you feel as a female software analyst in an area which tends to be predominantly male?

I always look at this topic as gender neutral. I think it depends on the relationship a person has with the given area, in the sense that the working tool of a software analyst is the computer.

I’m the kind of person who enjoys clear rules and so the one – zero world of computers works for me. The work of a SW analyst isn’t for someone who needs intense social contact, because they would miss the emotions.

Better to say, for an SW analyst it’s probably important to “fall in love” with the technical solution and then it doesn’t matter whether you’re a woman or a man.

Coincidentally I recently watched a movie about Alan Turing, who is considered to be the grandfather of digital calculating machines – in other words, computers. He created this kind of calculating machine and even though it was a tangle of parts and cables, he loved it.

Even from my own experience I know that there are quite a few female SW analysts, even in our firm (laugh). The designer – architect of SW solutions is another role with whom the SW analyst closely cooperates, and that’s a strictly male affair. I could count on one hand the female SW architects I know.

Alan Turing created a calculating machine and even though it was a tangle of parts and cables, he loved it. And for me, custom software development is a certain form of art.

What is interesting and appealing to you about SW analysis?

It’s important to point out the difference between the analysis of a SW product and custom SW. The development of custom SW is a kind of art form. As an analyst I can apply everything I know and use my creativity to the maximum extent to achieve the client’s goal.

On the other hand it’s also a commitment and a responsibility in the sense that the analyst must think for their clients. We can’t expect that our clients will say ‘do it like this.’ They often know what they want, but they don’t know how to achieve it. The main job of the analyst is to transform the customer’s requirements, to explore and to pose critical questions.

I know that younger analysts think of their role as writing down a list of requirements. But it’s not just writing down requirements, it’s also necessary to understand them and to draw out what is hiding behind the requirements. I like to say that if a client tells you that you have a pretty sweater, it’s important to understand what they really mean by it. Are they saying it because they really like the sweater, or is it because I didn’t dress appropriately? Or is it because it’s cold outside and they think it makes sense to wear a sweater? Or is it something different?

The role of the analyst is to understand the client’s intention and to transform it into an assignment.

In this sense, working on a SW product, which is limited by the product’s options, is different. Since the product has to be repeatedly used, the analyst tries to defend the quality of the product and to show how it can be used to meet the client’s requirements. When working on a SW product, the analyst has the advantage of knowing the product in detail and so they don’t have to reintroduce themselves to the new business environment of the client.

What was the biggest challenge for you as a SW analyst?

Before joining ANASOFT, I was a SW product analyst and the biggest challenge for me was to reconfigure myself to custom development solutions. To realize that I suddenly didn’t have the world of my product, but I needed to continually learn and try to understand my clients’ business and to search for the optimal solution.

I also realized that it was important to leave behind a relatively large trace because each project is unique. As a result, the analyst doesn’t just do the job for themselves and the programmers, but also for those who come after them.  This enables them to find out how and why a solution was built even after a longer period of time without having to examine the details of the source code, which is the most expensive solution.

I assume that leads to a certain methodology of analytical work.

Of course. It’s more noticeable during big projects. The bigger the project the more people who need to be coordinated. That’s why, among other things, we implemented a central storage site of projects in the Enterprise Architect tool, where analysts have access to analytical documentation of projects in terms of our project methodology. 

The second area is the creation of documentation, and in order to achieve this, we began to create a robust methodology some time ago. We created templates of various analytical documents with the objective to have things analytically processed in a precise way. But although this worked with large projects, on smaller projects we realized that it wasn’t appropriate. Many times even the clients themselves are not able to store it and so it requires a more open approach.   

After years of experience, a certain puzzle was created in which the analyst could build whatever they needed from the methodology with respect to the extent and needs of the project.

As an analyst, what is the key to a successful project?

Even though I consider the job of a SW analyst as a technical job, communication is crucial. Aside from the technical solutions and technologies, the analyst is also a kind of psychologist who needs to understand the points of view and needs of the people involved. 

Apart from the users, the analyst’s partners include the project managers with whom they discuss the project’s scope, risks and schedule.

Then there’s the designer/developer, for whom the analyst must prepare an assignment with an explanation “Why are we doing this” and offer all the details, without which the developer can’t program. The analyst must also have an answer for every question the developer has. And it doesn’t matter whether it’s thought out beforehand or if they find it out from the client.

Last but not least there’s the tester, to whom the analyst must explain what the resulting solution should do, and help them configure the tests that will verify the solution.  

Even though I look at the job of a SW analyst as a technical job, communication is crucial. Aside from the technical solutions and technologies, the analyst is also a kind of psychologist who needs to understand the points of view and needs of the people involved.

Is the job of an analyst difficult? It seems that it requires a vast amount of  experience.

Like every job, experience is beneficial. Over time my view of the job of an analyst has changed. Many younger analysts take the job more technically than communicatively, but like every job, which is fun and which a person sticks with, new experience comes and with it a new view of what is important. It’s definitely a complex job. It’s not about collecting requests, but also about fulfilling the client’s objectives, which are not always clear at first glance.  

For me it’s an interesting job, but I also find the job of the testers admirable, because their job never ends and they can always start testing from the beginning. In my case I see it as an advantage that the SW analyst sees the results of their work. And definitely, the job is a sort of connector during the whole project.

What would you compare the job of a SW analyst to? It seems to me that it’s as complex as creating music for a film.  No one tells the composer which instruments should be used and when they should be played. The composer has to put it all together.

I never thought about it this way, but it’s an interesting comparison. In a certain sense it’s similar in that you start with nothing and the solution has to be created and the analyst is the one who contributes greatly to the creation. Something tangible is created based on the requests and ideas.  

How would you describe the process of SW analysis in layman’s terms?  

To a great extent it’s about talking with the client and figuring out what they really want. If for example the client says that they need to record invoices, I’ll think about it and find out that they might also need the records of partners. They’ll also need some sort of invoice forms as well as their electronic transmission.     

It’s a process in which I identify domain objects – words, that the customer uses, and I create a list of analytical objects which are then more abstract than what the customer stated.

It’s because invoices can be supplier or customer invoices. Apart from that, it would also make sense to record orders. That’s why it would make sense to record something more abstract in the system, for example documents. It’s important to pay attention to the functionality, which is often done by using the raising of invoices or their payment. The opposite approach is also possible.  First I write down the functionality and from there the objects which are used will come out.

The next step is to design the user interface so that it’s  understandable for the client. the integration solutions for different systems form another chapter in itself.    

And how does a SW analyst make sense of all this and communicate it to the user and their colleagues?

An important part of the analyst’s job is notation or a form of entry so that it’s clear what the system will be doing and how. It’s very important that all the parties involved are able to read the analytical outputs and comment on them. Analysts use a number of different types of notations, but that’s a topic for another entire interview (laugh).

That’s not a bad idea. Thanks for the interview.

Interview conducted by Boris Rybár
Software Development Team Manager

WHAT COULD INTEREST YOU