Authors: Florian Sch\u00e4ffer, Andreas Lachenschmidt, iNTENCE automotive electronics<\/p>\n
This presentation reveals the pitfalls of modern software engineering when it comes to effort and cost assessment, and the hidden challenges of virtual and distributed projects. In the past, it was possible to simply add up the unit costs of hardware and rely on a transparent manufacturing process where programming was a secondary activity. However, with increasingly extensive, complex, and agilely developed software, more sophisticated methods are required for accurate effort estimation.<\/strong><\/p>\n When we talk about software engineering, we're not thinking of the agile app developer who single-handedly handles all disciplines. They define their own requirements. The app's software architecture emerges organically as they find suitable solutions to the problems that arise along the way. Most of the development time is spent on implementation.<\/p>\n But even that's short-sighted: Without a functional, field-proven OS, even the best app won't run. To then bring the OS to market in a production-ready state, we need software engineering with many specialists involved, who aren't afraid to think outside the box.<\/p>\n Therefore, a large number of people in different roles are responsible for ensuring that our software project adheres to the agreed time and cost plan.<\/p>\n However, a plan is only valid until the first contact with the enemy. After the first functions are delivered to the customer, it turns out that one or more requirements were misunderstood or implemented incorrectly.<\/p>\n If we don't want to jeopardize the schedule, we'll now try to get this situation back on track with overtime and additional developers!<\/p>\n Naturally, this has created additional work because we first have to explain the project to the "new people" who were brought in from other projects. Until the additional hardware and all the tools for the developers arrive, inefficient and unproductive days or weeks will pass. The only thing running at full capacity will be the coffee machine.<\/p>\n The cost burden doesn't just grow upwards, but also continues to migrate towards the start of production. Let's first remain in the idyllic world of planning.<\/p>\n With the well-known iterative V-model, the situation is quite clear and relatively predictable because it is the most widely used and therefore most proven development model. Each individual V-model we go through is similar to its successor and its predecessor. The effort required may vary between the individual disciplines, but the overall effort is comparable in each cycle.<\/p>\n (see image 1,\u00a0PDF<\/a>)<\/p>\n Of course, this model doesn't prevent us from heading in the wrong direction during a V-cycle and only realizing it at the end when delivering the final version to our customer. The best-laid plans would be ruined if we had naively relied on our intuition and hadn't planned for additional, expensive releases "just in case.".<\/p>\n Agile development using methods like Scrum, Continuous Integration, and Continuous Delivery reduces the hectic pace before deliveries and distributes effort more evenly, but in smaller increments. Ramp-up and ramp-down phases are less disruptive because they are needed less frequently. Project missteps can be identified earlier and corrected with minor adjustments.<\/p>\n Long-term planning isn't the goal, however; the main advantage lies in not having to postpone deliveries because there's practically always a sufficiently mature, and above all, tested and optimized software available. Not just for customer releases. But instead of throwing schedules out the window, there's always the risk that features not considered high priority will fall by the wayside.<\/p>\n So, what is our best course of action? A conservative and supposedly safe approach based on the iterative V-model, or a modern, agile approach with room for adjustments if the customer changes their mind?<\/p>\n Within the framework of the applicable regulations and standards (for example, ISO 26262), we can therefore choose which approach we want to take. The biggest differences between the two approaches arise in testing, documentation, and especially communication.<\/p>\n Initial testing and tooling costs are certainly higher with agile development because we need to establish a tool landscape that makes continuous integration possible in the first place. Test cases are formulated and at least prepared at the beginning using Test-Driven Development. This saves us dedicated test runs before each customer release, including time-consuming bug-fix loops.<\/p>\n (see image 2,\u00a0PDF<\/a>)<\/p>\n If we strictly follow the V-model process, there are very few points at which we communicate with the customer and future users of our system. This differs from agile development, where we maintain constant contact with the customer. This creates additional work, but it also prevents us from going in the wrong direction for too long.<\/p>\n An initial cost estimate certainly seems easier at first glance with the conservative approach using the iterative V-model. Nevertheless, Parkinson's Law will apply in both cases if we estimate too cautiously.<\/p>\n \u201e"Work expands to fill the time available to complete it."\u201c<\/p>\n Speaking of communication \u2013 we live in modern times. We also want a piece of the digitalization pie. Digitalization offers projects diverse opportunities to adapt software development to new circumstances. Theoretically, every employee can do their work from anywhere in the world, as long as there is electricity and an internet connection.<\/p>\n Distributed teams allow us to bring together the best developers from around the world without requiring anyone to relocate. This is in addition to the different salary structures across borders, which also benefit us in our expensive development locations.<\/p>\n Of course, it's not that simple! Let's not forget everything we discuss in the coffee kitchen or in the hallway.<\/p>\n How high is the hurdle to picking up the phone and speaking to a developer colleague on the other side of the world in a language that isn't both of our native tongues? We can, of course, lower that hurdle if we see each other regularly or engage in small talk. But that requires travel budget \u2013 which needs to be factored in not only financially, but also in terms of time.<\/p>\n Let's go even further: As a driver, do you know what motorway turn signals or comfort turn signals mean?<\/p>\n If we were to ask the same question in a country where roads outside the megacities don't even have road markings\u2014and these are the popular "low-cost countries"\u2014the answer would be different. Cultural differences also mean that we have to spend significantly more time specifying our requirements more precisely. However, this additional time is incurred in "high-cost countries," not where the hourly rate is cheaper on paper.<\/p>\n The most experienced developers, who wouldn't need any explanations of the functions, won't accept this pay gap for their entire careers. They'll try to advance or apply for more lucrative positions abroad. So we lose our best people, whom we've invested a lot of time and effort to train, very quickly.<\/p>\n Since software often has dependencies on neighboring systems, it's necessary to gather information about these dependencies. Information about the target system and much more is required. If such information isn't provided, it can lead to delays and additional costs. Managing this information can therefore be crucial. Defining the quality, quantity, and timing of the information provided can save projects.<\/p>\n When taking a function-driven view of the product, we mustn't forget that seemingly trivial things like setting up a project environment, creating the architecture, and implementing quality assurance measures need to be factored in. Checklists can be helpful here.<\/p>\n Inaccurate specifications can lead to significant misunderstandings regarding the functionality of the software to be developed. Estimates based on these misunderstandings will only prove flawed later in the project, costing time, money, and nerves. Creating a project handbook during the acquisition phase helps to discuss goals, tasks, and the timeline with the client before submitting a proposal.<\/p>\n Often, project specifications are not fully detailed at the time of tendering. To ensure transparency regarding the basis of the estimate for the client, the assumptions should be documented as precisely as possible in the proposal. A personal review of these assumptions with the client before submitting the proposal can prevent misunderstandings and allow for early confirmation of assumptions, as well as providing an opportunity to adjust estimates. An established change management system can be helpful in this regard.<\/p>\n It pays to keep the technical and organizational challenges, or even risks, of the project in mind during the proposal preparation phase. Sufficient time should be dedicated to these points during the estimation process to thoroughly examine complex issues and evaluate alternative solutions.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topics of management \/ process, project and product management.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in management \/ process, project and product management is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\nFurther considerations<\/h3>\n
\nManagement \u2013 our training & coaching<\/h2>\n
\nManagement \u2013 Expertise<\/h2>\n