Beitrag von DONAT IT GmbH

🧨 𝗠𝗶𝘁 𝗜𝗧-𝗗𝗶𝗲𝗻𝘀𝘁𝗹𝗲𝗶𝘀𝘁𝗲𝗿𝗻 𝗳𝘂𝗻𝗸𝘁𝗶𝗼𝗻𝗶𝗲𝗿𝘁 𝗲𝘀 𝗲𝗶𝗻𝗳𝗮𝗰𝗵 𝗻𝗶𝗰𝗵𝘁! 🧨 Mal ganz ehrlich: Wer von euch kennt das nicht aus eigener Erfahrung oder von Freunden und Bekannten. Sie haben mit einem externen Partner zusammengearbeitet und das überhaupt nicht funktioniert. 💸 Warum? Weil der Dienstleister einen Haufen Geld gekostet hat und am Ende die Software nichts brachte. Oder von so schlechter Qualität war, dass sie direkt neu gebaut werden musste. Dabei klang am Anfang alles so gut! ❗ Deswegen hören wir immer wieder: Das funktioniert einfach nicht! Wir haben uns einen anderen Weg gesucht. 💬 Es geht aber auch anders. Es kann auch funktionieren, wenn man auf ein paar klare Punkte achtet. Davon berichten Konrad Hosemann, Sascha Wechsung und ich in unserem Vortrag von den IT-Tagen: https://lnkd.in/ex3iqS9D. ☕ Möchtet ihr mehr erfahren – oder glaubt es immer noch nicht? Dann lasst uns sprechen: https://lnkd.in/evVkx3TG.

Raus aus den technischen Schulden. 👾 Der Aufbau technischer Schulden ist kein Zeichen von fehlender Professionalität, sondern eine alltägliche Realität. Dennoch solltet ihr sie bewusst eingehen und ihren Abbau entsprechend berücksichtigen. Unsere Erfahrung nach entsteht genau dann Reibung, wenn ein Entwicklungsteam einerseits neue Features umsetzen muss, aber gleichzeitig unter bestehenden technischen Altlasten leidet. Ein dauerhaftes Ignorieren technischer Schulden birgt Risiken für Softwarehersteller, wie mangelnde Skalierbarkeit und langsame Entwicklungszyklen. Sie machen überbordende Refactoring- oder Rewrite-Initiativen erforderlich oder führen im schlimmsten Fall in die „Technische Insolvenz“. Damit es gar nicht erst so weit kommt, haben wir Dir unsere Tipps zum Umgang mit technischen Schulden hier im Blogartikel zusammengefasst: https://bit.ly/3U2Yu2V #TechnischeSchulden #Refactoring #Schuldenfalle

Der richtige Umgang mit technischen Schulden will gelernt sein. Neben den Empfehlungen von DevBoost finde ich es noch wichtig, technische Schulden zu quantifizieren. Oft werden technische Schulden erst sichtbar, wenn über längere Zeit der Schaden von technischen Schulden mit Zahlen belegt werden kann. Einige Beispiele, um den Einfluss von technischen Schulden zu quantifizieren, sind: * Werte aus der (hoffentlich vorhandenen) Testautomatisierung erheben, wie z.B. der Grad der Testabdeckung * Komplexitätswerte wie zyklomatische Komplexität berechnen * Regelmäßig Zahlen aus Tools wie SonarQube erheben, wie z.B. Anteil der Codeduplikation * Metriken erheben, die indirekt auf technische Schulden hinweisen, wie z.B. * Velocity des Teams * Performance der Software * Häufigkeit von Bugs Komplexe Herausforderungen erfordern nicht immer komplexe Herangehensweise - oft reicht es, mit einfachen Ideen den ersten Schritt zu tun!

