All posts in Software Development

An exploration of SonarQube and the pursuit of enchanted Software Quality.

Subscribe for more…


I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke funktionell kravställning & Teknisk skuld

 

I takt med att informationsteknologi och digitalisering blir allt viktigare för företag och organisationer så blir även inverteringar mer integrerade och komplicerade. Detta leder till att det blir svårare att retroaktivt anpassa fundamenten till nya inriktningar, livscykelhantering blir avgörande för vilka risker och möjligheter man har att anpassa mot strategier och kvalitetsförväntningar.

 

Icke-funktionella krav anger kvalitetskriterier

För att undvika att hamna i ett läge där man inte längre har möjlighet att möta marknadens behov inom en rimlig tid och investeringsnivå så bör man redan tidigt etablera nyckeltal som indikerar trender på de icke-funktionella kraven och den tekniska skuld som man har upparbetat i lösningen. Dessa nyckeltal agerar som en baslinje (nollmätning) som man sedan mäter förändringar mot. Det pratas väldigt mycket idag om IT säkerhet och vikten av informationssäkerhet – inte minst i samband med ny lagstiftning och medias reportage kring organisatoriska fadäser inom just IT säkerhet.

Beslutsfattare och kravställare av informationssystem och tjänster underskattar ofta vikten av de icke-funktionella kraven, kanske för att det är grumligt vad det egentligen innebär, samt att det ofta rör sig om tekniska eller designmässiga kvalitetsaspekter och vedertagna begrepp från yrkeskåren. Icke-funktionella krav är krav som anger kvalitetskriterier som kan användas för att bedöma driften av ett system, i stället för specifika beteenden. Planen för genomförande av icke-funktionella krav beskrivs ofta i dokumentation för systemarkitekturen och underhålls vanligtvis av en lösningsarkitekt. Några vanliga områden man pratar om kring icke-funktionella krav är:

  • Säkerhet – Nivå av preventiva säkerhetsåtgärder för att motverka otillbörlig tillgång
  • Förvaltningsbarhet – Livscykelaspekter för att bedöma hur utvecklingsbart systemet är
  • Tillgänglighet – Toleranser för systemets tillgänglighet
  • Användbarhet – Intuition mått för användare att konsumera nya funktioner
  • Prestanda – Kapacitetsmått under tung last

 

Kvantifiera den tekniska skulden

Framgångsrika organisationer använder moderna metoder för att utveckla lösningar med inbyggda kvalitetsgrindar för att systematiskt och inkrementellt bygga lösningen med rätt kvalitetsegenskaper. Vilket innebär att man ibland medvetet inte bygger lösningen med full funktion. Vanligtvis gör man en prototyp för att tidigt utvärdera egenskaper och riktningsbeslut. Eftersom vissa delar har medvetet blivit eftersatta och kommer behöver kompletteras så aggregeras det en skuld, eg. teknisk skuld. Begreppet (teknisk skuld) fungerar precis som vanlig ekonomisk skuld, genom att man lånar för att tidigare kunna erhålla produkten så får man betala ränta så länge man har lånet kvar.  Precis som amortering på ett ekonomiskt lån så betalar man tillbaka sin tekniska skuld med refaktorisering, dvs man förbättrar kvalitén i koden. Teknisk skuld kan mätas genom att kvantifiera attribut och kodmönster med tidsfaktorer och övervakas kontinuerligt (continuous inspection). Koden kan delas upp i olika alvarsgrader som exempelvis att det luktar illa till riktigt buggar och sårbarheter som akut måste fixas före det produktionssätts.

