The Art of Software Reviews: Identifying problems and risks accurately

Source: Heise.de added 28th Dec 2020

  • the-art-of-software-reviews:-identifying-problems-and-risks-accurately

True to the motto “It’s always better”, practically every software suffers from problems of small or large nature: Perhaps it runs too slowly, sometimes crashes or looks less beautiful than the competition’s system. Business often complains loudly that new features take far too long – in new German: the time-to-market is too bad. Apart from hello-world, there are still many things that can be improved everywhere.

Anyone who wants to leverage this potential for improvement in their system should definitely do it First, develop an explicit, concrete and specific understanding of the existing problems. One can learn from medicine: There is a thorough diagnosis (examination) before the therapy proposals. Without such a review, as the study is called in the IT industry, there is a risk of deterioration.

The article presents the breadth-first search as the central approach of methodical software Reviews and highlights some of the main research approaches.

Five phases Schematically, reviews should always have five phases take place:

Before starting, teams should clarify the objectives and the scope with the clients or system managers. To do this, they jointly determine how long the review should take. The concrete procedure is also defined with these people: Which interviews and analyzes are required at what point in time and with which participation? In a kick-off, those responsible explain this procedure to all people involved. At the same time, you can use this meeting for initial discussions about the system and its strengths and weaknesses. Targeted interviews will now follow Participants from different areas. After these discussions, further analysis steps are available, if necessary, in which one can search specifically for problems and risks of certain categories. Analyzes and the interviews from step 3 can alternate: The results of interviews may make certain analyzes necessary and vice versa. Finally, you work up the results, conclusions and recommendations and present them to those involved. Review procedure (Fig. 1)

Who carries out reviews? Before the review, it should be considered which people are actually eligible for a review. In principle, these can be those involved in the development, alternatively also outsiders (“external parties”). Figure 2 compares some advantages and disadvantages of the two variants – with the conclusion that internal and external participants are mixed for reviews – this is how you get a “best of both worlds”: They exclude bias and operational blindness and are time-effective and substantiated concrete results.

Internal versus external reviewers (Fig. 2)

Successful reviews start with a clear formulation of Goals that the review should achieve. Project managers should work out such goals together with the clients of the review. You should ask what motivates someone to review or what problems it caused. These goals should be put in writing – otherwise they will be forgotten all too quickly.

In addition to the goals, those involved must clarify the subject of the review. What exactly should you investigate? A formulation like “the system X” could be interpreted differently by different people, so they determine together with the client what exactly they should investigate. Typical points could be:

the architecture, the structural design of the system from components and their interfaces technologies used and technical concepts of the system the implementation, i.e. the source code the operation of the system in its Infrastructure or target environment the development or development processes, for example clarification of requirements, coordination of development tasks, test and quality assurance, configuration and Version management, deployment, rollout as well as change management and bug fixing This article comes from the special issue “iX Developer – Modern Software Architecture”. On 148 pages it forms a cross section on important topics of contemporary software architecture. Interested parties can get an overview here. The printed version costs 14, 90 Euro, the PDF output 12, 99 Euro.

The parties should In this preliminary discussion, ensure that the scope and goals match. They also clarify which people are working. This also applies to the cooperation of the client and deadlines.

Read the full article at Heise.de

brands: Art  Best  CODE  New  Versus  Writing  
media: Heise.de  
keywords: Review  Software  

Related posts


Notice: Undefined variable: all_related in /var/www/vhosts/rondea.com/httpdocs/wp-content/themes/rondea-2-0/single-article.php on line 88

Notice: Undefined variable: all_related in /var/www/vhosts/rondea.com/httpdocs/wp-content/themes/rondea-2-0/single-article.php on line 88

Related Products



Notice: Undefined variable: all_related in /var/www/vhosts/rondea.com/httpdocs/wp-content/themes/rondea-2-0/single-article.php on line 91

Warning: Invalid argument supplied for foreach() in /var/www/vhosts/rondea.com/httpdocs/wp-content/themes/rondea-2-0/single-article.php on line 91