𝗣𝗿𝗼𝘇𝗲𝘀𝘀𝗯𝗲𝘀𝗰𝗵𝗹𝗲𝘂𝗻𝗶𝗴𝗲𝗿 𝗪𝗶𝘀𝘀𝗲𝗻 Unternehmensprozesse sind oft träge, Software-Anforderungen häufig ein Fall für sich. Die Prüfung zahlreicher Nutzungsrechte, die Menge der involvierten Personen und die Vielzahl der eingesetzten Systeme lassen den Prozess ausufern. Häufiges Ergebnis: ein aufwändiges Vor und Zurück, Stillstand und genervte Beteiligte! Wir haben die Lösung: mit der License Library prüfst du Nutzungsrechte in einem zentralen System, klärst deine Fragen und bedienst die internen Stakeholder. Sebastian K. zeigt dir, wie einfach das geht: https://lnkd.in/eDgFkBD4 Oder teste gerne selbst: https://lnkd.in/ehnriP76 #ccpsoftware #licenselibrary #lizenzmanagement #softwareanforderungen #lizenzprüfung #nutzungsrechte

Ein elektronisches Fahrtenbuchprogramm muss manipulationssicher sein. Dies bedeutet nicht, dass das Programm vor jeglichem Hackerangriff gesichert ist. Aber es muss sichergestellt sein, dass die Fahrtenbücher in einer in sich geschlossenen Form erstellt werden sowie nachträgliche Veränderungen an den erfassten Daten technisch ausgeschlossen sind oder zumindest als solche offengelegt und erkennbar sind. Darüber hinaus müssen Fahrtenbücher mit vertretbarem Aufwand auf ihre materielle Richtigkeit hin überprüfbar sein. #elektronischesFahrtenbuch #Firmenwagen #Steuern

Ein elektronisches Fahrtenbuchprogramm muss manipulationssicher sein. Dies bedeutet nicht, dass das Programm vor jeglichem Hackerangriff gesichert ist. Aber es muss sichergestellt sein, dass die Fahrtenbücher in einer in sich geschlossenen Form erstellt werden sowie nachträgliche Veränderungen an den erfassten Daten technisch ausgeschlossen sind oder zumindest als solche offengelegt und erkennbar sind. Darüber hinaus müssen Fahrtenbücher mit vertretbarem Aufwand auf ihre materielle Richtigkeit hin überprüfbar sein. #elektronischesFahrtenbuch #Firmenwagen #Steuern

Wird ein Firmenwagen auch für private Fahrten genutzt, ist der geldwerte Vorteil nach der 1%-Regelung anzusetzen. Die 1%-Regelung kann nur vermieden werden, wenn ein ordnungsgemäßes Fahrtenbuch geführt wird. Ein Fahrtenbuch kann nur dann ordnungsgemäß sein, wenn es eine geschlossene äußere Form aufweist und die Eintragungen zeitnah erfolgen. Das gilt auch für ein Fahrtenbuch, das mithilfe eines Computerprogramms erstellt wird. #Fahrtenbuch #Computerfahrtenbuch #Steuertipp #PKW

Wir durften unseren Kunden Neo One AG bei der Einführung der digitalen Rechnungsverarbeitung unterstützen. Seither profitiert das Unternehmen von folgenden Vorteilen: 👉 Beschleunigung der Rechnungsverarbeitung um 30 Prozent 👉 Automatisierung der Dateneingabe 👉 Einfache Freigabeprozesse und sofortiger Statusüberblick Möchtest du das für dein Unternehmen auch erreichen? Komm gerne für einen Kaffee vorbei und wir besprechen, wie ich dich dabei unterstützen kann. ☕️ Mehr Informationen zur Customer Story findest du hier: https://lnkd.in/eW-qQUqP #Workflowautomation

Was ist eigentlich #Updatability? Immer wieder findet sich in der juristischen Literatur die Forderung, Geräte mit integrierter Software müssten als vertragliche Sollbeschaffenheit oder als produkthaftungs- bzw. produktsicherheitsrechtliche Anforderung jedenfalls „updatable“ oder „updatefähig“ sein. Aber was bedeutet das eigentlich? Welche Dimensionen sind bei der Implementierung eines Updatemechanismus zu berücksichtigen? Und wie wirken sich #CRA, #GSPR und das Recht auf Reparatur darauf aus? Dem gehen meine Kollegen Raphael Brenner, Sebastian Jänich, Henrich C. Pöhls und ich aus dem Forschungsverbund ForDaySec in der Juniausgabe der RDi nach. Wir freuen uns über Lektüre und Feedback! Link (Paywall): https://lnkd.in/dbj8Jv8r