Genom att kontinuerligt mäta och medvetet styra utvecklingen inkrementellt så får man även tidiga varningssignaler och minimerar kvalitetsbrister. Genom kvalitetsprofiler så kan man mäta specifika grader av kvalitetsbrister och säkerställa att man inte överstiger satta tröskelvärden. Enhetstestning och utforskande testning kan påverka kvalitetsgrindar och kan med fördel innefattas i kvalitetsprofilen. Kvalitetsgrindar säkerställer att varje inkrement uppnår rätt nivå och mäts i perioder mot baslinjen för att se trender och tendenser. Ju tidigare man upptäcker en kvalitetsbrist, desto mindre blir i regel skadan och ju enklare blir det att åtgärda.

Kontinuerlig inspektion

SonarQube (www.sonarqube.org) är ett bra verktyg för att kontinuerligt mäta och kvantifiera den tekniska skuld man har i lösningen. Genom statisk kodanalys så analyserar verktyget hela kodbasen och presenterar visuellt hur olika ögonblicksbilder av koden presterar mot den kvalitetsprofil man har fördefinierat. Det möjliggör en dialog kring icke-funktionella kvalitetsaspekter och teknisk skuldhantering som annars kan vara abstrakt och svårkommunicerad.

Genom att visualisera och använda verktyg som SonarQube för att analysera stora kodmassor så kan vi säkerställa att vi ser samma bild och gemensam förståelse för annars svåra begrepp att säkerställa handskakning med tydlig kommunikation med intressenter.

Tillsammans med en partner som har gedigen erfarenhet av kvalitetshantering och med effektiv kommunikation kring icke-funktionella krav så att du som kund kan komma till avgörande insikter och säkerställa att investeringar frodas under lång tid framöver.


Why, How, What of Kanban – is a walkthrough of Kanban using a software delivery pipeline example.

 

Subscribe for more…

 


How to migrate source code from Team Foundation Server (TFS) to Visual Studio Team Services (VSTS).
 


 
Subscribe for more…
 

 


Screencast how-to install SonarQube 6.0 on a Windows Server in Azure using Microsoft SQL Server and integrate it to Visual Studio Team Services latest build system.
 

 
Subscribe for more…
 

 


For more than 20 years software development has been both my passion and profession. Many things have changed during this time and not all for the better…

Sometimes I miss the feeling of being in full control and understanding every little piece of the software from ideas to actual usage. In some sense it was easier before when this was expected from a software craftsman like me, to be able to deliver it all in one self, and to be the whole process and not just a replaceable gear that’s moving other gear without understanding the purpose. For me the completness is where the passion was created, the endless curiosity and borderless creativity was created from this spark, resulting in a lifelong passion for software development.

Modern software development practices seems to aim for the return of the completeness into focus for developers – ALM and DevOps. Regardless of the role we have in the team the feeling of being a part of the whole and not just an isolated part should be valued as it feeds the sense of purpose and nurtures curiosity, maybe even sparks passion.

Continuous innovation, feedback and improvements feed the lifecycle engine in continuous agility from planning to operations. Composed of persons, processes and tools to make it more predictable and deliver more quality software faster.

 

blog.yllemo.com_devops_alm

 

Gathered behind the shared goal of increased transparency and cooperation between all stakeholders involved in the software crafting process, making increased collaboration the key to success and sparking passion.

In the end it is the passion that rules the game.


Hello, Friends! Are you interest in delivery of quality software in less time? Let me introduce a new experiment I’m working on to help close the gap between Business practices and Software Development practices – ALMBoK.com.

Application Lifecycle Management (ALM) defines how a software application is managed from conception, through its creation and deployment, to its eventual retirement. ALM is made possible by tools and technologies that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management. ALM recognizes that the requirements are evolved based on business needs or ideas for new opportunities. Applications are the foundation from which business processes are executed.

Modern ALM and DevOps practices enables integrated and optimized processes that provides the agility needed to quickly take advantage of increasingly faster paced business demands.

The Body of Knowledge (BoK) provides the insights to improve business and development processes via knowledge areas and groupings of knowledge articles (disciplines, methodologies, products and tools) from both internal and external sources.

