Challenges in the digitalisation of administrative processes
E-government as a means to more economic growth
The digitalisation of administrative processes in the public sector received a boost during the Corona pandemic, but much remains to be done. Especially on the African continent, administrative hurdles and corruption are an important factor for the low economic growth in many countries. The digitalisation of administrative processes such as lending or publicly available online information on trustworthy companies are therefore often an important prerequisite for economic growth.
Involving administrative staff in development
More and more governments are therefore making efforts to digitise the public sector, partly with the help of the World Bank and other organisations. For this to succeed, some hurdles need to be considered. Since the ultimate goal is to improve service for citizens, it is necessary to involve both administrative staff and citizens in order to develop applications that convince everyone.
Especially with regard to the employees, it is important to convince them that the new solution will make their work easier and will not pose a threat to their jobs from the beginning. This means that they should already be involved in the requirements analysis. In order to identify their needs, it is often necessary to observe the existing processes on site in order to be able to map them digitally on the one hand and optimise them on the other.
In order to increase the acceptance of the new systems and to reduce possible resistance, it is important to think about a strategy in advance. Particularly intensive training after the system has been implemented, which focuses on the advantages for the users, can be an important factor in this.
Cooperation of systems between government entities
Other pitfalls for the digitalisation of administrative processes are the legal requirements for them. In order to be able to take them into account accordingly in a system, a precise analysis and knowledge of the laws is necessary. In addition, the areas that refer to laws must be easily adaptable in order to be able to update them quickly in case of changes.
Last but not least, either missing data or data distributed in monolithic systems pose a challenge. Making these easy to find through high-performance search functions, as well as migrating data so that all legal requirements continue to be met, requires a great deal of planning and understanding of administrative processes.
Another important success factor for the use of digital administrative systems is the exchange of data between systems of different government entities. On the one hand, this saves users from having to travel back and forth between authorities, and on the other hand, information is retrieved directly from its sources, which guarantees the accuracy, correctness and up-to-dateness of the data.
Technical and content know-how
All these are reasons why it is often difficult for governments to find the right partner for the implementation of their digitisation strategy, because companies rarely bring both the know-how for the development of such a complex system and the necessary knowledge regarding the specific requirements for the digitisation of administrative processes.
In conclusion, it can be said that experience is crucial in the implementation of e-government projects in order to avoid problems. Precise knowledge of the legal situation and the processes is also essential.
Content:
Complexity needs new solutions
Comparison Individual Software vs. Standard Software
Advantages of customised software: tailor-made solutions
Advantages for individual software can be found quickly: If, for example, a company decides to have a software solution developed, it adapts optimally to its own needs. Business processes remain unaffected by it because it takes them into account right from the start and can even help to improve them – just think of digitalisation. Moreover, it can be seamlessly integrated into existing systems and structures or, again, help to make them more transparent and faster, for example when monolithic structures are merged into one system.
If, despite all the forward-looking planning, adjustments and extensions are necessary if something changes in the size of the company or its range of services, these are possible at any time because there is direct contact with the manufacturer. This also becomes important when companies have to react quickly to changes in the market, which is becoming more and more important in times of rapid change and many global crises, such as the Corona pandemic or the Ukraine war. Last but not least, the look and functions can also be tailored exactly to the company’s wishes.
Disadvantages of individual software reassessed
But what about the disadvantages? At first glance, implementing new software seems like a lengthy process that many would like to bypass. But anyone who has dealt with and experienced the introduction and implementation of standard software knows how many snags there can be before the product achieves the desired result. Because “bought quickly” does not mean that the solution will also run quickly and the seemingly cheaper standard product will quickly become a permanent construction site.
IIf one is also a smaller customer, the interest in successful support is often not very great, whereas the developers of one’s own solution are available for problems and enquiries in one’s own interest alone. Moreover, a standard programme often does not cover all areas of a company, so that one has to deal with a wide variety of providers and maintain different systems, whereas with an individual software solution everything is in one hand.
Cost savings through precise planning and nearshoring
In fact, it is possible for the costs of custom software development to exceed the planned budget. However, a precise needs analysis and planning as well as strict budget monitoring can avoid a cost explosion from the very beginning. Further savings can be made by using a partner who has outsourced his software development to a nearshoring region. In addition, the balance sheet quickly looks different when comparing customised software with standard products, taking into account maintenance, software updates, licences, etc., which are often incurred with the latter.
Close cooperation with a company that specialises in the development of complex software solutions therefore also prevents misunderstandings about what the finished product must be able to do and achieve. This is also helped by the agile way software companies work, where developers can react quickly to changing requirements.
Conclusion: Individual software is the solution of choice in complex environments
In some cases it can certainly make sense to choose standard software. The question of the complexity of one’s own structures and processes, based on the Cynefin framework, helps with the decision. Especially in times of digitalisation, the challenges are rarely simple, so that the approach of a best-practice solution no longer applies. Because in a complex Vuca world, what counts are procedures and structures that can be adapted easily and quickly. A solution tailored to the needs of the customer, which has already dealt with the special challenges of the company during development, is far more helpful than one developed for standard cases. This is true even if experience from many industries has gone into it, as nothing is as unique as a company’s structure and culture.
Content:
Nearshoring in Tunisia: Is it possible?
Six reservations reassessed
Many companies in Europe are now using nearshoring partners to outsource their software development or entire business processes due to the lack of skilled IT staff and high labour costs. The classic choice is Poland, Bulgaria or Ukraine. But locations such as Tunisia are also becoming increasingly important in this context. However, there are still reservations about non-European partners, which can easily be refuted, because nearshoring in Tunisia also offers many advantages.
Quality training and geographical proximity
Quality: In Tunisia, higher education is of high quality and absolutely comparable with Western European countries. 240,000 students graduate from higher education each year, of which 20,000 are engineers and scientists and 9,000 are information and communication technology graduates. Tunisia has more than 50 engineering schools that teach computer science, among other subjects. This guarantees high quality in the implementation of software projects.
Distance: Even though Tunisia is located on another continent, the time difference is a maximum of one hour in summer and a flight takes only a little more than two hours. Thus, in contrast to offshoring in countries like India, it is guaranteed that contact persons are available during European business hours to make arrangements or solve problems.
Multilingualism and stable infrastructure
Communication: Large parts of the Tunisian population speak fluent French, English is taught at school from grade 4 and there are certified as well as professional language institutions for the German language. In the technical professions, French and English can be assumed, and German and Italian are often added. The local distance can be bridged without problems thanks to digital means of communication, which have developed even further during the Corona pandemic. The good telecommunications infrastructure, in which Tunisia is a leader in the southern Mediterranean, also contributes to this.
Mentality: Without question, there are differences between the German and Tunisian mentality. However, companies like think tank Business Solutions now have decades of experience in implementing numerous projects with European partners. A German bridgehead consisting of product owners and IT consultants additionally guarantees that the cooperation with the customers runs smoothly.
Hands-on mentality and cost savings
Management: Managing a project is always challenging, especially when a hybrid, multinational team has to be managed. To ensure the smooth running of a project, an agile working model is a good choice, which has also become popular in Tunisia, especially in the development and implementation of software in companies like think tank. By having German colleagues manage the projects, it is ensured that the customer’s requirements are always in focus. The developers in Tunisia also have a “get the job done” mentality just like their colleagues in other countries and act in a goal-oriented manner.
The best of both worlds
Costs: Tunisia is also a very good alternative in terms of costs. The hourly rates for a Tunisian employee are attractive and competitive. Despite the good quality of the labour market, the average wage costs for a full-time employee, for example, are very low compared to Eastern European countries, making Tunis an attractive North African location for business process outsourcing. It should not be forgotten that with Tunisia we are in a politically stable area, whereas in the Eastern European area there have been tensions and uncertainties in recent times.
Overall, it can be said that Tunisia as a nearshoring partner is a good alternative to the classic Eastern European countries. In combination with a German bridgehead, which can act as a translator not only of culture but also of mentality if necessary, one is relying on the best of both worlds: Availability of skilled labour, cost savings and German know-how and quality.
Content:
Testing in Software Development
Mistakes and how to avoid them
Frequent arguments against extensive testing in software development are often that this is not necessary because a lot of value is placed on qualitative work in one’s own company. This would make it possible to save money on software tests. On closer inspection, however, it quickly becomes clear that both of these points can be refuted very quickly.
Consequences: Missing features and dissatisfied end-users
Because in the communication between the customer and the developer, misunderstandings can arise in the various steps, so that in the end the released application is missing features or cannot do what it should. In addition, the human factor cannot be neglected, i.e. people always make mistakes in their best work. Moreover, changes in an existing system can lead to malfunctions elsewhere, which only appear when an end user complains about them.
And this brings us to one of the consequences of companies trying to save on testing. Errors can lead to customer dissatisfaction and thus to a loss of image. In addition, bugs that occur after the release have to be fixed as quickly as possible. The developers are tied up during this time and cannot continue working on the development of new features, so that the further development of the project is delayed and thus costs money that should have been saved by testing.
Do's: Timely start and dedicated roles
All this makes it clear that testing is a necessary corrective in every software development. But what should you pay attention to in software testing and what should you avoid? It is important to create the test cases in good time, i.e. already when the user stories are created. In the best case, an independent test team is responsible for this, which is not too closely involved in the development, in order to exclude a certain operational blindness. The same applies to test execution. It is best if no one tests their own test cases, but always those created by someone else. In addition, this avoids a bottleneck being created by the product owner who has to approve the release and thus approve all test cases, which can lead to delays.
It is essential to ensure that the test cases are well developed. This means that the test cases are created on the basis of the user stories and, at best, all the steps listed there are covered. Testing should also begin immediately after the developer has implemented the user story in order to be able to meet the release date. Each test should also include a test report, in which exactly what worked and what did not work is recorded, in order to keep an overview of the errors in a development sprint. Automation of test cases for standard use cases, e.g. “I can download a text” or for errors that occur again and again, can be a great help.
Plan 20% of the project volume for software testing
Of course, testing should not be rampant; a test coverage of 95% negates all cost savings, as such a rate can only be achieved through intensive testing. 20% of the project volume is a good guideline to follow when introducing a testing procedure. However, it is pointless to try to save money by testing less, as this is not worthwhile due to the possible loss of image, the resources tied up in development for bug fixing and the associated time-delayed release of a downstream application.
Content:
Do you need a Blockchain?
Do you need a Blockchain?
- Decentralisation,
- security and
- trust.
In order to get a better overview of the different areas of application, the categories to which most use cases can be assigned, regardless of the industry, are listed below:
Digital Identity Management: Many people have certainly come up with the idea of managing digital identities. Not least Facebook and Google, which are integrated as registration services in many online services. From the user’s point of view, this is both convenient and questionable, as it is not always obvious when which data is passed on to third parties and for what purpose. The decisive factor in this category is the purpose, namely the storage of personal data that can be validated and thus used for authentication for other services.
Market creation and digital currencies: This category refers to the creation of new markets. Usually, this is a blockchain-based market on which goods or services can be traded. All cryptocurrency applications are examples of this category. Initial Coin Offerings (ICOs) in which investor funds are collected in an initial funding phase are also examples of market development.
Origin and tokenisation: In tokenisation, a real object that represents an asset is converted into a digital asset. The value is transferred to tokens and uniquely assigned to an owner. The tracking mechanism can be used to prove the origin and ownership of an object at any time (provenance).
Meta-consensus: Meta-consensus is one of the fundamental paradigms of the blockchain, as all participants must agree on a “chain”. This use case category is about finding and reaching consensus on a specific issue without being able to manipulate the outcome of the election. Examples are parliamentary elections, referendums or the votes of shareholders or contracts between several parties.
Tracking. Tracking is about the transparent, permanent storage and traceability of information that is relevant for several organisations. A good example is use cases from supply chain management, as data on transport goods is necessary both for individual suppliers and for checking adherence to laws and guidelines (compliance).
IoT – Internet of Things: Machines that interact on the blockchain like we humans do in real life and exchange goods and services via a wallet are part of the IoT category. An example is the automatic payment of tolls or parking fees, which can be paid by the car, which has a unique ID. Smart contracts, which are executed automatically without external intervention, also belong to this category.
Intermediary trust: Due to the characteristics outlined at the beginning, the blockchain has the potential to reduce the participants in a value chain to those that are really necessary, i.e. only those that actually contribute to an increase in value. Services and goods can thus be offered much more cheaply. One example is the energy sector, where it is possible to directly connect producers and consumers thanks to the blockchain.
We don't need a Blockchain!
The use of a blockchain solution should be viewed critically if it involves the storage of large amounts of data, there are many write accesses and a real-time data set is necessary or only a few participants are involved.
Conclusion
The applications of blockchain are as diverse as our lives. Nevertheless, it is often difficult to judge when its use really makes sense. “If trust or robustness are not important, then there is nothing which a blockchain offers that can’t be done with a regular database.” Gideon Greenspan – Founder of Coin Science.
Quellen: Ulrich Gallersdörfer Masterthesis: Analysis of Use Cases of Blockchain Technology in Legal Transactions https://wwwmatthes.in.tum.de/pages/z0tgbukmqlbr/Master-s-Thesis-Ulrich-Gallersdoerfer, zuletzt geprüft am: 05.02.2020
Cathy Mulligan (April 2018) These 11 questions will help you decide if blockchain is right for your Business https://www.weforum.org/agenda/2018/04/questions-blockchain-toolkit-right-for-business, zuletzt geprüft am 05.02.2020
T. Koens & E. Poll 2018 What Blockchain Alternative Do You Need? http://tommykoens.com/wp-content/uploads/2018/09/blockchain-alternative.pdf, zuzletzt geprüft am: 05.02.2020
DHS model (~end 2017) Dylan Yaga Peter Mell Nik Roby Karen Scarfone Blockchain Technology Overview https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf , zuletzt geprüft am: 05.02.2020
Scaling frameworks Nexus, LeSS and SAFe
Tabular comparison
Megatrends such as digitalisation, globalisation and flexibilisation are rapidly changing our working world today. The expectations and demands of customers are adapting to digital possibilities at ever shorter intervals. New demands are also constantly being placed on products. Teams can be scattered all over the world and still work together excellently. Everything is becoming faster, more interactive and more agile – accordingly, product development cycles are also becoming shorter and shorter.
One method that meets these requirements – today on everyone’s lips – is Scrum. However! What do you do when the product is so large and comprehensive that many teams, different departments or even the whole organisation has to work together on it? The right scaling for efficient and satisfying collaboration provides orientation and support for the teams. But: how do you decide which scalable framework is best? Which framework can be used when the processes of Scrum for 3, 4, 5, … teams are too small? The search for the most optimal approach is a big challenge for many.
To give you a rough overview of the common scalable frameworks, I have summarised an overview that highlights the differences of each framework: Nexus (Framework for Scaling Scrum), LeSS (Large-Scaled Scrum) and SAFe (Scaled Agile Framework).
Nexus
The father of the Nexus framework, Ken Schwaber, describes it as an exoskeleton that connects three to nine Scrum teams to develop a product. It is a process framework based on the agile manifesto and Scrum.
Nexus captivates through its simplicity. Scrum is scaled in its roles, events and artefacts. It focuses on cross-team dependencies and integration issues that arise when scaling across multiple teams and emphasises transparency.
LeSS
LeSS aims to impress with its simplicity (more with less) and relies on clear principles. The teams under a product owner are responsible for the complete product development and bear a great responsibility, which also includes communication towards customers and the environment. If there are more than eight teams, the system is expanded to LeSS Huge in an additional scaling phase.
SAFe
SAFe is economically oriented and has the continuous improvement of value streams in mind. With its hierarchical structure, it looks beyond the team to the programme, solution and portfolio levels as well as the overall embedding in the organisation. Roles, methods and artefacts are clearly described and support the introduction to scaled agile working.
Agile scaling frameworks Nexus, LeSS and SAFe × This comparison is intended to provide you with an orientation to make it easier for you to take the first steps regarding the decision in which direction you want to go – Nexus, LeSS or SAFe. The advantages, disadvantages and limitations of these frameworks have deliberately not been discussed here.
However, before you can choose one of the scaling frameworks, you need to think carefully about which one fits your company culture and values. Check what your goal is, what do you want to achieve? What is the environment like and which agile methods are already used in your company?
My recommendation is to take the elements that best fit your organisation from the known frameworks and adapt an agile scaling framework.
Sources:
SAFe – https://www.scaledagileframework.com
LeSS – https://less.works/de
THE NEXUS™ GUIDE – https://www.scrum.org/resources/nexus-guide
Agile Skalierungsframeworks: Safe, Less und Nexus im Vergleich – https://t3n.de/news/agile-skalierungsframeworks-safe-less-nexus-1150190/
Das beste agile Framework – 5 Large-Scale Ansätze im Überblick – https://www.mosaiic.com/agile_framework/
Agile Testing in
Software Development
The agile way to more quality and efficiency
With the introduction of agile methods, user requirements are the focus of software development. Future users are more involved in the development process and ensure through their input that important issues are actually implemented and that the application is easy to use and perfomant. To verify this, functional and bug-free software must be delivered often and continuously. The high demands on the non-functional part of the software also have to be tested continuously: has it been coded cleanly, does the application meet the security requirements, does it function stably and is it easy to maintain? In one sentence: constant, frequent and error-free code delivery is a question of quality.
What distinguishes agile from classical testing
In classical test management, development and testing are clearly separated and all four test stages run one after the other: the test phase begins with the completion of the product. First the individual components are tested (component test), in the next stage, the integration test, the interaction of the individual components is checked, and finally the functions of the entire product are put through their paces, first internally (system test) and finally by the customer (user acceptance test). The roles are clearly distributed. The development team develops, the test team tests and the test management controls and steers.
If you want to deliver stable and error-free software continuously (with each iteration) in an agile environment, tests must be carried out continuously. In the long run, it is not feasible to run through one test stage after the other according to classical test methods, because the iterations are short and things have to be done quickly. Agile testing also has component, integration and system tests, with the difference that these do not run one after the other, but in parallel within an iteration, and are sometimes even embedded in the development. The agile approach also does not know any clearly distributed roles: Ideally, software developers and architects as well as testers, test and quality managers are part of the development team and support each other. The team has a common goal: high quality through high test coverage, efficient test execution and documentation. This can only be fulfilled through a balance between a high degree of automation and few manual tests.
Efficient distribution of tests: The test pyramid
A look at Mike Cohen’s test pyramid shows how an efficient test strategy can be designed, how the distribution of tests to the individual test levels should be planned and which areas make the most sense for test automation.The broad base of the pyramid is formed by a high number of component tests in the form of automated unit tests. They are relatively easy to create in parallel with application development, can be carried out quickly, are correspondingly inexpensive and guarantee a high level of test coverage. They ensure that most errors are already detected during development.
The middle level of the test pyramid is formed by integration tests (API tests). API stands for Application Programming Interfaces. Automated API tests ensure that components work together as specified. API tests are very well suited for test automation because they are usually subject to few changes and are easy to maintain. At this point, it should be noted that non-functional tests such as load and performance tests are not considered in the test pyramid, but are important for user acceptance and can also be automated very well in some cases. System tests (GUI tests) are at the top of the pyramid. GUI (Graphical User Interface) is the term used to describe the graphical user interface. Automated GUI tests check whether all functions run as desired. Their automation is quite feasible due to a selection of tools, but the choice of tests to be automated should be considered very carefully, as they are more complex to create and maintain and thus cost-intensive. As a rule, GUI tests require considerable rework to keep up with frequent changes.
It is advisable to automate only as many GUI tests as necessary and as few as possible and to introduce them successively, for example by securing existing functions sprint by sprint using automated regression tests. Exploratory and end-to-end tests are hardly suitable for test automation. The latter because of their complexity. Explorative tests because of their degree of freedom. The explorative tester explores the application without having previously determined exactly which test steps are to be executed. One advantage is that less preparation is required, documentation is kept to a minimum and errors are found away from existing test scenarios.
Quellen: Buch: Agile Testing: Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos (2018): Der agile Weg zur Qualität
Content:
Test automation
An indispensable part of agile development
Agile work promotes flexible, dynamic and uncomplicated work with as little bureaucracy as possible. The focus is on people and communication. Results mean more than documentation. Establishing a direct line to the customer and always reacting flexibly is more important than stubbornly sticking to a plan. Agile software development means constantly improving the end product in short iterations, together with colleagues and customers. In this article I would like to explain why automated tests are an integral part of software development.
The importance of testing
Testing occupies an important position in software development. A high-quality product must go through different levels of testing, such as component tests, integration tests and functional tests. In Agile work, as mentioned above, the focus is on short development iterations, which also require short test iterations. In order to be able to carry out the various test stages without getting into a time crunch, it is necessary to execute various tests faster and with easy repeatability. The more complex the software, the greater the importance of test automation. Test automation alone can ensure that both test coverage and test depth are within a satisfactory range once the development reaches a certain complexity.
The fallacy of automated tests
The pitfall of automated tests is that they can only take over the manual task part of a software tester. Behind clean and reliable tests, however, there is just as much creative intuitive thinking and clever action. Under no circumstances should test automation be seen as a rationalisation of a tester’s work, but rather as a tool for the tester that can hardly be imagined without. While he no longer has to spend hours working through new developments of his company through automated processes, he has more time for the intellectual part of software testing. He can test better and in a more concentrated way instead of getting lost in a huge amount of tests. Of course, test automation does not always make sense, such as with small transitional programmes. However, the longer-lived and more complex the software, the more costs and effort test automation saves in the long run.
Selenium as a general-purpose tool
There are many tools for test automation. Selenium is probably one of the best known, especially in the area of websites and their user interface. Selenium offers various tools for projects of different sizes and requirements.
Selenium as a browser plug-in
The Selenium IDE is a browser add-on that allows you to record clicks, keystrokes and movements on the website. Later, you can replay the recorded actions and thus obtain a test that can be executed as often as you like. However, since the recording is very time-consuming manually, the add-on is only available for the browsers Chrome and Firefox and there is no possibility to document the tests, the browser plug-in is only suitable for smaller projects or for beginners.
Selenium WebDriver - When websites suddenly become self-sufficient
The Selenium WebDriver, on the other hand, acts as a programming interface for the browser, is compatible with the most common browsers and supports many different programming languages, including JavaScript, Python, Ruby, and many more. Tests can be programmed in any code editor, e.g. Visual Studio, and the browser is then addressed via the WebDriver. Each time the written test is called up, a new window opens in which the website runs itself through the test. A major advantage over the add-on is that the test can be parameterised. The test coverage can be increased much more quickly and easily.
Cucumber, anything but a cucumber
Since this testing does not provide a clear documentation of the work done, there is a tool for various programming languages (Ruby, Java, C++, …) called Cucumber, which makes it very easy to write and read the test cases and also produces easily readable documentation when the tests are executed. In Cucumber, tests are written in the language Gherkin and then translated into the corresponding programming language. Gherkin essentially contains the commands Given, When and Then, through which the optimal functionality of the software is described by conditions (Given), executed actions (When) and desired result (Then). Since the desired behaviour of the software is directly formulated, Cucumber is a very good tool for Behaviour-Driven-Development. The documentation then contains the simple sentences of the Cucumber programming and is thereupon comprehensible for everyone.
Selenium-Cucumber a reliable double pack
The Ruby extension Selenium-Cucumber takes over the translation of the Cucumber tests into the corresponding programming language. Instead of arbitrary sentences, as previously in Cucumber, there is now a defined set of commands that is independently “translated” into an executable test case. The writing effort on the part of Cucumber naturally becomes greater and more incomprehensible, but the programming elsewhere is omitted altogether. Through this interaction of Selenium-Cucumber it is possible to write automated test cases without in-depth programming knowledge. This way, product owners can pack the requirements for the end product itself into the test without any loss.
Our first steps are done
The combination of Selenium WebDriver, Selenium-Cucumber and Ruby or others allows us to take the first steps towards test automation. Besides the easy writing of the tests and the good documentation in html format, the Selenium WebDriver also allows a wide test coverage in different browsers.
What's next: test automation a must
Test automation is a must in an agile environment. The simpler the tests and the more frequently they have to be performed, the more important automation is. However, automation does not replace a tester but facilitates and improves his work, giving him more freedom for tests that cannot be automated (e.g. UX/UI tests). In the course of continuous improvement, every software company should use automated tests. This is the only way to succeed in meeting the high demands and time pressure of today’s world.
Sources: Buch: Seidl, Richard/Baumgartner, Manfred/Bucsics, Thomas (2011), Basiswissen Testautomatisierung (2. Auflage), Heidelberg, dpunkt.verlag
