ADDERA nr 1 2015 årgång 5 by AddivaAB

ADDERA

NR 1 2015 · ÅRGÅNG 5 · UTGES AV ADDIVA

Addiva förvaltar mjukvara s. 4 Vi berättar om vår process för förvaltningsuppdrag

Applikationsutveckling med MVVM s. 9 Separera programlogik från presentation genom MVVM

UWB radar s. 12 Addiva och Melika forskar på Ultra Wide Band Radar

ADDERA Address Kopparbergsvägen 8 722 13 Västerås

Telefon 021- 471 21 30

VÄLKOMMEN TILL ETT NYTT NUMMER AV ADDERA.

Hemsida www.addiva.se

Ansvarig utgivare Pamela Christensson pamela.christensson@ addiva.se

Grafisk form Victoria Ben-Chivar

Foto

i har påbörjat en förändring av layout och hoppas att du gillar det. Detta

nummer ska spegla vad vi gör, ta upp intressanta tekniker och tankar kring framtiden.

I detta nummer kommer du att kunna läsa om Ultra Wide Band-teknologi och radar samt metoder för att utnyttja kraftöverföringskapacitet så effektivt som möjligt. Tekniklösningar som förfinas och kan användas på innovativa sätt i framtiden. Du får även en inblick i applikationsutveckling med MVVM och app-utveckling samt olika plattformar beroende på vilka krav som ställs på appen.

Victoria Ben-Chivar

Skribenter Arman Bolourian Daniel Kling Daniel Söderholm Jesper Söderlund Kjell Iwarson Magdalena Bozyk Melika Hozhabri Pamela Christensson Robin Persson Thomas Wilen

Tryck

”Addiva Tour” är en rundvandring på vårt kontor där du som besökare får lyssna på och se de olika inhouse-projekt som vi arbetar med just nu. Alla projekt drivs via vårt Project Management Office (PMO), där vi arbetar vi med olika metoder för effektivare utförande. Allt från att förstå gruppdynamik, beteenden till inofficiella roller som är viktigt att hantera både som projektledare och som projektmedlem. Vi berättar även om hur vi använder Prince 2 metodiken för projektledning, ofta i kombination med Scrum. Du får en beskrivning av de sju principerna för Prince 2 för att ge en förståelse till varför vi använder denna metod samt en introduktion till TFS och versionshantering. Sen presenterar vi förstås nya medarbetare på Addiva. Trevlig läsning!

Navii

“LOREM IPSUM DOLOR” CARINA WIGHOLM VD Addiva AB

Innehåll Addivas process för förvalting av mjukvara

Visste du att... 5 TFS and Git code

Prince 2 Principles

Utveckling av applikationer med MVVM

Förbättra verkligheten med Microsoft

Ultra Wide Band-teknologi och radar

Addiva-tour

Congestion management

Profilanalys för bättre projektsamarbeten

Mobilutveckling och App-utveckling 19 Inofficiella roller i projekt NYA PÅ ADDIVA Julbordet

ADDERA

ADDIVAS PROCESS FÖR FÖRVALTING AV MJUKVARA Addivas produktförvaltning ger en stabil plattform att stå på när vi tar hand om en produkt. Det gör det möjligt för kunden att fokusera på affären och utveckla affärsverksamheten.

Möjlig leverans

Krav och Arkitekt ur

arje produktförvaltning består av ett produktteam som är anpassat till storleken på produkten. Ett produktteam består normalt av:

Nya tjänst

Drift och support

Aﬀärs beslut

MÅL FÖR CLOUD SERVICES

• • •

Projektledare, kravhanterare Systemarkitekt Utvecklare, Testare Support personal

Cloud services Fas 3

Nya tjänst

Bas plattf

Aﬀärs beslut

• • • •

Cloud services Fas 2

Cloud services Fas 1

Besl uts-

Möjlig leverans

• • •

Fokus på affären Skapa förutsättningar för utökat tjänsteutbud Kontrollevrad tillväxt genom skalbarhet Positiv upplevelse för kunderna Skapa ett handlingsutrymme genom bättre resultat Leveranstrygghet och kvalité

Produktförvaltningen omfattar • Produktunderhåll • Utveckling • Support • Drift • Utvecklingsmiljö och licenser • Metodstöd och verktyg för projekt samarbete

ADDERA

Det är vanligt förekommande att kostnaden för en produkt över livscykeln är konstant. En föråldrad arkitektur som inte är anpassad till aktuella affärskrav är en vanlig orsak.

Addiva inför en effektivisering av hela produkt utvecklingscykeln. Leveransen blir en produkt som är anpassad till affärskraven. Kostnaderna för underhåll minskas samt att kostnad för resurser mellan utvecklings faserna minskas.

Text: Pamela Christensson

VISSTE DU ATT… … loppor kan hoppa 350 gånger så långt som sin kroppslängd? ... ljud färdas 4 gånger snabbare i vatten än i luft? ... den enda bokstaven som inte finns i det periodiska systemet (förutom å, ä och ö) är bokstaven J? ... Jordens genomsnittliga hastighet i omloppsbanan runt solen är 107,220 kmh?

TFS AND GIT CODE REVIEWS One of the major features in TFS 2013 Update 4 CTP1 is the ability to create pull requests when using Git. This article will explain how the pull request feature is used for its intended use of performing code reviews on feature branches. But first we will start with some basic introduction to TFS and version control just to make sure that everyone reading this article may feel comfortable with what we are talking about.