The ambition of this free knowledge base – ALMBoK.com – is to cover the high level perspective and to serve as your guide in Application Lifecycle Management.

For more detailed information please visit the site – www.almbok.com

almbok.com_blog.yllemo


Att bygga mjukvaror är svårt, att räkna på investeringar i mjukvaror är svårt, att möta investeringen med rätt byggkvalitet är jättesvårt. Vi vet oftast för lite kring vilken skuld vi har ackumulerat genom de beslut vi tar längs resan och vi fokusera inte ofta på att amortera skulder.

Total ägandekostnad (eng. Total Cost of Ownership, TCO) är något som investerare kalkylerar på för att se vad den totala kostnaden är för en mjukvara inför ett investeringsbeslut. Den totala ägandekostnaden omfattar såväl anskaffningskostnad som driftskostnad men i många fall så räknar man inte med ackumulerade skulder som en del av den totala kostnaden för ägande, kanske för att det inte finns bra modeller för detta eller för att man helt enkelt inte förstår att det kan kalkyleras.

Under en applikationslivscykel så skiftar investeringen från en kapitalinvestering (CAPEX) till en operativ kostnad (OPEX), vanligtvis från ett projekt till en förvaltning. Inkluderat i denna övergång är de skulder som ackumulerats vilket kan leda till oförutsedda kostnader och ytterligare investeringsbehov för att möta effektmål. Det är en stor risk att inte veta vilken skuld man äger och vilka mått av kvalitet man mäter på, detta kanske är än mer viktigt när det kommer till mjukvaror då det kommer strida strömmar av inkrementella förbättringar och de positiva riskerna (vinster) kan kontinuerligt värderas därefter. Det är trots allt idéer som blir till affärsapplikationer, som sparar pengar eller ökar omsättningen.

För några veckor sedan var jag med som talare på en konferens kring systemförvaltning och passade även på att lyssna på övriga talares framträdanden. Ett mycket intressant framträdande var från Johan Magnusson, forskare från Chalmers kring Teknikskuld (eng. Technology debt) och Teknisk skuld (eng. Technical debt). Det bredare begreppet kring teknikskuld som innefattar såväl personal (ideologi, kompetens, arbetsmiljö), användare (nöjdhet, rykte) och system (infrastruktur, skugg-it, teknisk, styrning) kan även ackumulera skuld på samma sätt som teknisk skuld gör vid exempelvis bristande kvalitet i konstruktion av programvara. Väldigt användbart för att hantera såväl risker som nyttorealisering och skuldsanering, ser fram emot mer insikt i denna forskning.

Att automatisera, optimera och integrera leveransprocessen är utmanande, men om inte snabbt införande prioriteras kommer det inte heller att gå snabbt, likaså är avsaknad av inbyggd kvalitetshantering det säkraste sättet att erhålla dålig kvalitet och en stor dold skuld med ockerränta. Genom att kontinuerligt värdera nya insikter och vikta dessa mot baslinjen så kan man istället undvika onödiga problem och säkerställa bra och friska nyckeltal.


Under ett seminarium om Continuous Delivery och Azure Camp hostade av Microsoft och Solidify så förkovrade jag mig i det senaste nyheterna kring vad som hänt på ALM frontlinjen under hösten.  En lång rad nyheter presenterades, men för mig så var de en sak som sken upp mer än de övriga.

Äntligen, nu har TFS fått stöd för Markdown-filer (.md). Även om det än så länge bara finns stöd i Visual Studio Online (VSO, TFS i molnet) så är detta något jag sett fram emot länge då det underlättar avsevärt för dokumentationsrutiner. Genom att skapa vanliga textfiler med några får fördefinierade syntax så formateras .md filerna om till Markup-filer, vanligtvis HTML. På detta minimalistiska sätt så får man ett enhetligt format och kan länka in bilder, tabeller och hyperlänkar direkt i samma kodmassa som då kan utvecklas parallellt med alla förgreningar och versionshantering av koden.