eam Foundation Server (commonly abbreviated to TFS) is a Microsoft product which provides source code management (either via Team Foundation Version Control (TFVC) or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, lab management, testing and release management capabilities. It covers the entire application lifecycle. TFS can be used as a back end to numerous integrated development environments but is tailored for Microsoft Visual Studio and Eclipse (on Windows and non-Windows platforms).

» Team Foundation Server (commonly abbreviated to TFS).

VERSION CONTROL 0.3

MASTER

0.4

There are a lot of different approaches to the problem of version control (VC). The simplest and sadly the most common way are to simple do this manually by copying files into time stamped backup folders. For any serous work such a manual VC approach will soon be incredibly error prone. The amount of copies of files will soon be so many that accidents are prone to happen.

Release 0.3 Release 0.4

DEVELOP Iteration 1

Feature A

Iteration 2

Feature B

Iteration 3

Feature C

Master branch

Develop

Feature branch

Release branch

Unlimited lifespan Stable code Tagged version numbers Limited PUSH

Unlimited lifespan Integration code Nobody commits here Never merged

Limited lifespan Feature specific code Branched from Develop Merged into Develop

(Limited lifespan) Prepare Stable Release Branched from Develop Merged into Develop and Master

» The picture illustrates an example on how versioning can be structured with a VCS. The master branch, also called trunk, contains the stable/released versions of the code. The development branch is the main branch for the develop-

VC becomes even more challenging when it comes to versioning files containing source code, since every change may cause a lot of things to a program or application. So for decades developers have used and improved on what we now call Version Control Systems (VCSs), for keeping track of changes to files.

ment team. Actual development is done on a feature branch, while bug fixes is done directly on the release branches. » The colored dots on the lines symbols changes in one way or form.

ADDERA

TFS (Team Foundation Server) is developed by Microsoft and have become very popular since it integrates with Microsoft’s development environment Visual Studio. TFS also provides VC in the form of Microsoft’s own TFVC (Team Foundation Version Control). But the restrictiveness of TFVC and the popularity of the brilliant way the Linux community have solved the VC problem with it’s Git distributed VCS, Microsoft announced on Wednesday Jan 30 2013 that they would include Git in TFS 2013. This was part of Microsoft attempt to interest embedded developers, people working in distributed teams, especially the huge open source arena, to Microsoft’s integrated development environment Visual Studio and TFS. However they failed to include support features for code reviews using Git up until November 12 2014 and the TFS 2013 update 4 release.

CODE REVIEW In its simplest form, a code review is whenever we take a look at source code and give feedback to whomever are interested in the same code. Formally I will just refer to the following quote from Wikipedia.

indeed it is convenient to make reviews on strategic changes to the code rather than on the complete code base. Fore example, if we delegate someone in our team to implement a certain feature it would be brilliant if we could review just the code for that feature when it is done. This is what we can use VCS for.

“Code Review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.” [Wikipedia] I wont dive into specifics on code review strategies in this article. The important thing is to understand why code review can be improved by version control. A modern VCS intended for versioning source code will also address the problem of visualizing the changes that has been made to any file under version control. Since reviewing code is costly

» Pull Request from a maintenance branch to the master branch.

TFS PULL REQUEST Let’s say our resource could request a code review when the feature he is working on is thought to be complete. Let’s imagine that we could perform our review in a forum like webpage and that our comments and feedback can be discussed back and forward by all the team members. Thus improving both the implementation of the feature and the knowledge of its implementation to every one involved in the discussion (Code Review). This could then be integrated with the development process and the VCS so that when a feature gets approved by the Code Review it will be included (merged) to a more stable version of the code.

Robin Persson

ADDERA

Request from a maintenance branch to the master branch. The team can easily review the code before it is merged to the master branch. When working in teams the pull-request feature enhances the feeling of code control, and contributes greatly to both the quality of the code and the sharing of development skills among team members. Text: Robin Persson

This is exactly what pull requests in TFS Git repositories is all about. In the example above we have a Pull

PRINCE 2 PRINCIPLES Addiva are using the Prince 2 methodology for project management, often in combination with Scrum. In order to raise the knowledge of Prince 2 this article will describe the 7 principles of Prince 2, to give an understanding of why we use it. 1.

The principle Continuous business justification means that there is a focus on the Business case throughout the project. Verify that the benefits still are worth the risk and cost for the project. The Business Case is the most important document, and is updated at throughout the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case. 2.

logs items that can be good to know later and for other projects. The “lessons log” are used within a project and are delivered to the corporate management at the end of the project. The reason for the lesson log is to ensure that discovered pitfalls can be avoided in the future.

PRINCIPLE - CONTINUOUS BUSINESS JUSTIFICATION

“Defined roles and responsibilities” defines that each person involved in the project are aware of what is expected from he or she. Prince 2 has 3 levels of management within the project management team.

PRINCIPLE - MANAGE BY EXCEPTIONS

The managers (team manager, Project manager) has a mandate to act upon issues, risks and budget changes up to a certain limit without disturbing the Project Board. These limits are decided by the tolerances of the project. The tolerances for the project are set by the corporate management and act as a higher and lower limit for time, cost, quality, etc. The reason for this is to relief the Project board and other stakeholders from being disturbed with minor issues. In practice this means that the project manager can extend the deadline for the delivery up to 2 weeks, if the project has a tolerance in time +2 weeks. 3.

•

Project board which consists of the following roles: 1. Project Executive – Responsible for the project, represent the business objectives in the project. 2. Senior supplier – Responsible for: Can it be done? 3. Senior User – Responsible for: Will it work?

PRINCIPLE - LEARN FROM EXPERIENCE

To prevent each project for doing the same mistakes Prince 2 has a principle called learn from experience. In practice this means that each project has a lessons log that

PRINCIPLE - DEFINED ROLES AND RESPONSIBILITIES

•

Project manager which are responsible for communication, progress, quality, cost management etc. for the project.

•

Team Manager which are responsible for producing products assigned as work packages.

PRINCIPLE - MANAGE BY STAGES

Prince 2 are monitored and con-

Jesper Söderlund

trolled on a stage by stage basis. To ensure that plans only has a manageable and foreseeable level of details the plans are recommended to be divided into 3 levels of plan. First the project plan which are made in the beginning of the project, then the Stage plan which are done close to the beginning of a stage, and then the team plan which are produced by the team manager, and includes only the work packages to be delivered within this stage. There are a minimum of 2 stages in prince 2, first the initiation stage and then 1 or more implementation stages. In the last stage will also include the producing of the end project report. After each stage the project board will verify the stage plan, and validate that the project are business justified. The project board has a default no go and must verify that the project still is viable. ADDERA

“PRINCE 2 METHODOLOGY FOR PROJECT MANAGEMENT”

PRINCIPLE - FOCUS ON PRODUCTS

Prince 2 uses a product based approach which provides awareness of the purpose of each product, how it will be composed and the quality expectations. For each product a Product Description are assembled which describes the purpose of the product, quality criteria’s, methods for how the quality will be checked, estimations for work, resources and activities.

PRINCIPLE - TAILORING

Prince 2 should not be applied as it is, it should be tailored to the project/organization’s needs. The tailoring should consider the project environment, size, complexity, importance, capability and risks. Text: Jesper Söderlund

UTVECKLING AV APPLIKATIONER MED MVVM Det är i dag, och har varit i många år, en vedertagen branchstandard inom applikationsutveckling att använda sig av någon typ av arkitekturell lösning för att separera presentation (UI), presentationslogik och affärslogik från varandra. De fördelar man uppnår genom att separera programlogiken från presentationen är främst: •

•

Förbättrad möjlighet till testning. Genom att separera ut interaktions och datalogik till ett objekt som är separat från UI definitionen så kan man enhetstesta den logiken. Det blir lättare att återanvända koden. I många fall kan presentationslogiken återanvändas för olika visuella presentationer av samma data. Koden blir lättare att underhålla. Mjukvara med väl separerade och distinkta ansvarsområden leder till högre möjlighet att att förändra eller underhålla mjukvaran utan oönskade sidoeffekter.

Det finns flera sätt att uppnå en sådan separation. Ett av dem är designmönstret MVVM, Model-View-View Model. Den ADDERA

här artikeln syftar till att ge en översikt över MVVM, samt ge några tips på teknologier som kan underlätta implementationen.

HISTORIA Ett av de tidigaste designmönstren för separation av UI, data och logik heter PM, Presentation Model och introducerades av Martin Fowler. Från detta ursprungliga mönster har ett flertal mer specialiserade mönster uppkommit. De mest traditionellt kända är MVP (Model-View-Presenter) och MVC (Model-View-Controller). För båda dessa mönster är det Presenter/ Controllers ansvar att vidarebefordra användarinteraktion och dataförändringar mellan UI och modell. De största problemen med dessa lösningar har varit att en stor del av koden har varit till för att synkronisera data och interaktion mellan UI och modell, och stor del av denna är repeterad kod med endast små skillnader

för anpassning till vilket UI element som behövs synkroniseras. Lösningen för att slippa handkoda synkronisering av data och kommandon är MVVM mönstret, som inför begreppet Binder för automatiserad bindning av UI element till data.

MVVM MVVM är förkortning för ModelView-ViewModel och är ett arkitekturmönster framtaget av Micrsoft för deras .NET WPF/Silverlight applikationsplattform, baserat på MVC mönstret som introducerades av Martin Fowler. Namgivningen på mönstret leder ofta till förvirring och missuppfattningar brukar uppstå vad det gäller ordningen på de inblandade objekten. Den korrekta ordningen borde vara, uppifrån och ned i en ”lagermodell”, View-View ModelModel. En mer korrekt akronym skulle således kanske vara VVMM.

Mönstret togs fram för att bland annat få bort det onödiga skapandet av kod för att synkronisera data och kommunicera mellan View (UI) och View Model, och i stället låta generellt beteende i ramverket lösa dessa problem. MVVM består av dessa delar: •

View: Användargränssnittet, UI

•

View Model: Data-abstraktion av vy, anpassninslager mellan View och Model

•

Model: Domänmodell och/eller Data Access Lager, domänlogik och domändata

•

Binder: Databindning, mekanik för att deklarativt koppla element i UI till data i ViewModel.

•

View-ViewModel komposition: Sammankoppling i runtime mellan en viss vy och vymodell.

View (UI) Presenta on (UI) & Presenta on Logic View Model

Business Logic & Data

nedom om Model lagret utan att det går emot reglerna. Notera att man i bilden även tillåter indirekt koppling via databindning från View till Model. Detta kan tillåtas för att binding teknologin inte beror på hårda typkopplingar nedåt, utan skall arbeta med meta-data såsom namn på egenskaper och kommandon.

MODEL Implementationen av Model-delen har inte så mycket att göra med MVVM, men typiska arkitekturella lösningar är att använda en objektcentrerad lösning med Domän Modell, eller en datacentrerad lösning med ett Data Access Lager, eller en kombination av båda. Huvudprincipen i MVVM för att uppnå isärkoppling View – View Model – Model är tumregeln ”never look up”. Om man ser hela MVVM enligt tidigare bild så innebär detta att View Model aldrig får ha någon kännedom om vilken View den används i och Model får inte ha någon kännedom om View Model. View måste ha kännedom om View Model, men med hjälp av Binder så behöver den inte ha konkret kännedom om typen av View Model utan enbart känna till gränssnittet som View Model implementerar. View Model kan ha obegränsad kän-

Model

» Figur 1: MVVM

Mönstret har även överförts till webutveckling, då det med senare tids större fokus på komplicerade webklientapplikationer blivit nödvändigt att strukturera upp även dessa för att kunna uppnå ovanstående önskvärda mjukvaruegenskaper.

Thomas Wilen

Data Binding

DATASYNKRONISERING Datasynkronisering och vidarebefordring av användarinteraktion mellan View – View Model sköts med hjälp av databindning. Man beskriver i UI-koden vilket data ett UI element skall kopplas till varpå Binder-teknologin ser till att förändringar i data kommuniceras upp till vyn och att användarinteraktion kommuniceras ner till ViewModel. I WPF lösningar används den inbyggda Binding-modellen för detta ändamål genom att i XAML deklarera en Binding

till en angiven property i ViewModel. Det finns även andra lösningar för att binda samman vyelement och ViewModel. Till exempel använder Caliburn Micro namnet på vyelementet för att binda elementet till data. För webklienter i HTML och JavaScript finns ett antal frameworks för vykomposition och databinding, såsom KnockoutJS som enbart hanterar databindning, och mer avancerade frameworks som Durandal och AngularJS som även hanterar View-ViewModel komposition.

AVSLUTNINGSVIS Detta är inte en på något sätt uttömmande artikel om MVVM eller en lösning på hur man enligt best-practices skall implementera en applikation i dag, men jag hoppas att den gett dig en liten insikt om vad MVVM innebär och några ledtrådar som kan leda vidare till mera information. MVVM skall kanske heller inte ses som allenarådande lösning på hur man skall konstruera applikationer, den har dock visat sig ha fått starkt fotfäste vid utveckling av såväl små konsumentapplikationer som tunga affärsapplikationer inom branschen. Omfattande stöd för ramverksutveckling av MVVM implementationer kan också ses, speciellt inom Webutvecklingsområdet där företag med stora resurser som Google och Microsoft är med och utvecklar och stöttar Open Source projekt. Text: Thomas Wilen ADDERA

FÖRBÄTTRA VERKLIGHETEN MED MICROSOFT Under en presskonferens för Windows 10 som hölls den 21a januari avslöjade Microsoft ett antal nya produkter, däribland Hololens.

ololens är ett headset med inbyggda glasögon som skapar tredimensionella objekt och projicerar dem i den verklighet användaren ser. Till exempel kan mjukvara identifiera bordsytor och väggar och placera virtuella objekt på dem, som tv-skärmar eller kalendrar. Användaren kan sedan interagera med dessa objekt genom röst- och rörelsedetektorer. Hololens kräver ingen koppling mot en fristående dator, istället är all hårdvara inbyggd direkt i headsetet som kommer köra Windows 10. Produkten är del av en större satsning som Microsoft kallar ”Microsoft Holographic”, ett initiativ företaget menar kommer smälta samman den digitala och den fysiska världen på ett helt nytt sätt. I den demonstrationsfilm Microsoft släppte i samband med presskonferensen kan användare ses titta på Netflix på en virtuell TV som ritats upp på väggen. TVns storlek kan skalas om med en lätt handrörelse. I en annan scen sitter

förväntningar som Microsofts marknadsföring bygger upp kan detta verkligen vara det första steget in i en ny framtid. Samtidigt finns så klart några orosmoln. De senaste åren har vi sett många försök till rörelse- och röststyrning, inte minst i form av Microsofts egna Kinect, vilket även Hololens bygger på. Inget av de försök som har gjorts har dock fungerat på ett tillfredsställande sätt och fortsätter den trenden kommer Hololens bli ett frustrerande verktyg att arbeta med. Så klart vet Microsoft om detta och arbetar hårt för att komma runt de problem som finns idag. Om de lyckas får framtiden utvisa. Daniel Kling en kvinna och arbetar på en 3D-modell av en motorcykel och kan samtidigt se samma motorcykel stående på skrivbordet bredvid sig. Om Hololens kan leva upp till de

I dagsläget finns varken prisuppgifter eller releasedatum, men en version för utvecklare att börja experimentera ska finnas tillgänglig till hösten 2015 och redan till sommaren ska prototyper göras tillgängliga för NASA för att underlätta deras arbete. Text: Daniel Kling

LITE SKÖJ: ADDERA SERIE

Illustration: Kjell Iwarson ADDERA

ULTRA WIDE BAND TEKNOLOGI OCH RADAR

Traditionella radarsystem skickar signaler i ett smalt och specifikt frekvensområde medan ett UWB-system sänder signaler över ett mycket bredare frekvensområde (>500 MHz). Enligt UWB-definitionen borde den relativa bandbredden vara större än 25 procent av centerfrekvensen.

adar är baserad på att elektromagnetiska vågor reflekteras när de möter ett objekt och därefter återvänder till platsen för deras ursprung. Den tiden det tar för vågen att komma tillbaka avslöjar målets position genom att den elektromagnetiska energin färdas genom luft med en närmast konstant hastighet, vilken i stort sett är ljusets hastighet.

TEKNIKEN Den mest använda UWB-signalen är pulser med väldigt kort längd (1 ns) i ett pulståg. Ibland är pulstågen modulerade så att de kan överföra information eller en specifik kod. Ett sätt att generera pulståg är att använda M-sequence (maximum length sequence). M-sequence är en pseudoslumpartad binär serie. I radarapplikationen jämförs den sända signalen med den mottagna signalen matematiskt, med hjälp av en korskorrelationsfunktion, för att estimera målet position.

Avstånd till målet kan därmed beräknas så här: Tiden det tar för vågen att komma tillbaka (time of flight) delas med två och multipliceras med ljusets hastighet (300,000 kilometer per sekund).

ADDERA

Med radiosändning reflekteras signalerna av ett föremål och resulterar i olika radiosignalvägar. Till exempel kan en signal studsa på en yta för att komma fram till mottagaren senare i tiden. Sådan oönskad studs stör radioöverföring som går direkt från sändaren till mottagaren. Med frekvensbaserade sändningar superpositioneras sinusvågorna på mottagarantennen och gör det svårt eller omöjligt att urskilja den direkta överföringsvägen från de reflekterade vägarna. Detta kallas “multi-path fading” och “multi-path interference”.

Direkt sändning mellan sändare och mo agare(A) Önskad Re ek on(B)

Mul path(C)

Amplitud

A B

Tid

En av de värdefulla aspekterna av UWB-radiotekniken är möjligheten för ett UWB radiosystem att bestämma “Time of Flight” av den direkta vägen för radioöverföringen mellan sändare och mottagare. Med UWB-sändningar kan tidskodningen slumpvis skicka en signal och mottagaren kan sedan avgöra vilken som är den direkta vägen. Med ett dubbelriktat system eller ett radarsystem kan detta avstånd bestämmas mycket mer exakt.

UWB-radar kan tillhandahålla millimeternoggrannhet. Några exempel är: 1.

Att bevaka människor hemma med kameror kan vara integritetskränkande, även om det är av medicinska skäl. Med hjälp av UWB radar kan man upptäcka om en person rör sig eller andas dygnet runt.

Att skapa en skyddszon runt om farliga maskiner eller robotar. Då kan människa och robot arbeta ihop utan att behöva bygga upp burar runt omkring maskiner eller riskera liv.

ANVÄNDNINGSOMRÅDEN •

Att se igenom saker: 1.

Existerande lösningar för att rädda folk, till exempel under kollapsade byggnader, kan idag vara kameror med långa fibrer som skickas in i rasmassan. Dessa har svårt att exakt avslöja människans position. Räddningshundar är en annan lösning, men de kan dock inte urskilja levande människor från döda. Här kan UWB-radar vara ett bra alternativ eller tillägg till existerande lösningar genom att den kan upptäcka andning eller hjärtrytm tack vare sin millimeter-precision och förmåga att penetrera byggnadsmaterial(3).

Melika Hozhabri •

•

Dataöverföring: På grund av den extremt låga uteffekten fungerar UWB-system på korta avstånd. Därmed, på grund av den korta pulslängden av UWB pulser, är det möjligt med extremt höga datahastigheter. Den kan användas till att överföra stora datamängder som t.ex. trådlös bildskärm. Positionering och målföljning: Att positionera inomhus har blivit allt mer attraktivt de senaste decennierna. Men den teknik som ligger närmast till hands, GPS-tekniken, är ofta inte tillgänglig i den aktuella miljön eller så är den inte tillräckligt noggrann.

•

UWB, skilt från kameror, fungerar i alla ljusförhållanden och är väldigt robust i olika väderförhållande.

•

Olika material reflekteras och absorberas av elektromagnetiska vågor på olika sätt. Det gör att man med hjälp av UWB radar kan urskilja olika material från varandra. Den har används i t.ex. detektion av bröstcancer(4). Text: Melika Hozhabri

Källor 1. Wolff Christian . 1998. Radar Principle. http://www.radartutorial.eu/ (Hämtad 2015-01-31). 2. M.G.M. Hussain, “Ultra-Wideband Impulse Radar-an Overview of the Principles,” IEEE Aerospace and Electronics Systems Magazine, Vol. 13, Issue: 9, pp. 9-14, September 1998. 3. Egor Zaikov and Juergen Sachs (2010). UWB Radar for Detection and Localization of Trapped People, Ultra Wideband, Boris Lembrikov (Ed.), ISBN: 978-953-307-139-8, InTech, http://www.intechopen.com/books/ultra-wideband/uwb-radar-for-detection-and-localization-of-trapped-people4. A. Lazaro, D. Girbau, and R. Villarino, “Wavelet-based breast tumor localization technique using a UWB radar,” Progress In Electromagnetics Research, Vol. 98, 75-95, 2009. 5. Imran Mehmood & Shoaib Amin, June(2011). Detection Of Multiple Targets Using Ultra-Wideband Radar, Examensarbete Vid Gävle Universitet Och Radarbolaget AB.

ADDERA

ADDIVA-TOUR

ddiva har flera projekt som vi arbetar med ”inhouse”, det vill säga på vårt kontor. Under åren har vi märkt att våra kunder alltmer efterfrågat en lösning, snarare än en person att arbeta på plats hos dem. Vi har då anpassat oss efter önskemålen och har idag blivit en partner att räkna med. Vi har de processer (läs mer om en del av våra processer på sid 4 och 8) som krävs och förändrat organisationen till att klara av att leverera projekt i tid till våra kunder. Vi vill här ta dig igenom vårt kontor och berätta lite om vad vi gör just nu.

Addiva fungerar som en extern utvecklingsavdelning till ett företag som tillverkar lyftok för fraktcontainrar. Där arbetar vi med att utveckla den elektroniska styrenhet som kontrollerar lyftokets hydraulik. Vi tar fram kretsschema, kretskortslayout, mjukvara, samt testrigg för löpande funktionstester av kretskorten.

Addiva har utvecklat ett beräkningsverktyg för att räkna på fuktig luft genom värmeväxlare. Vi har även bidragit med beräkningsarbete. Verktyget är webbaserat och används av ingenjörer och säljare för kundens produkter. För att hålla reda på komplexiteten av produkterna så har vi även levererat ett produkthanteringsverktyg.

Vi har utvecklat ett finansiellt system för aktieanalys. Nu underhåller och förvaltar vi produkten som har ett par tusen användare. Systemet visar signaler för köp och sälj för varje aktie som finns på börsen. Underliggande finns avancerade beräkningar för att generera köp- och säljrekommendationer.

ADDERA

Vi har utvecklat ett webbaserat diagnostiksystem från grunden. Vi utvecklar, underhåller och driftar systemet och supportar användare. Systemet registrerar avvikelser och identifiera fel – förhoppningsvis innan någonting allvarligt inträffar. De tåg som levereras följs upp på ett sätt som optimerar underhållet och undviker tågstopp med hjälp av statistik och visualiseringsteknik. Förutom hos producenten används systemet även av tåganvändare, men marknaden är betydligt större än så; problemen som adresseras är lika vanliga här som i Amerika eller Asien. Systemet är lämpligt för andra typer av anläggningar.

Addiva utvecklar och underhåller ett integrerat data management system. Systemet innehåller all information kundens komplexa produkter. Den integrerar med flera avdelningar gällande, RAM, LCC och dokumentation. Systemet används bland annat för att kunna räkna på kostnader i samband med offerter, garantier med mera.

Vi utvecklar beräkningsverktyg och system som används för att dimensionera kundens elkraftsanläggningar.

Våra 800XA experter stöttar kundens team med kvalitetssäkring av leveranser av kraftanläggningar offshore.

Vi utvecklar en plattform som används av kundens säljare och kunder. Företaget i fråga har en mycket stor produktportfölj och ett stort antal kunder globalt. Plattformen är integrerad mot ett antal backendsystem såsom produkthantering, CRM, lagersystem mm. Samt innehåller en konfigurator som vi utvecklat. Säljare och kunder använder systemet för produktsök, pris- och lagerinformation och teknisk produktinfo. Funktionalitet finns även för att generera CNCkod för kundens bearbetningsmaskiner.

ADDERA

CONGESTION MANAGEMENT Congestion in the deregulated power market and constrained power grid is the power demand above the transfer limitation and indicates the needs of power generation or transmission expanding. Congestion or bottlenecks don’t occur just because of poor generation in the certain geographical location, the model of trading which shaped by supply and demand can result the congestion too.

ongestion management leads us to obtain the highest economic solution. Several methodsor combinations of them can be used in the power market to obtain desired solution. The aim is to utilize power transmission capacity as efficiently as possible. In deregulated power market, congestion occurs when producers or consumers longing to transmit electricity at or away from the transmission physical, policy or operational constraints. Congestion can arise in normal operation and even in fault condition. The way to manage this violation is congestion management. From the nineties decade, the competitive deregulated power market has changed the old business instruction and the multiplicity of the generation, transmission and distribution intensity, make a lot of difficulty of the congestion management.

In power market, constrains leads the higher marginal cost of electricity and reduce safety and reliability. Congestion management removes the exceeded power flow above the limitations and provides the most economic and reliable power flow to consumers. The goals of congestion management can be, provision the optimal capacity power to market participants by consideration and fulfilling the security constraint’s requirements or managing the existing or predicting future congestion. Continual

“CONGESTION OR BOTTLENECKS DON’T OCCUR JUST BECAUSE OF POOR GENERATION.” congestion indicates the needs of more transmission lines and generators. Congestion management performs by independent system operator (ISO). Different methods can be used to manage congestion in different markets and utilities. For example the use of FACTS devices and use of tap changers or the use of market base management for instance market splitting, locational marginal pricing, counter trade, and financial transmission rights and some other methods.

Arman Bolourian

Different countries and regions in deregulated power market can have different adapted methods of congestion management, it depends on for example

the industrial development, political decisions, environmental constrains and other factors. There are several methods of congestion managements in deregulated electricity for example:. • Implicit auction • Explicit auction • Using FACTS devices • Market splitting • Counter trade • Locational marginal pricing (LMP) Some combinations of the mentioned methods above can be applied in order to handle congestion problem in the deregulated power market. Investigations are ongoing and it will be possible to have even more and complicated congestion management methods in the future. Usually some congestion management methods or the combinations of methods use to satisfy participants in the market and reduce congestion risks in transmission lines. The choice of these methods and implementation can be differed in the countries or regions. For instance, some technical reasons such as electricity demands, generations’ capacity or transmission lines capacity and other reasons which are not related to the technical issues, such as political decisions or environmental constraints will influence the choice of congestion management method. In this article “Market Splitting” method is explained as an example of congestion management method.

ADDERA

MARKET SPLITTING In this method to manage congestion, system will divide into separated bid areas and these areas will connected by corridors. First scenario, both bid areas act as spot electricity market, hence bid their sell and buy their adjusted price then submit it. ISO will calculate electricity price for sell and buy bids and the price for each bid area will be the same until it exceeds limitation. Second scenario, if transmission of electricity exceeds constraints, these two bid areas will have separated electricity price. Limitations of the power transmission in each transmission line and congested lines will be recognized by ISO.

For more clarity two areas, A and B have been considered here. Area A, is surplus generation area and area B, is deficit generation area. When there is no congestion, the total generation will be equal to the total demand and the price for both areas is the same ρ_A = ρ_B= ρ. When congestion occurs, the total generation and demand differs from each other and the Relations in (3) are valid. GA = D A + Pm (3) GB = DB – Pm Where, Pm is the transfer capacity which directed from surplus generation area (A) to deficit generation area (B). Pm represents also, the ISO purchasing from the low price area A and then selling to the high price area B. in order to obtain net operators revenue, the price differences for per MWh in two areas will multiply to transfer capacity. The strategy of this method is, persuading and courage consumers to buy electricity from the generation surplus areas which leads to manage congestion problem. Consumers benefit from this low price energy but it doesn’t mean generators lose their profit.

In market splitting method when congestion occurs, price in the area which has surplus generation capacity or export electricity, is lower than area which imports electricity. In the area by surplus generation, price of electricity will be calculated as relation in (1). Loads will benefit in the areas by surplus generation. ρ_( area)^( low) =ρ_m- ρ_cap (1) In the generation deficit area when congestion occurs, price will be determined as relation in (2). Generators benefit in this situation. ρ_( area)^( high) =ρ_m+ ρ_cap (2) ρ_m represents the price in the pool market without congestion, ρ_cap is the capacity fee dedicated by ISO.

This lower cost of electricity price, courage consumers to buy high quantity electricity from generation surplus areas and at the same time, it leads generators to benefit by selling higher quantity of electricity. For example in Nordic countries, this congestion management method is used between Sweden and Norway. For more clarity, area price calculation have been illustrated in the following figure, the revenue of market operator is (ρB – ρA) × K, where K represents interconnector capacity and is equal to (PB – P’B = PA – P’A). Text: Arman Bolourian

ADDERA

PROFILANALYS FÖR BÄTTRE PROJEKTSAMARBETEN

i strävar alltid efter att bli effektivare i våra projekt. Vi kommer framåt genom omorganiseringar, utbildningar, nya tekniska verktyg och arbetssätt. Men projektet kan alltid hoppa upp ytterligare ett par snäpp på effektivitetsstegen genom att medlemmarna blir bättre på att samarbeta. Att förstå varandra. Beteendeforskare berättar att ju bättre du förstår dig själv och din kollega desto mer accepterar och respekterar du honom, du samarbetar mer och arbetet blir effektivare. Hur mycket tid går inte åt till missförstånd, felinformation eller för lite information? Den som ska få projektet att gå i hamn är projektledaren. Projektledarrollen är komplex och ställer stora krav på förståelse för mänskliga beteenden, en känsla för att känna in och vårda varje person så att de tillsammans gör ett bra jobb projektet ut.

Ett verkningsfullt verktyg att ta hjälp av är profilanalys. Genom att utvärdera varje medlem utifrån en analys så kan egenskaper och förhållningssätt konkretiseras utan att lägga till värderingar. Det vill säga att exempelvis kreativ, entusiastisk och övertalande inte är bättre eller sämre än metodisk, noggrann och taktfull. Små saker kan göra stor skillnad. Om du vet att din kollega gärna vill ha en exakt tid att träffas så kan du säga 13.45 istället för ”runt två”, som du själv kanske tänker. Addiva använder IPU profilanalys®* för att urskilja beteendestilar (utgår från utvärderingsverktyget DISC*). Det visar pedagogiskt var var och en befinner sig i ett hjul. Hjulet innehåller fyra stilar; analytiskt, dominant, stödjare, inspiratör. Vare stil representerat i var sin färg. Här kan alla på ett lätt sätt förstå de olika beteenden som kan uppkomma hos respektive person. Så att det faktiskt används och gör skillnad. Många anlayser utförs för olika ändamål men många gånger blir det en punktinsats och personen ifråga kommer inte ihåg så mycket av resultatet. Med denna metod är det lättare att ta till sig de olika färgerna och beteenden kopplat till denna för att faktiskt agera och förändra sig själv och sitt möte med andra. Att kunna anpassa sig till andra för ett bättre samarbete. När ni ska påbörja ett nytt projekt, eller vill effektivisera ett pågående, kan Addiva ge projektmedlemmarna möjligheten att gå igenom IPU profilanalys®. Utförandet kan variera och anpassas efter projektet och dig som kund, men innehåller alltid enkätfrågor och återkoppling. Vi går igenom färgernas betydelse och alla visar öppet specifika egenskaper.

Pamela Christensson

På det viset tydliggörs hur medlemmarna vill bli bemötta och det skapas en mer öppen kommunikation. Du kan hantera konflikter, ge kollegorna personlig utveckling, öka motivationen och förbättra arbetsprestationer. Allt med hjälp av att förstå varandra och sig själv bättre.

Att kommunicera med en person med mycket... » Blått: förbered dig väl, var noggrann och realistisk, presentera fakta, var uthållig, » Rött: var klar, tydlig och håll dig till ämnet, gör en effektiv och logisk presentation, ställ tydliga frågor som börjar med ”vad..?” » Grönt: bryt isen med en personlig kommentar, bra med ”hur..?” frågor, Ha en lugn, mjuk och vänlig ton. » Gult: Prata gärna människor, lägg tid på att umgås och ha trevligt tillsammans, fråga efter personens åsikter.

*www.discprofile.com *www.ipu-profilanalys.com Text: Pamela Christensson Chef HR och administration Godkänd utövare av IPU profilanalys. ADDERA

MOBILUTVECKLING OCH APP-UTVECKLING Idag finns det två sätt att nå ut till en mobil plattform. Det ena sättet är via en mobilanpassad hemsida och det andra sättet är via en mobil applikation, som vi hedanefter helt enkelt kallar appar. Det finns fördelar och nackdelar med båda metoderna, så vilket alternativ som är bäst beror på produkten man vill nå ut med. I den här artikeln kommer vi titta närmare på några sätt att utveckla appar.

et finns ett antal olika sätt att utveckla appar på. De olika metoderna skiljer sig på ett antal punkter. De har olika utvecklingsverktyg, olika prestanda och olika möjligheter att stöda multipla plattformar. Vilken du väljer beror på de krav som ställs på appen du ska utveckla.

Utvecklingsmiljö och simulatorer är anpassade specifikt för plattformen, vilket underlättar utvecklingsarbetet. Den stora nackdelen med denna typ av utveckling är att en ny version av mjukvaran måste utvecklas för varje plattform applikationen ska köras på. Dessutom skiljer sig programmeringsspråken mellan de olika plattformarna vilket ställer höga krav på utvecklingsteamet och gör det svårt att återanvända kod mellan de olika versionerna.

CROSS-PLATFORM

Daniel Söderholm

NATIVE Med native-utveckling menas att man utvecklar applikationen direkt mot den givna plattformen, till exempel OS X. Fördelarna med detta är många. Prestandan brukar vanligtvis bli bättre, dessutom brukar dokumentation och exempel vara betydligt bättre för den valda plattformen. ADDERA

Alternativet till native-utveckling kallas ”cross platform”. Vid cross platform-utveckling skrivs koden på ett ställe, i ett språk och kan därefter kompileras ner och köras på flera olika plattformar. Det viktiga när man väljer ett framework för cross platform-utveckling är att titta på kraven för applikationen. Detta inkluderar tillgänglig utvecklingstid, applikationens storlek och funktionella krav, samt så klart vilka plattformar som ska stödjas. Det finns ett antal verktyg som stöder denna typ av utveckling och vi kommer här titta på två av dem.

XAMARIN

vilket gör att den effektiv att köra. Den separata koden för UI gör att man kan använda plattformsspecifika lösningar och få applikationen att se ut som andra applikationer på samma plattform utan problem.

PHONEGAP PhoneGap har en helt annan lösning på problemet. Istället för att kompilera ner koden till nativeformat, körs appen på samma sätt som om det vore en hemsida. Applikationen utvecklas med hjälp av HTML5, CCS3 och JavaScript och körs sedan i wrappers på varje plattform, vilket låter samma kod köras, oavsett operativsystem.

SAMMANFATTNING Oavsett vilken teknologi som används är det oftast en bra idé att utveckla dina applikationer med cross-platform i åtanke. Även om kraven i dagsläget inte kräver det, förlorar man inte mycket på att satsa på att stödja fler plattformar redan från början, hellre än att i efterhand behöva porta koden.

Text: Daniel Söderholm

Grundtanken i Xamarin är att all affärslogik är gemensam för samtliga plattformar, sen måste separat kod utvecklas för varje plattforms användargränssnitt. Xamarin kompilerar sedan ner koden för den givna plattformen till native-kod,

INOFFICIELLA ROLLER I PROJEKT

är mjukvarutvecklingsprojekt bemannas, även agila sådana, letar organisationen efter personer som kan uppfylla de kända officiella rollerna såsom arkitekt, CM, testare, utvecklare osv. Men ofta glömmer man, eller till och med är omedveten om, de inofficiella rollerna som är minst lika viktiga för projetets framgång. Dessa roller är kända under namnen Public Character, Gate Keeper, Matron och Wise Fool.

PUBLIC CHARACTER En organisation är en social enhet, vilken är beroende av mer än bara professionella relationer för att fungera väl. Därför tar en eller flera personer rollen som Public Character för att hjälpa de sociala processerna på traven, både bakom kulisserna och i sociala sammanhang.

Public Character är den ytterst informella rollen som inte går att tilldela till någon, men går att hitta. Detta gör du genom att ställa strategiska frågor till en möjlig kandidat, såsom: • • • • • •

Vem kan databaser? Hur fixar man felet i skrivmaskinen? Hur hittar man information om webbservern? Var är chefen just nu? Var är bästa lunchstället? När brukar Anita dyka upp?

GATE KEEPER Ett projekt måste utveckla bra gränssnitt med de många utomstående parter som det interagerar, eller borde interagera, med. Därför tar sig en projektmedlem (en Public Character med gripande personlighet) an rollen som Gate Keeper. Magdalena Bozyk

Ett projekt har oftast en eller flera Public Characters. Dessa är mycket sociala och håller tät kontakt med andra projekt- och organisationsmedlemmar. De är informella informationsnav och håller reda på massor av information, allt från små detaljer till djupa insikter. Ofta är det information, som inte går att få tag på genom de formella kanalerna, men icke desto mindre viktig för att stödja arbetsmiljön och arbetet. Där ingår också meta-kunskap om var eller hur man kan hitta viss typ av information. Public Character är ofta en levande anslagstavla, som andra projektmedlemmarna vänder sig till för att både få, söka och sprida information. Ofta får dock dessa personer inte den uppskattning de förtjänar. Tvärtom så är det inte ovanligt att de blir bestraffade för att de inte får något gjort och istället slösar tid på onödigt skvaller. Men när en sådan person försvinner ur projektet kan det påverka arbetsmoralen negativt. Det kan till och med vara så att det har större effekt än när man tappar en teknisk nyckelperson.

“DE INOFFICIELLA ROLLERNA ÄR MINST LIKA VIKTIGA FÖR PROJEKTETS FRAMGÅNG.” Denna person sprider information från utsidan av projetet till projektmedlemmarna och tolkar denna till termer relevanta för projektet. En Gate Keeper kan också ”läcka” projektinformation till relevanta utomstående. Många utvecklare är inte bekväma med att behöva kommunicera med utomstående, och de kan många gånger vara dåliga på det. Medan kommunikationen är viktig, kan overheaden bli för hög om informationskällorna utanför projektet är många samtidigt som det finns många projektmedlemmar. Det är också bra om

organisationen kontrollerar informationsflödet in och ut ur projektet. En Gate Keeper underlättar detta, dock kan en person med egen agenda stjälpa mer än hjälpa. Därför kan det vara bra att veta om Gate Keeper:n är aktiv inom kontorspolitiken och tagit sig an den rollen bara för sin egennytta. Officielt brukar man tillskriva den här rollen till projektledaren, men det händer att den blir explicit i stora projekt och organisationer.

MATRON Ett team överlever inte bara på sitt arbete. Vissa sociala aktiviteter är nödvändiga för att motivera teamet att fortsätta med det tekniska arbetet. Därför bör man försäkra sig om att gruppen har en Matron som kommer att planera och utföra de sociala och mellanmänskliga aktiviteterna som är nödvändiga för att behålla sammanhållningen i gruppen. ADDERA

Matron Gate Keeper Public Wise Fool Character

En matron är en person som håller reda på andras födelsedagar och hittar ofta orsak att fira. Hon (trots namnet kan det också vara en han) är ofta engagerad i att arrangera fester, olika (trivsel)aktiviteter och är medlem i kakklubben, picknickutskottet och festkommittén. I en organisation där många är introverta, vilket är inte så ovanligt bland mjukvarutvecklare, blir Matron-rollen desto mer synlig och viktig. Denna roll är en inofficiell roll som inte går att tilldela. Någon antingen är en Matron, eller inte.

WISE FOOL Det är inte ovanligt att mellanmänsklig dynamik avskräcker andra från att ta upp goda idéer och rensa bort de dåliga. Därfor bör man vårda rollen av Wise Fool, som ostraffat kan påvisa de obekväma sanningarna. Under medeltiden, var hovnarren den enda som ostraffat kunde driva med, och skratta åt, kungen. Men hovnarren var inte bara rolig, han tillhandahöll insikt som stimulerade tankegångarna. På samma sätt kan Wise Fool tvinga en organisation till navelskådning och introspektion. I en organisation kan många vara rädda för att påpeka saker till personer med auktoritet och ledarroller. Det kan också vara svårt att ta upp vissa ämnen i en ADDERA

grupp där alla till synes verkar vara nöjda med status quo. Men det behövs alltid någon som säger rätt ut när något är snätt. Wise Fool ställer de obekväma och impopulära frågorna. Ibland är Wise Fools kända för att vara taktlösa, men de är ofta tekniskt kunniga och respekterade. Det är inte ovanligt att de undviker att göra karriär inom företagsledning, och kan t.o.m. te sig vara föraktfulla till denna. Wise Fool är en roll som man växer in i och som inte kan bli tilldelad. En organisation eller ett team som har en Wise Fool tenderar att ta färre dåliga beslut.

fungera problemfritt, fokuserar Wise Fool mest på gruppens resultat. De fyra rollerna tillför värde till projektet, resultatet, effektiviteten, moralen och sammanhållningen. Eftersom de oftast inte kan tilldelas bör man se till att projektet bemannas av personer som antingen redan har dessa roller, eller besitter egenskaper som gör att det kan tyckas falla sig naturligt.

Text: Magdalena Bozyk

Tyvärr så kan Wise Fool-rollen förbises som gnällspik eller bråkmakare. Därför är det ytterst viktigt att en Wise Fool ser skillnaden mellan gnäll och legitima problem och bara tar upp saker som organisationen har kontroll över.

SLUTLEDNING I första anblicken verkar Wise Fool, Matron och Gate Keeper vara samma som Public Character, eftersom det finns stora likheter mellan dessa roller. Skillnaderna är att Matron är inåtriktad mot organisationen och koncentrerad på att vårda den. Gate Keeper håller sin fokus utåt och ser fram emot nya riktningar. Public Character är någonstans i mitten, men skild från dessa. Wise Fool är också mycket lik Public Character och är också inåtriktad mot organisationen såsom Matron. Men där de andra tre rollerna får teamet att

NYA PÅ ADDIVA

ARMAN

HENRIK

FREDRIK

Arman är civilingenjör och utbildad inom elkraft från Chalmers Tekniska Högskola. Arman har flera års erfarenhet som elkonstruktör. Han

Erfaren utvecklare med god kompetens inom Microsoft-världen. Har arbetat inom flera branscher och byggt både client/server, distribuerade

Har en kandidatexamen i datavetenskap från Mälardalens Högskola. Fredrik har arbetat med utveckling av mobilapplikationer i 4 år, både

har dessutom haft rollen som serviceingenjör, nätanslutningsingenjör och komponentingenjör. Senast var han globalt produktansvarig för strömriktarmoduler.

system och SOA-lösningar. Dessutom har han kunskaper om modern testmetodik och testautomation.

i Android och IOS. Han har under denna tid kommit att bli riktigt duktig och eftertraktad utvecklare av mobilapplikationer. Han har även erfarenhet av utveckling i finansiella system, då i högnivåspråk såsom C# och Perl.

Arman arbetar proaktivt, han är en resultatinriktad person som kan leverera ett komplext tekniskt arbete enligt projekt/tidsplan. Han strävar efter att tydliggöra projektkrav och att efterleva de tekniska/finansiella begränsningar som reglerar projektet.

Henrik har arbetat som konsult/systemutvecklare sedan 1997. Även om han har jobbat mycket med Microsoft specifika lösningar så ser han egentligen inte tekniken i sig som det viktigaste. Hans erfarenhet som konsult är att kunden vänder sig till den som förstår deras verksamhet och behov bäst.

NILS

JERKER

MIKAEL

Civilingenjör i robotik med kompetens inom främst inbyggda system, digital elektronik och hårdvarunära programmering men också andra områden som matematik, mekanik och CAD.

Jerker har en magisterexamen i matematik/ datavetenskap från Lunds Universitet. I över 25 år har han arbetat med systemprogrammering och många gånger har det också inkluderat krav, konstruktion, provning, support, felsökning och prestandaanalys. Han är bäst inom hårdvarunära utveckling, exempelvis assembler, C och kompilatorteknik.

Mikael är en illustratör / artist / grafisk formgivare. Han jobbar med 3D visualisering, Adobe Photoshop, Illustrator och Indesign.

Utexaminerad 2014 och examensarbetet ”Tillägg till kommunikationsprotokollet Space Plug-andplay Architecture (SPA) för kommunikation över CAN-protokollet” blev nominerat till Embedded Awards.

Hans stora intresse för programmering tillsammans med en bra analytisk förmåga gör att han lätt kan skaffa sig en helhetsbild över projekt, men samtidigt hålla med detaljkunskaper för att kunna fatta rätt beslut och leverera lösningar.

Han älskar att skapa konst, både digitalt och för hand, samt branding och grafisk design.

Tycker om ren och koncis kod med återkommande mönster, som är väl dokumenterat i doxygen eller liknande verktyg.

ADDERA

LEIF

JOHN

DENNIS

John har en utbildning från Örebro Universitet och hans första arbete var som systemutvecklare, där projekt i C-språken var övervägande. Han har under sina 15 år i branschen hunnit med att klättra på karriärstegen som egen företagare, produktchef projektledare och avdelningschef.

Vår IT avdelning har fått förstärkning med en IT tekniker. Dennis har en bakgrund som hårdvarutekniker, där han arbetat med service, underhåll och lagning av PC, Mac, mobiltelefoner och servrar.

Hans gedigna erfarenhet har gett honom ett mycket bra sinne för affären i varje projekt,

Dennis är en omtyckt, kunnig och hjälpsam tekniker som får oss alla att ha en lättare vardag!

Leif har arbetat i över 30 år med systemering och programutveckling av avancerade tekniska system. Realtids- och hårdvarunära programmering samt tele- och datakommunikation ingår i hans kompetens. Utveckling av testprogram och testskript samt test och verifiering av hårdvarukonstruktioner har liksom utveckling av realtidskärnor ingått i många av uppdragen. Leif är metodisk och brukar nå sina mål och hålla en hög kvalitet på sitt jobb även när problem dyker upp. Som konsult har Leif arbetat åt många stora och små industriföretag. Projekten har varit allt från små enmansprojekt till projekt med hundratals deltagare. Han har därför fått erfarenhet av såväl de mindre projektens alla ingående faser från kravspecifikation till färdigt testat och genomfört system, som de större projektens komplexitet.

samtidigt som han har god teknisk kunskap i både hårdvara och mjukvara. Han är person som är informativ och har styrkan att vara rak på sak.

Fotograf: Melika Hozhabri

JULBORDET

Addiva njöt av julmat i gott sällskap av varandra

Vi önskar er en god fortsättning på 2015! ADDERA

TEKNISK SYSTEMUVECKLING Peter Krantz

Dag Lindahl

Rasmus Friberg

Pamela Christensson

Säljare/affärsutvecklare

Chef teknisk systemutveckling

Affärsområdeschef Stockholm

Chef HR och administration

0708-67 24 57 peter.krantz@addiva.se

0736-10 22 60 dag.lindahl@addiva.se

0768-30 80 70 rasmus.friberg@addiva.se

0708-68 54 11 pamela.christensson@addiva.se

EL/AUTOMATION/MEKANIK Johan Nilsson

Liz Hoffman

Chef mekanik/el och Dalarna

Chef automation

0705-55 04 88 johan.nilsson@addiva.se

0707-86 90 37 liz.hoffman@addiva.se

Kopparbergsvägen 8, 722 13 Västerås. Telefon: 021- 471 21 30. E-mail: pamela.christensson@addiva.se