Det finns en del verktyg för att hantera .md filer även utanför utvecklingsmiljön, som exempelvis http://markdownpad.com där man ser hur resultatet ser ut samtidigt som man skriver.

Möjligheterna är många för denna nya funktion och helt klart ett stort steg åt rätt håll, även om jag kan sakna många av de bra funktionerna som erbjuds i exempelvis DokuWiki, så applåderar jag för införandet av .md filer i TFS. På sikt hoppas och tror jag vi får se både Microsoft och community utvecklade förbättringar kring syntax och integrationer av Markdown-filer.

Microsoft, snyggt jobbat!

 


Tittar man på ett historiskt perspektiv kring systemutveckling så ser man att det har hänt mycket kring antalet roller och verktyg som är involverade under hela livscykeln. Mängden kommunikationsvägar  har samtidigt ökat radikalt, det är betydligt fler specialister med i utvecklingsprojekten än tidigare och det blir därmed svårare att avläsa status då det behövs aggregeras data från fler källor än tidigare.

kommunikationsvägar systemutveckling alm

Det är kanske inte så ovanlig att specialister vill ha de bästa verktygen för just den specialiseringen man nischat in sig på, som exempel så vill ju gärna testproffs använda sig av Test Management verktyg och programmerare vill ju gärna ha effektiva källkodshanteringssystem. Börjar man lista dessa specialist system så blir det snart en gedigen lista och det är inte alltid så lätt att få dessa system att kommunicera med varandra utan manuell handpåläggning.

Det finns en formel för att räka ut hur många kommunikationsvägar som finns givet antalet kommunikatörer, formeln är n*(n-1)/2 och används ofta inom projektledning för att räkan på hur många kommunikationsvägar som måste hanteras. Som exempel så kan vi tänka att ett systemutvecklingsprojekt består av 10 personer så blir kommunikationsvägarna mellan dessa 10*9/2=45, alltså kan kommunikationen färdas på 45 olika vägar.

Denna formel går även att applicera på verktyg som systemutvecklare behöver använda för att bedriva effektiv systemutveckling. Om vi tänker oss att det finns 10 olika verktyg för systemutveckling (så som verktyg för programmering, källkodshantering, dokumentation, rapportering, krav, test, arkitektur, tidsrapportering, bygghantering och drifthantering) då blir även detta 45 olika vägar som information kan tänkas behöva flyta för att få effektivitet i flödet. Enligt min erfarenhet så är det inte så många organisationer som lägger samma vikt vid denna typ av kommunikationsvägar som i projekten, men det borde man för det minimerar waste (se Lean) och förbättrar kvalitet på resultatet. Detta argument är centralt i ALM (Application Lifcecycle Management) verktyg, där fokus är att länka samman alla verktyg och underlätta för hela systemutvecklingsflödet både mellan människor i sociala relationer och mellan verktyg och informationsflöden däremellan.

Är man ansvarig projektledare för ett större systemutvecklingsprojekt och får den vanliga frågan ”Hur går det?” så blir ju svaret ofta ett konsultsvar – Det beror på…
Det är ju så många olika saker som väger in och det är ofta svårt att få insikt om hur det faktiskt går vid en given tidpunkt och ibland kan det faktiskt vara så illa att man inte ens har möjligheten att införskaffa sig insikt då det är för många kommunikationsvägar som saknas eller inte är kompatibla.

 
Vi vill ju ofta arbeta mer agilt och i många kortare iterationer vilket är bra då man efter varje cykel kan avgöra om man behöver ändra riktning. För att denna process skall fungera optimalt så behöver även verktygen samspela effektivt över hela applikationen så det inte uppstår köbildning i någon instans där informationsflödet kan komma ur synk. Genom att samordna verktyg och processer för att aktivt hantera alla kommunikationsvägar över hela applikationslivscykeln så faciliteters även de sociala kommunikationsvägarna.