Styrande faktorer och övergripande systemkrav vid testning av SIM-kortskommunikation
|
|
- Mattias Lindqvist
- för 8 år sedan
- Visningar:
Transkript
1 Styrande faktorer och övergripande systemkrav vid av Examensarbete utfört vid, KTH & Utvecklings ochforskningsavdelningen vid AU-System Mobile Mh.Th Industrial Control Systems School of Electrical Engineering and Information Technology KTH, Royal Institute of Technology Stockholm, SWEDEN
2
3 Abstract Leading aspects and overall systems requirements in testing SIM card communication As the development of new services for mobile phones, Over-The-Air functions and applications with SIM Application Toolkit, new demands on comprehensive test procedures arise. The objective with this Master Thesis has been to map the overall aspects on developing and testing these services, and, to evaluate and improve the existing test process, and, if possible, also then automate the test procedure. Measurements showed that the most time consuming parts where latencies in the GSM network and the tedious manual test labour. An evaluation indicated that an application that bypassed the GSM network and the mobile phone would make the test procedure more efficient, thus enabling Short Messages to be transferred directly to the SIM card. A literature study on requirements engineering and automated tests was performed, enabling a requirements capture on the test environment where the application was to operate in. To get the overall picture, an investigation of technologies was performed in the field of mobile telecommunications and especially related to SIM cards and Short Message Service, SMS. Following the implementation and introduction of the application into the test environment there were an improvement of, as much as, 65%. The automation of the test procedure was not as successful and the improvement was negligible compared to the bare introduction of the application in the test environment. Keywords: GSM network, OTA - Over-The-Air, SAT - SIM Application Toolkit, SIM cards, SMS, automating tests, automated test tools, mobile communication, requirements engineering, testing. i ABSTRACT
4 Sammanfattning Vid utvecklingen av nya tjänster till mobiltelefoner, Over-The-Air-funktioner och SIM Application Toolkitprogram, krävs en omfattande testprocedur för att verifiera resultaten. Målet med detta examensarbetet har varit att kartlägga de bakomliggande faktorerna vid utvecklandet och testandet av dessa tjänstesystem, och även förbättra den befintliga testproceduren, och eventuellt automatisera testförfarandet. Det visade sig att den mest ineffektiva delen i testmiljön var relaterad till fördröjningar i GSM-nätet samt det enahanda manuella testarbetet. Efter en utvärdering ansågs att en applikation som emulerade GSM-nätet samt mobiltelefonen skulle kunna effektivisera testprocessen för att på så sätt kunna skicka SMS, Short Message Service, direkt till SIM-kortet. För att ta fram kraven, på testmiljön som applikation skulle operera i, utfördes en grundlig studie i kravhantering och autotester. För att få med helheten kring testprocedurerna sammanställdes även en nulägesanalys av mobiltelefoni med inriktning på SIM-kort och SMS. Efter att ha implementerat och infört applikationen i testmiljön blev resultatet att tiden för att utföra ett test förkortades med hela 65%. Dock så blev automatiseringen ej lika lyckad då tidsfaktorn vid automatiseringen endast förbättrades marginellt i jämförelse med den icke automatiserade lösningen. Nyckelord: GSM, OTA - Over-The-Air, SAT- SIM Application Toolkit, SIM-kort, SMS, autotester, autotestverktyg, kravhantering, mobiltelefoni, requirements engineering, testning. ii SAMMANFATTNING
5 Förord Detta examensarbete genomfördes under sommaren samt hösten 1999 på dåvarande AU-System Mobile av vid, KTH tillsammans med Johan André, vid Institutionen för Teleinformatik, KTH. Efter att ha arbetat närmare 21 veckor på Utvecklings och Forskningsavdelningen på AU-System Mobile kan jag se tillbaka på en mycket givande och rolig tid. Dessa veckor har gett mig nya erfarenheter, ett stort antal nya förkortningar, ny kunskap samt nya vänner. Jag vill tacka alla på Mobile för deras hjälp och tid, speciellt Hilde Digernes och Fredrik Broman för deras svar på frågor om SIM-kort och SMS, Simon Wallén, Fredrik Almgren, Filip Rosenbaum och Kenneth Johansson för deras programmeringskunskaper, Jörgen Hult, Anki Andersson och Anders Månsson för deras ovärderliga kunskaper om transportservern. Jag vill även passa på att tacka Per Lundh för det mycket intressanta samtalet som vi hade. Sedan vill jag även tacka mina handledare, Erik Johansson,, KTH och Staffan Lindgren Testansvarig, AU-System Mobile. Dessa två skall ha ett stort tack för de kommentarer och hjälp som de bidragit med under arbetets gång. De mötena som jag och Erik hade innebar oftast att jag lämnade mötena med fler frågor än jag hade när vi började mötena, med de var alla väldigt givande och nyttiga för mig och min rapportering. Till sist vill jag även tacka Johan André som jag utförde examensarbetet tillsammans med. Utan honom hade arbetet inte förlupit så smidigt som det gjorde och examensarbetet hade inte varit så givande och trevligt som det faktiskt blev. Stort tack ska ni alla ha!, november 1999 iii FÖRORD
6
7 Innehåll I Introduktion 1 1 Inledning Presentation av AU-System Verksamheten tillämpad tele- och datakommunikation Kompetensen AU-System Mobile Bakgrund Nya tjänster Den befintliga testproceduren Kommande tester Mål och syfte Problemformulering Avgränsningar Rapportdisposition... 6 II Teorier 7 2 Kravhantering Inledning Ett systems användarcykel Krav Aktiviteter under kravhanteringsfasen Utmaningar i kravprocessen Specifikationsarbetet Problematiken Fel i kravhanteringsprocessen Dokumentering Helheten formulerad Kravhanteringen i utvecklingsprocessen Automatiserad testning In- och uppspelningsverktyg Testning av användargränssnitt Regressionstest Problematiken Myterna Paradigmen Strategi Klassiska misstag och problem Rollen Planering Personal Arbetet Teknologins framfart ställd mot det ekonomiska faktorerna Vilka tester kan automatiseras? Autotestets livslängd Värdet av ett autotest III Nulägesanalys 26 INNEHÅLLSFÖRTECKNING
8 4 Utredning av teknologier Telekom Mobiltelefoni GSM Historia(Global System Mobile) Standarder SIM-kort, Subscriber Identity Module Kort historia Modul för en abonnents identitet Teknisk beskrivning Den elektriska karakteristiken Kortkonfiguration Arkitekturen hos ett SIM-kort Funktionalitet SIM Application Toolkit Short Message Service, SMS Strukturen hos ett SM Användardatat i ett SM OTA-SM Nätverksuppbyggnad SMS-överföringens primitiver Protokollagren i SMS-miljön AviSIM OTA Service center Systemarkitekturen hos AviSIM OTA-SC Klienttjänster Applikationer Framtiden Standarder GPRS Marknaden styr Historien innehåller inte hela sanningen IP - ärettkrav Uppdelning av mobiltelefon WAP - Wireless Application Protocol WIG Framtidens aktörer IVGenomförande 45 5 Metod Mätningar på dagens tester Skall testerna automatiseras? Är en applikationsprototyp lämplig? Tillvägagångssätt Krav Begränsningar Arkitektur Implementation Utgångsläget Språket Design Kommunikation Loggning Användarkonfigurationer Iaktagelser under utvecklingen INNEHÅLLSFÖRTECKNING
9 6.2.5 Verifiering Resultat Autotestets prestanda Slutsatser De bakomliggande faktorerna De övergripande aspekterna Fortsatt arbete INNEHÅLLSFÖRTECKNING
10 Figurer 1 Den övergripande systemmiljön i OTA-plattformen Testförfarandet vid test av stöd för SIM-kort [B1] Miljön för Wireless Internet Gateway och dess komponenter Systemmiljön, där molnet innesluter de komponenter som skulle modelleras för att eventuellt kunna elimineras Ett godtyckligt systems användarcykel [21] En process för kravhantering [21] Betydelsen för ett formulerat krav Skriptkod, med och utan användandet av ett API [23] Schematisk grovfördelning av en applikations innehåll [23] Schematisk grovfördelning av en applikation med testpunkter [23] Autotestets liv och faser [26] Koden i en applikation; kod under test, mellanliggande kod och testets kodpropagering [26] Koden i en applikation samt testpunkter och ramverk [26] Området under det horisontella strecket är stödkoden och området ovan illustrerar funktionskoden, här med fem specifika funktioner [26] En ändring i en funktion har gjorts i kod under test (den mörkare delen) [26] Här har två funktionsdelar ändrats och en ytterligare har lagts till. För att dessa nya koddelar skall fungera har även en viss del av stödkoden ändrats/påverkats [26] Tre tester, med olika indata och resultat, men som alla använder sig av samma stödkod [26] Kod under test uppdelat i mindre delar med block av stödkod [26] Ett SIM-korts tre olika användarfaser [11] Den övergripande strukturen hos ett SIM-kort [11] Exempel på filstrukturen hos ett SIM-kort Händelseförloppet för ett SMS för SIM-uppdatering. Env. = envelope, XX indikerar längden på kommandot som skall hämtas. ETSI[18] Uppbyggnaden hos ett SM Den generella strukturen på SMS-enheter. SMS-GMSCanvänds vid MT-meddelanden (SMS- C mobiltelefon) och SMS-IWMSCanvänds vid MO-meddelanden (mobiltelefon SMS-C) ETSI[18] MWD: De intressanta delarna i HLR ur ett SMS-perspektiv Protokollagren för Short Message Services. Bilden kommer från ETSI[17] Systemarkitekturen hos AviSIM OTA-SC [3] AviSIM OTA Service Centre med samtliga klienttjänster [3] Testmiljön vid OTA-uppdateringar Fördelningen av tiden mellan GSM-nätverksfördröjningar och det manuella arbetet Figuren illustrerar den övergripande arkitekturen vid användandet av den nya testproceduren med en applikation. Den lilla gubben motsvaras av en testare vid sin dator som kör alla applikationer [B1] Arkitekturen med implementationsfaserna [B2] Programarkitekturen för applikationen [B2] Flödet mellan Transportservern, applikationen och SIM-kortet De interna flödesdesignen hos applikationen. De delar med dubbelram exekverar som en tråd [34] Fördelningen av tiden i de tre fallen FIGURER
11 Tabeller 1 Fel och dess orsaker som kan uppstå i en kravprocess Innehållsförteckning för ett allmänt kravdokument [21] SMS-typer Protokoll för kommunikation med ett SMS-C och respektive tillverkare Intressenter och aktörer inom telekombranchen. Tabellen illustrerar att det är många inblandade med ibland olika positioner (leverantör, tillverkare, kund etc.) och att gränserna inte är helt uppenbara De närmast involverade personerna i kravprocessen TABELLER
12 Ordlista & Förkortningar ADN Abbreviated Dialling Numbers MT Mobile Terminated API Application Programming Interface, Meddelanden till mobiltelefonen programmeringsgränssnitt för en applikation Addressen på den enhet som utfärdat OA Originating Address CDMA Code Division Multiple Access ett visst meddelande. CPHS Common PCN Handset Specification OS operativsystem CR-verktyg Capture-and-Replay tools OTA-SC OTA Service Centre in- och uppspelningsverktyg OTA Over-The-Air DCS Digital Cellular System Samlingsnamn för de funktioner som kan ändra datat på ett SIM-kort genom att skicka SMS DF Dedicated File filtyp på ett SIM-kort PCN Personal Communications Network EDGE Enhanced Data rate for GSM Evolution PIN Personal Identification Number EF Elementary File PLMN Public Land Mobile Network filtyp på ett SIM-kort PUK Personal Unblocking Key ETSI European Telecommunications Standards Institute AU-Systems interna ramverk SAP SIM Application Platform GPRS General Packet Radio Service SAT SIM Application ToolKit GSM Global System Mobile Funktioner som stödjer nedladding av applikationer, menyer mm. på enmo- biltelefon och SIM-kort HLR Home Location Register HMI Human Machine Interface SC Service Centre ICC Integrated circuit Chip Card, smartcard SEND-SM Meddelandetyp som genereras av SIMkortet IMSI International Mobile Subscriber Identity SFM SIM File Management Klientapplikation IP Interaktions punkter SIM Subscriber Identity Module i ett grafiskt användargränssnitt SME Short Message Entity ISDN Integrated Services Digital Network SMS-C Short Message Service Centre LND Last Number Dialled SMS-GMSC SMS Gateway MSC MAP Mobile Application Part SMS-IWMSC SMS InternetWorking MSC MCEF Mobile-station-Capacity-Exceeded-Flag SMS Short Message Service ME Mobile Equipment Mobilentelefonen SM Short Message MF Master File SS7 Signalling System 7 Huvudfilen på ett SIM-kort STM SIM Toolkit Messaging MNRF Mobile-station-Not-Reachable-Flag TDMA Time Division Multiple Access MNRR Mobile-station-Not-Reachable-Reason TP-OA Transfer Protocol OA MO Mobile Originated Den adress som utfärdar ett SMS, och Meddelanden från mobiltelefonen som då skall ta emot ett eventuellt svar MSC Mobile Switching Centre TR Terminal Response MSISDN Mobile Station international ISDN Number Svar som en mobiltelefon kan skicka till SIM-kortet som bekräftelse MS Mobile Station TS Transportserver Mobilentelefonen och SIM-kortet sett Består av två delar STM och SMSsom en entitet ORDLISTA & FÖRKORTNINGAR
13 Gateway. UMTS Universal Mobile Telecommunication System VLR Visitor Location Register W-CDMA Wideband-CDMA WAP Wireless Application Protocol WIG Wireless Internet Gateway WML Wireless Markup Language ORDLISTA & FÖRKORTNINGAR
14
15 Del I Introduktion 1 Inledning En övergripande bild av ett systems utgångspunkt, med förståelse för varje systemkomponents roll, är ett krav för att kunna specificera och leverera ett fullskaligt utbud av tjänster och applikationer. Utvecklingen av GSM är en evolutionär process, system, funktioner och applikationer utvecklas i olika hastighet och i varierande grad, där den systemdel (av nätverk/sim-kort/mobiltelefon) som har den lägsta funktionaliteten bestämmer vad systemet kan erbjuda. I dagsläget finns det ett stort antal teleoperatörer världen över med olika tjänsteutbud. Det som de har gemensamt är möjligheten att erbjuda sina kunder, abonnenterna, nya tjänster i form av olika mervärdesfunktioner t.ex. biljettbeställning, banktransaktioner, bokningar, väderprognoser mm. Vid testning av dessa olika tjänster i form av applikationer, nedladdningar och uppdateringar från olika klienter mot ett SIM-kort, går dessa datameddelanden igenom hela GSM-systemet. Då GSM-nätet ej garanterar direkt leverans vid en överföring introduceras fördröjningar. Detta utgör således ett hinder för att kunna utföra automatiska tester vilket gör att testprocessen är både tidskonsumerande och ineffektiv. De tester som utförs i dagsläget har visserligen en positiv egenskap då en nedladdad testapplikation direkt kan interagera mellan SIM-kort och mobiltelefonen. Denna testmiljö, där meddelanden och applikationer överförs mellan SIM-kort och exempelvis en klient, ligger som grund för detta examensarbete 1 och det som skall modelleras är bl.a. hur GSM-nätet kan lyftas ut ur överföringskedjan. SIM-kort och övriga systemkomponenter skall inte märka att överföringar inte går via GSM-nätet, d.v.s. systemets överföringskarakteristik skall inte påverkas av den lösning som tas fram. 1.1 Presentation av AU-System AU-System[1] grundades 1974 och blev Sveriges första programvaruspecialist inom datakommunikation. AU-System är ett av landets största konsult- och programvaruföretag inom tele- och datakommunikation. Under våren 1999 omstrukturerades AU-System till ett mer renodlat konsultbolag. Sedan april 1999 är Schroder Ventures ägare till 75% och de skall tillsammans med Ericsson, den näst största ägaren, stärka AU-System i den fortsatta planerade internationella expansionen Verksamheten tillämpad tele- och datakommunikation AU-System är ett välkänt namn bland de stora aktörerna inom tele-, mobil- och datakommunikation. De har en stor andel av landets största telekomföretag som kunder. Cirka 60% av verksamheten vänder sig till operatörer och leverantörer inom telekommunikation medan 40% avser projekt och lösningar för slutkunder som banker, industriföretag och myndigheter Kompetensen Genom att lära sig ny kommunikationsteknik i projekt för stora IT-leverantörer för att därefter tillämpa tekniken i integrationsuppdrag för banker och stora industriföretag kan man på ett effektivt sätt att bygga upp företagets och de anställdas kompetens. Ett av de mest kraftfulla sätten att bygga och överföra AU-System inriktar sig på hur tekniken kan integreras och tillämpas för att bli till mest nytta för användarna. kunskap och erfarenhet är att jobba i projekt tillsammans med kollegor i egna lokaler. Till skillnad från andra mer renodlade konsultföretag arbetar därför 60-75% av personalen i de egna lokalerna med tillgång till kompetenta och erfarna kollegor. Detta medför att en kund som betalar för en konsulttjänst får mer 1 examensarbetet är även benämnt projektet i rapporten 1(62) DEL I: 1. Inledning
16 än den enskilde konsultens kompetens, då de även får tillgång till den kunskap som konsultens kollegor har AU-System Mobile AU-System Mobile 2 arbetar framförallt med systemlösningar mot SIM-kort för framförallt mobiltelefonoperatörer. De utvecklar olika s.k. Over-The-Air system, OTA, t.ex: OTA-Server, figur 1, är en plattform för alla tjänster baserade på OTA-SIM-kortshantering som stödjer metoder för fjärrhantering av applikationer i en mobiltelefons SIM-kort, lägga till och uppdatera data. Personaliseringssystem för SIM-kort, nedladdning av rådata på SIM-kortet (det innehåll som ett kort har när det kommer i handen på en slutkund). SIM Application Toolkit, tillhandahåller funktioner som möjliggör SIM-kortbaserade applikationer att interagera med en mobiltelefon. Figur 1: Den övergripande systemmiljön i OTA-plattformen. 1.2 Bakgrund Nya tjänster Möjligheten att administrera SIM-kort över luften öppnar nya dörrar för tjänsteutbudet till användarna. Ett exempel på dessa nya tjänster är mobil e-handel där abonnenterna använder sin mobiltelefon för betala och beställa produkter. Biljettbokning till bio eller en konsert kan snart genomföras med en mobiltelefon: biljetten bokas via Internet betalningen sker genom att kunden med hjälp av mobiltelefonen godkänner köpet Säkerhetsfunktionerna på SIM-kortet kan utnyttjas för att t.ex. innehålla pengar, på samma sätt som cash-kort. Ett ytterligare exempel är då en försäljare vill säkerställa en kunds identitet, vilket kan ske genom att kunden konfirmerar ett meddelande som försäljaren skickat till kundens mobiltelefon. I Grekland har föräldrarna idag möjligheten att programmera deras barns mobiltelefoner så att de endast kan ringa de telefonnummer som föräldrarna godkänt. Detta görs via en Internetapplikation som använder sig av OTA. Ett annat affärsområde som är mycket intresserade av dessa nya tjänster är aktiehandeln. I Singapore har mobiloperatören Singtel redan börjat använda ett system som gör det möjligt för abonnenterna att köpa och sälja aktier med mobiltelefonen och i dagsläget är det runt 400 kunder som utnyttjar dessa tjänster. Tekniken som används i detta system är SIM Application Toolkit, SAT (se avsnitt 4.3.8). 2 Sedan oktober 1999 heter nu företaget Across Wireless[2] 2(62) DEL I: 1. Inledning 1.2 Bakgrund
17 OTA-meddelanden, (Over-The-Air), ger operatörerna nya möjligheter, t.ex. kan de enkelt fjärruppdatera abonnenternas telefoner med exempelvis ett nytt nummer till deras kundtjänst och lägga in det i telefonboken på SIM-kortet Den befintliga testproceduren För att kunna verifiera att OTA Service Centre (OTA-SC), se avsnitt 4.6, stödjer de kort som operatörerna erbjuder sina kunder, måste dessa testas. Detta görs manuellt, se figur 2, genom att samtidigt använda tre olika applikationer. Testförloppet genomförs på följande sätt: 1. Välj lämpliga uppdateringskommandon i OTA Service Assistant 3, t.ex. uppdatera telefonboken. Sedan skickas dessa kommandon till SIM-kortet via GSM-nätverket och mobiltelefonen. Figur 2: Testförfarandet vid test av stöd för SIM-kort [B1]. 2. Beroende på vilken fil som uppdaterades på SIM-kortet finns det två olika applikationer som kan användas för att verifiera resultatet. Den ena visar filernas innehåll i hexadecimalkod och den andra visar klartext. I de fall som det inte går att verifiera resultatet med mobiltelefonen så används någon av dessa två applikationer. Vid genomförandet av detta test måste SIM-kortet flyttas mellan mobiltelefonen och en kortläsare och dessa frekventa operationer tar mycket tid. Testet är också resurskrävande då det överförs via GSMnätet, och (om det inte framgått) så är det ett mycket enahanda arbete. I dagsläget är detta det enda verifieringssättet som dessa kortstöd kan testas på. Ett annat scenario är när olika SIM-kort testas för att undersöka hur de stöder OTA-meddelanden. I dessa fall är intresset fokuserat på hur SIM-kortet agerar efter en nedladdning. Det är på uppdrag av mobiloperatörerna som vill försäkra sig om att deras nya kort stöder OTA-meddelanden innan de massproduceras och distribueras till kunderna. Dessa tester utförs på samma sätt som vid verifieringen av OTA-meddelanden Kommande tester Mobilt Internet[5] är det område som nu verkar vara det enda som är av intresse inom telekomvärlden. Alla människor utrustade med en mobiltelefon skall snart kunna surfa på nätet. Ett sätt som möjliggör 3 Service Assistant är en applikation som används för att administrera filerna på SIM-kort. 3(62) DEL I: 1. Inledning 1.2 Bakgrund
18 detta är att använda applikationer på kortet med SAT, SIM Application Toolkit. För kunna stödja SATmeddelanden uppkommer vissa nya krav på Transportservern (en central del i överföringen av meddelanden) och därmed nya testfall. De nya testfallen ämnar testa stödet för SAT i Transportservern och kan delas in i två stycken grundfall (figur 3). Mellan Internet finns en gateway, Wireless Internet Gateway, Figur 3: Miljön för Wireless Internet Gateway och dess komponenter. WIG, som är uppkopplad mot en Transportserver. WIGen består av en Push- och en Requestserver. Det första testfallet utförs enligt: 1. Användaren skickar en begäran (request) via mobiltelefonen genom GSM-nätet till en Transportserver. Det kan exempelvis vara begäran om en specifik websida. 2. Requestet skickas vidare till en Requestserver i en gateway (Wireless Internet Gateway, WIG, se 4.7.8). 3. Requestservern kommunicerar med den webbservern som har den aktuella webbsidan. 4. Den begärda sidan överförs sedan till Transportservern som vidareförmedlar den till mobiltelefonen via GSM-nätet. I det andra fallet vill Transportserverns beteende också undersökas, fast nu initierar Pushservern trafiken. Pushservern används för att överföra requests från Internet till mobiltelefonen. Till exempel kan det vara då en person vill köpa en produkt via Internet. Personen kan då konfirmera betalningen samt sin identitet genom att acceptera ett nedladdat acceptansrequest som leverantören skickat via Internet. Testförfarandet för detta utförs enligt: 1. En acceptansbegäran skickas till Pushservern från Internet. 2. Det överförs till Transportservern som skickar det vidare till mobiltelefonen via GSM-nätet. 3. Mobiltelefonanvändaren accepterar eller nekar förfrågan och svaret skickas tillbaka till GSM-nätet. 4. Transportservern vidareförmedlar svaret till Pushservern som skickar det till utfärdaren. Dessa testfall är av intresse vid utvecklingen av automationstester, därför att dessa tester också påverkas av GSM-nätets fördröjningar, vilket speciellt märks i det andra fallet. 4(62) DEL I: 1. Inledning 1.2 Bakgrund
19 1.3 Mål och syfte Syftet med detta projekt var att undersöka möjligheterna för automatiserade tester integrerade med vissa av AU-System Mobiles nuvarande testmetoder. Dessa metoder används för att testa systemkomponenterna i figur Problemformulering För mig, som student vid, var projektets övergripande mål att: Kartlägga de olika faktorer (strategiska, taktiska och operativa) som påverkar de framtida behoven inom SIM-kortskommunikation, samt belysa de olika trender för att ta fram övergripande systemkrav. Ta fram en rapport som behandlar viktiga aspekter för testning samt de grundläggande delarna för kommunikationen mellan ett SIM-kort och en server ansluten till olika klienter. Slutligen, med beaktande av ovannämnda kartläggning samt aktuella trender inom området, tillsammans med Johan André utveckla en prototyp (applikation) som möjliggör testning av SIMkortskommunikation utan att använda sig av GSM-nätet. Kartläggningen behandlar även aspekter rörande tester som utförs i dagsläget med målsättningen att ta fram de delar som är mest tidskonsumerande och enahanda och att eventuellt eliminera dem Avgränsningar Utöver den direkta kommunikationen med ett SIM-kort var det, enligt figur 4, endast de delar inom det skuggade området som skulle utredas; Short Message Service Centre, SMS-C, mobiltelefonen och delar av Transportservern. Denna begränsning gjordes initialt av AU-System Mobile som ansåg att en utredning av dessa delar skulle kunna leda till en förbättring i deras testprocedurer. Figur 4: Systemmiljön, där molnet innesluter de komponenter som skulle modelleras för att eventuellt kunna elimineras. Litteraturstudien valdes att endast inkludera kravhantering, autotester, GSM-systemet med fokus på SIMkort och Short Message Service (SMS) samt AU-System Mobiles egna system. Utöver detta fanns givetvis en tidsbegränsning på 20 veckor, inom vilken arbetet skulle slutföras med en skriftlig rapport. De avgränsningar som påverkat projektet mest har uppkommit vid framtagningen och implementationen av den nya applikation som utvecklats, se under avsnitt (62) DEL I: 1. Inledning 1.3 Mål och syfte
20 1.4 Rapportdisposition Inledningsvis i Del I presenteras AU-System Mobile och bakgrunden till projektet. Därefter följer mål, syfte och avgränsningar. En litteraturstudie inom kravhantering med relaterade problem och vissa lösningar belyses i den första delen av Del II. Den andra halvan av Del II behandlar autotester, hur man bör gå tillväga och tar upp ett flertal olika aspekter kring utvecklandet av autotester. I Del III presenteras en nulägesanalys av telekom, mobiltelefoni och hela SMS-överföringskedjan presenteras där innehållet koncentrerats till de delar som är närmast i testprocessen. Utredningen avslutas med en beskrivning av AU-System Mobiles system och sammanställningen av ett öppet samtal om framtiden med marknadschefen för AU-System Mobile. Del IV, behandlar genomförandet av projektet och inleds med en metodförklaring och mätningar på dagens tester. Sedan följer en beskrivning av hur testerna kan effektiviseras via en applikation. Därefter presenteras tillvägagångssättet med kravidentifiering och arkitekturen hos applikationen. I avsnitt 6 illustreras hur applikationen implementerades och designades samt vilka problem som där uppstod. Avslutningsvis kommer resultatet där prestanda av autotestet diskuteras tillsammans med slutsatserna av införandet av en applikation i testprocessen på AU-System Mobile. 6(62) DEL I: 1. Inledning 1.4 Rapportdisposition
21 Del II Teorier Följande del behandlar de teoretiska aspekterna av kravhantering och automatisering av tester. 2 Kravhantering 2.1 Inledning Kravhantering inriktar sig på vad (och vilka krav som finns på det) som skall designas snarare än hur det designas samt framtagningen av framtidens möjligheter för systemet som skall utvecklas. 2.2 Ett systems användarcykel Enligt Linda Macaulay[21] kan ett systems användarcykel se ut som figur 5. Först identifieras behovet av ett nytt system (eller produkt), därefter införskaffas systemet, installeras och användare tränas för att bruka systemet. Detta resulterar i en viss förändring i företagets arbetssätt och vissa fall blir det även omstruktureringar inom företaget då nya komplexa och omfattande produkter oftast medför nya Figur 5: Ett godtyckligt systems användarcykel [21]. arbetsmetoder. Förändringarna inom ett företag som sker vid integreringen av en ny produkt i det dagliga arbetslivet kan t.ex. vara en ny utvecklingsmetodik eller ett arbetssätt som tillåter att fler medarbetare arbetar i de egna lokalerna. Sedan, när allt gått bra, blir systemet helt integrerat och kan användas fullt ut och runt denna tidpunkt har hela företaget anpassat sig till det nya metoderna. Till slut inträffar den tidpunkt då systemets gränser är 7(62) DEL II: 2. Kravhantering
22 nådda. Det kan vara påverkan från omvärlden, t.ex. nya standarder, statliga lagar etc., eller intern påverkan (större inköp av utrustning till andra avdelningar) som får systemet att nå sin gräns. Då utvärderar företaget ånyo sin situation och beslutar sig för att det finns nya behov som inte är uppfyllda inom företaget och på såsätt är användarcykeln sluten. De behov som ej är uppfyllda kan tas om hand på olika sätt, man behöver inte alltid köpa ett nytt system - det kan ofta räcka med en uppgradering - eller att införa en ny arbetsmetod - eller effektivisera användandet av resurser och personal. Således är kravhantering en lika viktig del för kunder (användarna), då den ger insikt i vad och vilka nya behov som finns (och i viss mån vad som kommer) samt att identifiera hur man kan uppfylla dessa krav. 2.3 Krav Ett krav kan ses ha två grundperspektiv; någonting som en kund behöver och någonting som en utvecklare ser behöver utvecklas - dessa olika sidor betyder sällan samma sak, anser jag. Detta stödjer även Eason[21] då han anser att perspektivet som en intressent har på ett krav är belagd med en barriär gentemot perspektivet en annan intressent har. Enligt IEEE[30] 610 (1990) är ett krav (fritt översatt): 1. Ett tillstånd eller operation som en användare behöver för att lösa ett problem eller nå ett uppsatt mål. 2. Ett tillstånd eller möjlighet som ett system, eller systemkomponent, måste kunna nå eller klara av för att satisfiera ett kontrakt, en standard, en specifikation eller annat formellt uppställt dokument. 3. En dokumenterad representation av villkor enligt 1 och Aktiviteter under kravhanteringsfasen I sin bok om mjukvarukrav från 1993 beskriver Davis[21] två olika aktivitetstyper som uppkommer under kravhanteringsfasen i ett projekt. Den första är problemanalysen, där analytiker brainstormar, intervjuar de människor med störst kunskap om problematiken och identifierar alla möjliga begränsningar i problemets lösningar. Denna aktivitet karakteriseras enligt Macaulay av osäkerhet samtidigt som det sker en ökning av information och kunskap. Den andra aktiviteten är produktbeskrivningen, när det är dags att sammanställa en del svåra beslut samt att på papper beskriva produktens förväntade uppförande och beteende. Denna aktivitet karakteriseras av strukturering av idéer, lösning av olika synsätt och eliminering av konflikter och tvetydigheter. Vidare anser Davis att dessa aktiviteter ej nödvändigtvis behöver vara gemensamt uteslutande eller sekventiella, samt att de olika tekniker som används inom aktiviteterna också kommer att ha skilda karaktärer. I figur 6 introduceras en generell modell av processen för kravinhämtning. Grundidén (Koncept) är den initiala faktorn som startar hela kravhanteringsprocessen och kan till exempel vara en serviceförbättring, ett framtida behov, en mindre systemförbättring (av ett redan existerande system) eller ett behov av att använda en ny tillgänglig teknik. Problemanalysen inriktar sig på att utveckla en förståelse för de olika problem associerade med grundtanken och konceptet. När sedan detta är klart och man erhållit full förståelse för problematiken tas ett antal olika lösningar fram för ytterligare utvärdering i en förstudiefas. Förstudien rekommenderar en lösning som mer i detalj analyseras och modelleras. Varje aktivitet bör avslutas med en kontroll av vad som sammanställts i informationsväg samt vilken ytterligare kunskap som tillkommit. Till slut kan således ett kravdokument, den så kallade kravspecifikationen, sättas samman. En av Macaulays, [21], slutsatser är att kravinsamling är en process mycket hårt knuten till relationen mellan kund och leverantör, vilket inte borde förvåna någon. Eftersom varje skapande av en ny entitet (det kan vara precis vad som helst) inleds med ett behov hos ena sidan som den andra skall uppfylla - och den enkla lösningen är att ha en relation mellan leverantör och kund (tillverkare - köpare) för att kunna utröna vad som kan tillfredställa behovet. Dessutom är processen kring skapandet av en ny produkt inte av konstant eller generell karaktär, utan i de flesta fall beroende på vilken situation som föreligger. Det modellen i figur 6 belyser de stora delar som kravinhämtningen består av och får då anses vara av en generell karaktär. 8(62) DEL II: 2. Kravhantering 2.3 Krav
23 Figur 6: En process för kravhantering [21]. 2.4 Utmaningar i kravprocessen Bubenko[22] lägger i sin Challenges in Requirements Engineering, 1995, fram en del intressanta aspekter kring svårigheterna med kravhantering. Bland annat diskuteras de grundläggande problemen vid kravhantering relaterade till företagsledningar, organisationer, användare, övriga intressenter, metodik, verktyg och utbildning. Bubenko ser kravhantering som det tvärkunskapsområdet av kommunikationen mellan organisationella aktörer och deras visioner, intentioner och aktiviteter vad gäller deras behov av support samt att utveckla och vidmakthålla en adekvat kravspecifikation för ett informationssystem Specifikationsarbetet En kravspecifikation spelar många olika roller vid utveckling och upphandling av ett system. Dels är det ett kontrakt mellan olika intressenter, samtidigt som det är en arkitektur som är en implementationsoberoende bild av det framtida systemet. När sedan systemet är implementerat bör kravspecifikationen brukas som ett kontrollprotokoll för att jämföra det färdiga systemet med det som beställdes. I det ideala fallet skulle en kravspecifikation innehålla delar som beskriver vilka basantaganden som är gjorda, bakomliggande behov, vilken kunskap det finns inom den aktuella problemdomänen - allt detta för att understryka och stödja designen och implementationen av ett informationssystem. En ideal specifikation bör kunna besvara frågor och behandla ämnen som: Varför behövs systemet? Vilka är (de bakomliggande) målen för omgivningen/applikationen? Vilka prioriteringar finns (finns det delar som är viktigare än andra)? Vilka är företagets verksamhetsområden (mål, affärsregler, aktiviteter)? Hur och av vem genomförs de olika delarna? Vilka är de funktionella respektive icke- systemkraven? Utöver den beskrivande delen behövs även metoder i de inledande faserna för att på ett konstruktivt, samarbetsmässigt och effektivt sätt få med användarna. 9(62) DEL II: 2. Kravhantering 2.4 Utmaningar i kravprocessen
24 Vidga begreppen Den ständigt ökande vikten av informationssystem, för att kunna klara av att vara verksam i ett affärsområde, pekar på att förståelsen, för dels själva affärsområdet samt att detektera nya behov och krav, måste ökas. Ett väl fungerande system kan vara en (konkurrensmässig) tillgång medan ett system som ej är anpassat till affärsområdet kan utgöra ett hinder. Det som jag ser som här är att det är en skiftning i hur krav skall beaktas; från det mer tekniskt orienterade aspekterna mot ramverk som modellerar företaget (affärsområdet och affärsmetoder, affärsmål och affärsregler) samt de tekniska aspekterna Problematiken Företagsledningen är oftast inte medveten om den strategiska rollen som kravidentifieringsarbetet spelar och därför får detta arbete inte de resurser och det kapital som behövs. Vidare är ledningens involvering och åtagande i kravhanteringen generellt sett låg och detta implicerar att arbetet med kravhantering normalt inte förknippas med affärsvisioner, affärsmål, förändringar i affärsprocesser eller andra organisatoriska förändringar. Allmänt gäller att organisationer inte tycks lära sig från tidigare erfarenheter av kravhantering[21] - speciellt brukar inte kravspecifikationer användas som kunskapskällor för framtida kravhanteringsprojekt. Organisationer anser sig oftast ligga på en ganska hög mognadsnivå inom informationssystem och kravhantering. Därför anses det oftast inte vara nödvändigt att vidareutveckla metoder och öka kunskapen inom kravhantering hos användare och övriga intressenter vilket medför problem i kommunikationen mellan inblandade parter (utvecklare och användare) och en låg validitet hos kravspecifikationerna. Användarna, å sin sida, antar även de att systemutvecklare kan sin kravhantering och godkänner gladeligen krav utan att till fullo förstå dess innebörd. Detta är grunden till att användare och systemutvecklare är aktiva deltagare i kravidentifieringsprocessen - trots att de inte har full förståelse för vad den andra parten egentligen menar och ej heller har tillräcklig kunskap om hur denna förståelse gemensamt kan (och skall/bör) höjas. Verktyg och metoder Det finns idag ett stort antal kommersiella systemutvecklingsmetoder och CASE-verktyg 4, de flesta är dock inriktade mot de sista faserna i ett systems livscykel. De saknar en strukturerad hantering av de initiala stegen i analysen av affärsmål och kravgenereringsstegen samt att kunna gå mellan en svag informationsdomän till en formell sådan. Macaulay anser att dagens tillgängliga metoder är inte lämpliga att explicit ta hand om en strukturerad insamling och representation av organisatorisk och affärsrelaterad kunskap. De metoder som finns, kommersiella och teoretiska, innebär ett hinder för utvecklarna, anser Macaulay, då de ej helt kan analysera kvalitén på en kravspecifikation. T.ex. är det inte sant att en kravspecifikation alltid i alla situationer måste vara 100% komplett, otvetydig etc. Det finns en mängd olika faktorer och situationer som påverkar och styr den nivån av detaljer och fullständighet som en specifikation har. De ändringar som görs i designstegen dokumenteras sällan i den ursprungliga kravspecifikationen. De CASE-verktyg som idag finns tillgängliga är inte anpassade till kravhantering, då deär ämnade för mjukvaruutveckling och möjligheten att kunna spåra beslut inte stöds. Vidare så finns det heller inga verktyg som klarar av att hantera alla de olika dokumenttyper som ett kravarbete genererar, såsom rapporter, memos, e-post, video etc. Dock så tror jag att ett effektivt e-postprogram klarar av stora delar av det dokumentverktyg som Macaulay saknar. Dagens e-postprogram är utformade för att just visa och hantera en stort antal olika dokumenttyper och filformat. Grundläggande frågeställningar Ett av de mest grundläggande problemen är att det finns för få praktiska undersökningar av kravhantering. Detta innebär att det uppkommer att antal frågeställningar relaterade till hur och varför ett visst verktyg 4 Ericssons PROPS, Rationals ROP [28] 10(62) DEL II: 2. Kravhantering 2.4 Utmaningar i kravprocessen
25 används; Vad finns? Vilka relevanta problemerfarenheter finns? Varför används metod A framför metod B? Blir det färre fel med vissa analyser än med andra? och i så fall varför? Den akademiska utbildningen i mjukvaruutveckling och kravhantering är enligt min uppfattning inte inriktade på praktiskt arbete och därför finns det ett behov av att se över dessa utbildningar med fokus på att ta fram ingenjörer och inte programmerare. 2.5 Fel i kravhanteringsprocessen Enligt Lyytinen och Hirchheim (1987)[21] kan ett misslyckande av ett (informations)system delas in i fyra klasser. Dock så anser Macaulay att endast tre av dessa är intressanta: 1. Processfel, relaterat till den utvecklingsprocess, där budget, tid eller någon annan typ av resursallokation har passerat gränsen där förväntningarna på det föreslagna systemet negligerats eller där de allokerade resurserna resulterar i ett oanvändbart system. 2. Samspelsfel/Interaktionsfel, argumentationen att en lägre utnyttjandegrad av systemet än förväntats kan tolkas som ett misslyckande 3. Felaktiga förväntningar, systemet möter ej de förväntningarna som ställts upp av de involverade grupperna (intressenterna). Tabell 1 illustrerar exempel på orsaker som genererar de olika felen. Värt att notera är att kommunikationen mellan inblandade parter slår hårdast och ger mest konsekvenser när det inträffar. Typ av fel Process Interaktion Förväntan Brist på processystematik Dålig kommunikation mellan människor Bristande kunskap eller gemensam förståelse Otillfredsställande dokumentation Dålig resurserhantering Tabell 1: Fel och dess orsaker som kan uppstå i en kravprocess 2.6 Dokumentering Enligt IEEE , IEEE Guide to Software Requirements Specifications [21, 30], kan en innehållsförteckning över ett kravdokument ha följande struktur: 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2 General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies 3 Specific Requirements 3.1 Functional Requirements Functional Requirement Introduction Inputs Processing Outputs Functional Requirement n Functional Requirement n 3.2 External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communication Interfaces 3.3 Performance Requirements 3.4 Design Constraints Standard Compliance Harware Limitations Attributes Security Maintainability 3.6 Other Requirements Database Operations Site Adaptation... Appendices Index Tabell 2: Innehållsförteckning för ett allmänt kravdokument [21]. 11(62) DEL II: 2. Kravhantering 2.5 Fel i kravhanteringsprocessen
26 2.6.1 Helheten formulerad Denna uppbyggnad, enligt tabell 2, möjliggör ett enkelt sätt att få med de delar och aspekter som ett välskrivet kravdokument bör innehålla, utöver de olika och styrande satskriterierna (figur 7): Figur 7: Betydelsen för ett formulerat krav a) Entydigt/Korrekt: Krav skrivs oftast i vanliga språk där satser kan ha olika betydelser. Där det är tillämpbart bör man använda formella språk som kan detektera lexikala, semantiska och syntaktiska oegentligheter. b) Komplett: Ett kravdokument är komplett om det innehåller samtliga signifikanta krav (funktionella, prestanda, designbegränsningar etc.). c) Testbar och Verifierbar: Ett krav skall vara av sådan art att det är möjligt att verifiera kravet, d.v.s. kravet skall vara mätbart. d) Konsistent: Ett krav skall endast ha ett namn och beskrivas med samma termer (vid alla refereringar till det). e) Spårbart: Härkomsten av krav bör alltid klart framgå för att på så sätt möjliggöra spårbarhet bakåt för att se vilket eventuellt beslut som föreligger, samt spårbarhet framåt för att möjliggöra en översikt av de dokument som härrör från ett visst kravdokument. Man bör även ta med motivet bakom ett krav för att ytterligare belysa vilka faktorer som ligger till grund för kravet (m.a.o. ett sätt att öka att förståelsen av kravets ursprungliga betydelse). Detta kan vara till hjälp när utvecklingen av ett system och dess miljö genomgår förändringar 5. Återkoppling till de efterkommande faserna Utöver att kraven skall vara väl beskrivna bör ett kravdokument vara modifierbart, d.v.s. skriven på ett enhetligt sätt, t.ex. enligt IEEE-guiden i tabell 2. En enhetlig struktur förenklar både framtida modifieringar och läsbarheten vilket gör dokumentet mer användbart (m.a.o. så att det även kan vara till användning i drift och underhållsfaserna). 5 Intressant aspekt som min handledare vid, Erik Johansson, påpekade 12(62) DEL II: 2. Kravhantering 2.6 Dokumentering
27 Macaulay understryker även att det skall vara en distinkt skillnad mellan utvecklingsmodellen och den modell som beskriver mjukvaruimplementationen. Utvecklingsmodellen bör, enligt Verheijen och Van Bekkum, 1982[21], också innehålla följande delar: 1. En hög abstraktionsnivå, från användarnas perspektiv, och den bör innefatta och integrera användarnas koncept på ett tidigt stadium. 2. Mänsklig läsbarhet. Det använda språket bör vara av enkel natur, vilket i sin tur innebär problem vid användningen av kravdokument skrivna med ett formellt språk. Det viktiga är att det inte finns svårigheter att förstå den beskrivna modellen. 3. Precision, ett högnivåspråk bör användas för att definiera tillämpningsområde, systemgränser, namngivning av objekt, regler, processer mm. 4. Specifikationens helhet. Den använda modellen skall på ett klart och tydligt innefatta alla aspekter. 5. Överföring till efterföljande faser, detta med anledning att de faser som följer kravdefinitionsfasen skall kunna få en konstruktiv input, så måste modellen ha en sådan struktur att det lämpar sig att överföra den information som behövs till de efterkommande faserna. Läsbarhet ställt emot formalism I de två senaste uppräkningarna, 2 respektive a), introduceras en tvetydighet. I det ena fallet menar man på att formella språk som kan detektera lexikala, semantiska och syntaktiska oegentligheter bör användas för att beskriva krav. I det andra fallet föredras att språket bör vara av enkel natur för att öka förståelsen. Vad som är bäst avgör situationen; om det är en intern förstudie tror jag att språket är mer åt det läsbara, dåläsaren kan fråga författaren, som en kollega, vad en formulering syftar till. Men om det är en offert anser jag att det lönar sig att använda ett mer strikt och formellt språk. En allmänt bra metod är att definiera terminologin (ord, formuleringar, förkortningar, namnkonventioner etc.) som en del i kravdokumenten Kravhanteringen i utvecklingsprocessen Utöver ett välformulerat kravdokument behöver processen för kravhanteringen fogas samman med utvecklingsprocessen. Hur detta görs på bästa sätt finns det nog ingen som vet - det är därför det finns så många olika utvecklingsmetoder och tillhörande verktyg 6. Det som kravprocessen tillför utvecklingsprocessen är: 1. en överenskommelse - vad som gäller för de inblandade intressenterna 2. en beskrivning av kraven för utvecklarna - de får en (helhets)bild av vad som skall utvecklas 3. begränsningarna - inom vilka gränser som kraven gäller och håller, samt 4. en informationsbas - bakgrund (motiven), vilka faktorer som är intressanta. Min uppfattning är att resultaten ifrån processen av kravhantering, krav och kravdokument, måste förmedlas vidare till de följande utvecklingsfaserna. Jag tror att detta leder till en bättre hantering och krav - kraven kan på så sätt bli lättare att uppfylla och genomföra om de iblandade personerna har tillgång till kravdokumenten. Detta förutsätter visserligen att de inblandade personerna aktivt tar del av materialet. 6 Bakom referensen Tero Ahtee[28] döljer sig mer än 60 olika CASE-tools och utvecklingsmodeller 13(62) DEL II: 2. Kravhantering 2.6 Dokumentering
28 3 Automatiserad testning Dagens mjukvarusystem är oftast utrustade med grafiska användargränssnitt (Graphical User Interfaces). Med alla olika möjligheter som finns att interagera med användarna och det stora antalet kontrollelement (knappar, rullgardinmenyer, toolbars) som användargränssnitten har, blir testningen av dessa extremt tidskrävande och kostsamma. Att utföra dessa tester manuellt är arbetsamt, monotont och ouppskattat av de flesta utvecklare och testare. Det finns dock möjligheter att automatisera dessa tester med kommersiella mjukvarubaserade verktyg. 3.1 In- och uppspelningsverktyg In- och uppspelningsverktyg, Capture-and-Replay tools (CR-verktyg), är oftast objektorienterade och uppfattar alla delar i ett grafiskt användargränssnitt som objekt och registrerar de olika delarnas innehåll (namn, färg, värde) och inte bara dess X/Y-koordinater vid ett musklick. Vid en inspelning spelas all manuell användarinteraktion på testobjektet in och stegen sparas i ett skriptspråk med liknande syntax och semantik som C eller Basic. Ett inspelat skript kan sedan spelas upp hur många gånger som helst. Om testobjektet under en uppspelning uppträder annorlunda än det gjorde vid inspelningen registreras detta som ett fel av CR-verktyget Testning av användargränssnitt I ett system med ett grafiskt användargränssnitt är alla funktioner i gränssnittet representerade via interaktions punkter (IP) och dessa aktiveras genom att markera dom, t.ex. med musen. Att identifiera samtliga IP är inte något större problem för en människa även om, eller när, det sker förändringar i gränssnittet. Denna identifiering skall även CR-verktygen klara av, vilket av förklarliga skäl inte är det lättaste att implementera. CR-verktygen känner igen delarna i det grafiska gränssnittet via deras objektidentifierare och är därför känsliga för ändringar av värdet på dessa. Till detta tillkommer även att vissa mjukvaruutvecklingsmiljöer ibland ändrar identifierarna på grafiska gränssnittsobjekt, utan att underrätta utvecklaren (därför att utvecklaren inte skall behöva ha ansvar för tilldelningen av de individuella identifierarna). Så situationen vid användandet av CR-verktyg och förändringar i det grafiska användargränssnittet gör dessa testfall ganska problematiska. För att ge mjukvaruapplikationer ett enhetligt användarintryck, har utvecklare försökt ta fram layoutregler, Style Guides, där det exempelvis finns beskrivningar som: OK och Cancel är alltid placerade vid botten eller till höger och aldrig till vänster eller högst upp. Alla fält måste vara nåbara via tabbar i samma ordning Regressionstest Ett regressionstest är ett test som programrelease N passerat och som release N + 1 testas med för att se hur N + 1 versionen uppträder. Regressionstestverktyg för grafiska användargränssnitt finns i två varianter: 1. Första generationens inspelningsverktyg. Dessa spelar in musrörelser eller tangentnedtryckningar och tar ögonblicksbilder av pixlarna på skärmen. Dessa verktyg genererar tester som inte går att underhålla, för när det sker en minsta ändring på skärmen 7 så slutar testet fungera. Skärmbildens utseende och layout ändras vanligtvis så pass ofta att supporten (de manuella uppdateringarna) för dessa tester blir testpersonalen övermäktig och därmed blir testerna oanvändbara och dyra. 2. Andra generationens verktyg liknar de första men har även möjligheter för att använda testskript. Dessa är användbara då man kan kapsla in skriptkod med ett eget utvecklat API (Application Programing Interface). Ett inspelat skript kan ha liknande innehåll som figur 8-a illustrerar, medans ett skript, med ett API, kan ha strukturen som i figur 8-b. 7 klockan, e-post indikation etc. är förödande vid inspelningen av ett test. 14(62) DEL II: 3. Automatiserad testning
Nulägesanalys & Kravspecifikation
Nulägesanalys & Kravspecifikation Thord Schibler/Johan André Examensarbetare vid AU-System Mobile 1999 3 augusti 1999 Innehåll Ordlista & Förkortningar 1 1 Bakgrund 2 1.1 Inledning... 2 1.2 Avgränsningar...
Läs merFöreläsning 10 Mål Förse en översikt av mobilnätens utveckling Förstå komponenterna i ett mobilt nät. Mobila nätverk (1/5) Mobila nätverk (2/5)
Föreläsning 10 Mål Förse en översikt av mobilnätens utveckling Förstå komponenterna i ett mobilt nät Material Bengt Sahlin (2004) Föreläsning Ursula Holmström 01.11.2004 Bengt Sahlin 1 Mobila nätverk (1/5)
Läs merSänk kostnaderna genom a/ ställa rä/ krav och testa effektivt
Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning
Läs merCreo Customization. Lars Björs 2014-10-16
Creo Customization Lars Björs 2014-10-16 Norra Europas största partner och återförsäljare av PTC relaterad programvara (Windchill, Creo, Arbortext, MathCad, Relex) 70 anställda Egen utvecklingsavdelning
Läs merStartrapport 99-06-22
1 Bakgrund 1.1 Thord Jag,, besökte under våren 1999 ELARM, Elektrosektionens Arbetsmarknadsdag.Mitt mål var den dagen att få ett exjobb, eller åtminstone ett förslag eller en kontakt.jag ville även ha
Läs merDialogue Technologies April 2005
Dialogue Technologies April 2005 En typisk självbetjäningstjänst för web ser ut enligt följande En inledande text för att användaren skall förstå tjänsten En aktuell lista med de 10 vanligast frågorna
Läs merMobilteknik. Begränsningar och möjligheter
Mobilteknik Begränsningar och möjligheter Mobilteknik Begränsningar Skärmstorlek, läsbarhet i solljus Datahastighet i luften Batteritid, Prestanda, minnesstorlek Olika tekniker/standarder Möjligheter Beräkningar
Läs merTestplanering, test-first, testverktyg
Testplanering, test-first, testverktyg Mats Skoglund Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Stockholm, Sweden 12 mars 2007 Mats Skoglund Page 1(33)
Läs mer2014-2015 Alla rättigheter till materialet reserverade Easec
1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL
Läs merSystemspecifikation. Thord Schibler/Johan André Examensarbetare vid AU-System Mobile augusti
Systemspecifikation Thord Schibler/Johan André Examensarbetare vid AU-System Mobile 1999 16 augusti Innehåll 1 Introduktion 1 2 Design av mjukvaruarkitektur 1 2.1 Faser.... 1 2.1.1 Indelning... 1 2.2 Detaljerad
Läs merRapport Version 1.0 Johan Aldén Sida 1 av 12 2011-04-25. Rapport Förstudie Elevadministration och schemaläggning Sambruk
Johan Aldén Sida 1 av 12 Rapport Förstudie Elevadministration och schemaläggning Sambruk Johan Aldén Sida 2 av 12 Innehållsförteckning Inledning... 4 Deltagande kommuner... 4 Sammanfattning... 5 Förstudiens
Läs merSå säkerställer du affärsnyttan för dina produkter
Så säkerställer du affärsnyttan för dina produkter Den här guiden ger dig konkreta tips på hur du skapar en effektiv kravprocess som ökar affärsnyttan i ditt företags leveranser. Den här guiden ger dig
Läs merSF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0
Test summary SF Bio App. Repport Författare: Zina Alhilfi Datum: 2017-03-13 Version: v1,0 Granskad: Klar Ref: Test plan V1,0 Status: klar 1- Syfte Syftet med denna slutrapport är att redovisa vilka testaktiviteter
Läs merTestbara krav. SAST Syd 2012-02-09. Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt
Testbara krav SAST Syd 2012-02-09 Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt Ulf Eriksson Produktägare på ReQtest Specialist på kravhantering och test Grundare
Läs merQC i en organisation SAST 2008-09-16
QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har
Läs merUndervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande:
WEBBUTVECKLING Ämnet webbutveckling behandlar de tekniker som används för att presentera och bearbeta information i webbläsaren samt utifrån dessa tekniker skapa och vidareutveckla statiska och dynamiska
Läs merPMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning
PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer
Läs merProgramutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document
Programutvecklingsprojekt 2003-04-24 Projektgrupp Elvin Detailed Design Document Björn Engdahl Fredrik Dahlström Mats Eriksson Staffan Friberg Thomas Glod Tom Eriksson engdahl@kth.se fd@kth.se d94-mae@nada.kth.se
Läs merRegressionstestning teori och praktik
Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification
Läs merSå gör Vägledningen 24-timmarswebben dig till en bättre beställare. Funda Denizhan, Statskontoret Kommits 17 november, 2005
Så gör Vägledningen 24-timmarswebben dig till en bättre beställare Funda Denizhan, Statskontoret Kommits 17 november, 2005 Om IT och webb inte är en teknikfråga vad är det då? Är IT och webb en verksamhetsfråga?
Läs merVisionen om en Tjänstekatalog
Visionen om en Tjänstekatalog Varför ska vi införa tjänster? Copyright BiTA Service Management/Rolf Norrman 1 IT:s värde för verksamheten tydliggörs i verksamhetens egna termer Organisationens kundfokus
Läs merVisuell GUI Testning
Visuell GUI Testning Vad är ett Graphical User Interface (GUI)? Icke-animerat GUI Animerat GUI Nuläget System- och acceptanstestning är dyrt! Manuellt Långsamt Enformigt Svårt att replikera exakt Nödvändigt
Läs merLåt oss ta hand om din utveckling, medan du själv utvecklar ditt företag
Låt oss ta hand om din utveckling, medan du själv utvecklar ditt företag *vad är SmartCode? Vi gör ett komplett utbud av tjänster. Vi designar, utvecklar, stödjer och uppdaterar allt som fungerar i Web.
Läs merWebbserverprogrammering
Webbserverprogrammering WES Webbserverprogrammering Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets
Läs merIntressent- och behovskarta
Dokument nr: Version: Status: Sida: 1 Utgåva (0)6 Dokumenttyp: Projekt: Projektnummer: Leveransrapport ehälsa/mobilitet 1403 Dokumentbeskrivning: Intressent- och behovskarta Utfärdat av: Utf datum: Godkänt
Läs merGodkännande av kundapplikationer
samhällsskydd och beredskap 1 (9) Godkännande av kundapplikationer MSB-50.2 samhällsskydd och beredskap 2 (9) Innehållsförteckning 1 Alla applikationer måste godkännas... 3 1.1 Hur går ansökan om godkännande
Läs merFrågor och svar till tentamen i Kravhantering
Frågor och svar till tentamen i Kravhantering Del 1 Frågor & svar Frågor&svar till tentamen 1 Datamodeller (0.5p) När man tar fram data krav skriver Lausen i sin bok, gällande data modeller, att det finns
Läs mercampus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning
campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande
Läs merVektorkartor för mobila terminaler
Vektorkartor för mobila terminaler Magnus Janlert 3 juni 2004 Introduktion Externt examensarbete, utfört VT2003 Visualiseringscentrum, c:a tio anställda, en del av Lantmäteriet Handledare: Jerry Eriksson
Läs merMetoder och verktyg för funktionssäkerhet
Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och
Läs mermen borde vi inte också testa kraven? Robert Bornelind
men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST 15 års jubileum 14 oktober 2010 SQS Software Quality Systems Nordic Innehåll Introduktion Kvalitet, tid och kostnad Process Testning
Läs merLaborationsrapport av robotprogrammering
KUNGLIGA TEKNISKA HÖGSKOLAN Laborationsrapport av robotprogrammering Programmering av LEGO MINDSTORMS robot Rikard Bjärlind 2012-09-07 E-post: bjarlind@kth.se Introduktionskurs i datateknik (H12) II1310
Läs merObjektorienterad programmering
Objektorienterad programmering Emil Ahlqvist (c10eat@cs.umu.se) Didrik Püschel (dv11dpl@cs.umu.se) Johan Hammarström (c08jhm@cs.umu.se) Hannes Frimmel Moström (c10hml@cs.umu.se) 1 1. Introduktion 1.1 Objektorienterad
Läs merUtveckling av ett grafiskt användargränssnitt
Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat
Läs merNätinterna nummer och nummer för SMS-tjänster
REMISS HANDLÄGGARE, AVDELNING/ENHET, TELEFON, E-POST Pamela Davidsson Teleavdelningen 08 678 55 93 pamela.davidsson@pts.se DATUM VÅR REFERENS 11 april 2003 02-13500 Nätinterna nummer och nummer för SMS-tjänster
Läs merJavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08
JavaRats Kravspecifikation Version 1.1 Gustav Skoglund gussk258@student.liu.se Marcus Widblom marwi026@student.liu.se Senast ändrad: 13 / 05 / 08 Sammanfattning Kravspecifikationen för JavaRats har skrivit
Läs merDyna Pass. Wireless Secure Access
Dyna Pass Wireless Secure Access Säkerheten kring lösenord är ofta debatterad och det finns ett antal viktiga frågor man bör ställa sig. Några exempel på detta är: Hur stor risk ligger i den mänskliga
Läs merBeijer Electronics AB 2000, MA00336A, 2000-12
Demonstration driver English Svenska Beijer Electronics AB 2000, MA00336A, 2000-12 Beijer Electronics AB reserves the right to change information in this manual without prior notice. All examples in this
Läs merPå kommande sidor kan du läsa mer om CFI, dess innehåll och uppbyggnad.
Undrar du hur cheferna fungerar? Genom att mäta det kommer ni att veta. Vill ni vässa styrningen av verksamheten? Det är cheferna som gör jobbet. Behöver ni förstärka den gemensamma chefskulturen? Kulturen
Läs merFrågor och svar. (version )
Frågor och svar (version ) Fråga 1. Kan Ni närmare förklara vad det avses med e-tjänsteplattformen som en service (PaaS) där leverantören tillhandahåller servrar, lagring och tjänster? (1.2.2 Service,
Läs mervad kan det göra för mobila användare?
artikel Upptäck WWAN med bredband Upptäck WWAN med bredband vad kan det göra för mobila användare? Det blir allt viktigare med en snabb och smidig Internetuppkoppling för att lyckas i arbetet och vara
Läs merNågra grundläggande begrepp
Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen?
Läs merParaGå-guide -kommunala utförare
ParaGå-guide -kommunala utförare Viktig information Sid. 2 Aktivera låskod på enheten Sid. 4 Skapa Google-konto Sid. 8 Installera Mobileiron och ParaGå appen Sid. 10 Genväg ParaGå Sid. 18 Support Sid.
Läs merCalligra. En allmän inledning. Raphael Langerhorst Jost Schenck Översättare: Stefan Asserhäll
En allmän inledning Raphael Langerhorst Jost Schenck Översättare: Stefan Asserhäll 2 Innehåll 1 Inledning 5 1.1 Komponenter i Calligra.................................. 5 1.2 Översikt över funktioner i
Läs mermen borde vi inte också testa kraven?
men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av
Läs merChrister Scheja TAC AB
Byggnadsautomation för ingenjörer Byggnadsautomation för ingenjörer VVS-tekniska föreningen, Nordbygg 2004 Christer Scheja TAC AB resentation, No 1 Internet/Intranet Ihopkopplade datornät ingen ägare Internet
Läs merTest specifikation. SF Bio App. Författare: Zina Alhilfi Datum: Version: v1,0. Granskad: Klar Ref: Testplan_v1.
Test specifikation SF Bio App. Författare: Zina Alhilfi Datum: 2017-03-07 Version: v1,0 Granskad: Klar Ref: Testplan_v1.0 Status: Klar 1. Introduktion 1.1 Syfte och omfattning 1.2 Terminologi 1.3 Referenser
Läs merOppositionsrapport. Opponent: Therese Sundström. Respondent: Malin Abrahamsson & Aleksandra Gadji
Oppositionsrapport Opponent: Therese Sundström Respondent: Malin Abrahamsson & Aleksandra Gadji 2005-06-07 1 1 Huvudpunkter I denna sektion kommer jag att presentera de huvudpunkter som jag vill kommentera.
Läs merFöreläsning 2: Projekt, Kravhantering, Dokumentgranskning
ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning Jonas Wisbrant 2 Detta har hänt... Pratat krav Bildat projektgrupper :-) Skaffat litteratur?
Läs merKravspecifikation Fredrik Berntsson Version 1.1
Kravspecifikation Fredrik Berntsson Version 1.1 Status Granskad FB 2016-02-01 Godkänd FB 2015-02-01 Dokumenthistorik Version Datum Utförda ändringar Utförda av Granskad 1.0 2015-02-01 Första versionen
Läs merChaos om datorprojekt..
Systemutveckling och användbarhet Användarcentrerad systemutveckling, gränssnitt och prototyper. Referens till avsnitt i kursboken Dix kapitel 6 Gulliksen, Göransson: Användarcentrerad systemdesign, kapitel:
Läs merWEBBSERVERPROGRAMMERING
WEBBSERVERPROGRAMMERING Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets syfte Undervisningen i ämnet
Läs merTestning som beslutsstöd
Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten
Läs merTrackBlock Tracking System Bruksanvisning 2012-09-08
TrackBlock Tracking System Bruksanvisning 2012-09-08 Tack för att du valt TrackBlock Tracking System. Denna produkt är en kombination av GPS och GSM som hjälper dig att spåra bilar, båtar, arbetsmaskiner
Läs merBakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1
Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut
Läs merDesignmönster - EMW. Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.
Designmönster - EMW Kent Petersson epost1: kentp@cs.chalmers.se epost2: kent.petersson@emw.ericsson.se URL: http://www.cs.chalmers.se/~kentp arbetar på Inst. för Datavetenskap, Cth & Gu, 50% och Software
Läs merVad är. Domändriven design?
Vad är Domändriven design? 1 Domändriven design är utvecklare och domänexperter som arbetar tillsammans för att skapa mjukvara som är både begriplig och möjlig att underhålla. ett sätt att fånga och sprida
Läs merTitel Mall för Examensarbeten (Arial 28/30 point size, bold)
Titel Mall för Examensarbeten (Arial 28/30 point size, bold) SUBTITLE - Arial 16 / 19 pt FÖRFATTARE FÖRNAMN OCH EFTERNAMN - Arial 16 / 19 pt KTH ROYAL INSTITUTE OF TECHNOLOGY ELEKTROTEKNIK OCH DATAVETENSKAP
Läs merExempel på verklig projektplan
Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av
Läs merUtvärdering av personlarm med GPS
Utvärdering av personlarm med GPS Förutsättningar: EmCom har fått i uppdrag att utvärdera och analysera batteriprestandan hos två personlarm av olika fabrikat genom att ansluta dessa till vårt system och
Läs merDetta har hänt... Kursinformation. Agenda. Kursinformation
Detta har hänt... Pratat krav Bildat projektgrupper :-) Skaffat litteratur? Kommit igång med projektwikin: Formulerar krav Genomfört en övning: Hur var den? ETSA01 Ingenjörsprocessen för programvaruutveckling
Läs merFöreläsning 2: Projekt, Kravhantering, Dokumentgranskning
ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning Jonas Wisbrant 2 Detta har hänt... Pratat krav Bildat projektgrupper :-) Skaffat litteratur?
Läs merSara Skärhem Martin Jansson Dalarna Science Park
Sara Skärhem Martin Jansson Dalarna Science Park Sara Skärhem Martin Jansson Vad är innovation? På Wikipedia hittar man: En innovation är en ny idé, till exempel i form av en produkt, lösning, affärsidé,
Läs merDecentraliserad administration av gästkonton vid Karlstads universitet
Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration
Läs merProduktspecifikation Bitstream FTTx
Produktspecifikation Bitstream FTTx 1 Allmänt 2 2 Teknisk beskrivning 2 2.1 Nätnivåer 2 2.2 Anslutning av slutkundsplacerad utrustning 2 2.3 Tjänster & Prestanda 3 2.3.1 Internetaccess/Surf Consumer samt
Läs merTDDC74 - Projektspecifikation
TDDC74 - Projektspecifikation Projektmedlemmar: Namn Efternamn abcde123@student.liu.se Namn Efternamn abcde123@student.liu.se Handledare: Handledare handledare@ida.liu.se eller handledare@student.liu.se
Läs merMANUAL MOBIL KLINIK APP 2.2
MANUAL MOBIL KLINIK APP 2.2 Innehåll Innan appen tas i bruk 2 Registrera besök manuellt 6 Dokumentera besöket 7 Registrera besök med NFC-tagg 7 Planera nytt besök 9 Avboka besök 10 Patienter 10 Anteckningar
Läs merOntech Control för Android Användarmanual Svenska
Ontech Control för Android Användarmanual Svenska Inställningar Innan du använder denna app första gången så måste du ställa in den. Meny knapp Tryck på Meny knappen på startsidan och sedan Settings. Välj
Läs meropenbim Stockholm 22 april 2013 Kraven på BIM är här
openbim Stockholm 22 april 2013 Kraven på BIM är här Vi fick några frågor Kan gemensamma, formella och neutrala krav formuleras? Hur kommer sådana krav att påverka och befästa arbetssätt, processer, informations-
Läs merKlient/server. Översikt. Lektion 1: Webbtekniker från Microsoft. Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning.
Klient/server Översikt Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning. Lektion 1: Webbtekniker från Microsoft Microsoft webbtekniker. ASP.NET. Klientsidan. Internet Information Server.
Läs merAbelko Terminal. Användarmanual. Giltig för FIRMWARE version 2.4/2.5 och 15, 17 och 19 tums modeller
Abelko Terminal Användarmanual Giltig för FIRMWARE version 2.4/2.5 och 15, 17 och 19 tums modeller Abelko terminalen är en panel pc avsedd att monteras i kontrollpaneller eller skåp som display och gateway
Läs merInnehåll. Kravhantering. Kravhantering TDDD06 Introduktion till kravhantering. Vad är kravhantering?
Innehåll Kravhantering TDDD06 Introduktion till kravhantering Institutionen för datavetenskap (IDA) Linköpings universitet Kravhantering Omfattning Grundläggande koncept Aktörer Aktiviteter Artefakter
Läs merRapport i Mobila systemarkitekturer. Symbian
Rapport i Mobila systemarkitekturer med Symbian Kommunikation Datum: 2008-05-19 Namn: Kurs: Henrik Bäck HI101V Innehållsförteckning Inledning 3 Trådlös kommunikation 3 NMT 3 GSM 3 UMTS 3 802.15.1 (Bluetooth)
Läs merTentafrågor 1. Grupp. B
Tentafrågor 1 Grupp. B Sebastian Buks (ic05sb3@student.lth.se) Andreas Edmundsson (ic05ae6@student.lth.se) Birger Hedberg-Olsson (ic05bh3@student.lth.se) Omar Khan (ic05ok5@student.lth.se) Victor Lindell
Läs merProblemet. Beställarkompetens och kravhantering. Användbarhetsboom Internet som motor. Beställarproblemet. Användarnytta = verksamhetsnytta.
Problemet Beställarkompetens och kravhantering Trots mycket kunskaper inom människadatorinteraktion så är användare missnöjda med systemen, eller klarar helt enkelt inte av att göra det de önskar eller
Läs merFramsida Titelsida ii Trycksida iii Abstract iv Sammanfattning v Förord vi Tom vii Innehållsförteckning 1 Introduktion... 1 1.1 Bakgrund... 1 1.2 Inledning... 1 1.2.1 Kaprifolen... 2 1.3 Syfte... 2 1.4
Läs merProduktspecifikation Bitstream DSL Business
Produktspecifikation Bitstream DSL Business 1 Allmänt 2 2 Teknisk beskrivning 2 2.1 Nätnivåer 2 2.2 Anslutning av Slutkundsutrustning 2 2.3 Tjänster och Prestanda 3 2.4 Hastigheter 3 2.5 VoIP access 4
Läs merSTADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5)
Läs mig först Stockholms stad SOA-plattform 1 (5) Innehållsförteckning 1 Beskrivning av SDK 3 1.1 Software Developer Kit för Utvecklare... 3 1.2 Support för... 3 1.3 Omfattning... 4 1.4 Versionshantering...
Läs meriphone app - Users Net2 AN1116-SE Allmänt Starta Appen
iphone app - Users Allmänt Denna app finns tillgänglig hos Apple App Store. Appen fungerar på alla iphone eller ipad med ios 5.1 eller högre. Starta Appen När Appen laddats ner och installerats finns ikonen
Läs merMekanismer för mediadistribution
Mekanismer för mediadistribution Slutrapport David Erman, Revision: 1121 1 Inledning Detta dokument beskriver kort resultaten för projektet Mekanismer för mediadistribution, som finansierats
Läs merKursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014
Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign eller Webbutveckling 1 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se
Läs merFrågor och svar 3 Mobila larmenheter, dnr A /2016
Frågor och svar 3 1 (5) Datum 2016-11-17 Diarienr (åberopas vid korresp) A262.555/2016 Upphandlande myndighet Polismyndigheten Frågor och svar 3 Mobila larmenheter, dnr A262.555/2016 Nedanstående svar
Läs merKreativitet som Konkurrensmedel
www.realize.se 1 Kreativitet som Konkurrensmedel Vi är på väg in i Idésamhället. Ord som kreativitet och innovation upprepas som ett mantra. Det är många som vill. Det är färre som kan. Realize AB är ett
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar hur mjukvaror skapas, anpassas och utvecklas samt programmeringens roll i informationstekniska sammanhang som datorsimulering och praktisk datoriserad problemlösning.
Läs mertillägg till AnvändarmANUAL För LarmSystemet Lansen Home Installera, Använda och Administrera
tillägg till AnvändarmANUAL För LarmSystemet Lansen Home Installera, Använda och Administrera Innehåll 1 Externa antenner 2 GSM/GPRS 3 MMS 4 Ethernet inställningar 5 Fjärrhjälp OBS! För grundläggande information
Läs merProduktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000
Document: STG/PS K 525SV1 Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000 SIS, Projekt Kvalitetsledning 1 1) Introduktion Produktstöd Två av de viktigaste målsättningarna i arbetet
Läs merConfiguration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar
Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault
Läs merThe present situation on the application of ICT in precision agriculture in Sweden
The present situation on the application of ICT in precision agriculture in Sweden Anna Rydberg & Johanna Olsson JTI Swedish Institute for Agricultural and Environmental Engineering Objective To investigate
Läs merConfiguration Management
Configuration Management En möjliggörare för värdeskapande smart industri CM Forum SIS TK 280, TK 611 och CM vad är kopplingen? Er digitala information bör vara beskaffad så här! Era identifierare bör
Läs merDatalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001
Datalagringsmetodik och arkitektur i Java Projektdefinition Dokumenttitel Projektdefinition Dokumentansvarig Dokumentförfattare Björn Brenander Dokumentnamn Projektdefinition.doc Version 16 Ref. nr. Skapades
Läs merAnvändarcentrerad Systemutveckling
Användarcentrerad Systemutveckling Människadatorinteraktion (MDI) Inst. för informationsteknologi http://www.it.uu.se/edu/ course/homepage/hci/ ht10 Användarcentrerad systemutveckling, gränssnitt och prototyper.
Läs merChaos om IT-projekt..
Användarcentrerad systemutveckling, gränssnitt och prototyper. Lämplig extraläsning Gulliksen, Göransson: Användarcentrerad systemdesign, Studentlitteratur, kapitel: 4, 5, 6, 7, 8, 9 (Bredvidläsning) Syfte
Läs merKravspecifikation. 1. Introduktion. 2. Övergripande beskrivning. 1.1 Syfte. 1.2 Omfattning. 1.3 Definitioner och förkortningar. 1.
Kravspecifikation 1. Introduktion 1.1 Syfte Syftet med det här dokumentet är att ange kraven för spelet Bilspel. Dokumentet täcker bara konsumentens del av kravspecifikationen. Kraven ska vara specificerade
Läs merUndervisningen i ämnet mobila applikationer ska ge eleverna förutsättningar att utveckla följande:
MOI Ämnet mobila applikationer behandlar olika tekniker för att utveckla programvara riktad mot mobila enheter samt processen från idé till färdigt program. Ämnet mobila applikationer får bara anordnas
Läs merStyrteknik 7.5 hp distans: E-1000 och E-Designer
PLC8A:1 E1000 operatörsterminaler En operatörsterminal ger ett gränssnitt mellan männinska-maskin, (MMI människa-maskininteraktion, HMI Human Machine Interface) Alla terminalerna i E1000-serien är utvecklade
Läs merStudentsynpunkter? Vad menas med IT i organisationer. Moderna affärsstrategier. Beskriva organisationer ur olika perspektiv.
Moderna affärsstrategier Beskriva organisationer ur olika perspektiv F2 Vad menas med IT i organisationer IT i organisation Vad är en organisation? Vad menas med perspektivet IT i organisationer? Studentsynpunkter?
Läs merFilhanterare med AngularJS
Filhanterare med AngularJS Författare: Filip Johansson Peter Emilsson Oskar Georgsson Christian Nilsson Datum: 2014-03-26 1 Sammanfattning Filhanterare med AngularJS är en filhanterare skapad för Sigma
Läs merX-jobbs katalog. Medius R&D November 2011
X-jobbs katalog Medius R&D November 2011 Contents ERP och Workflow System... 2 ipad och workflow system... 3 Nya möjligheter med HTML5... 4 Nya alternativ för affärsregelmotorer... 5 Process Intelligence
Läs merDag König Developer Tools Specialist Microsoft Corporation
Dag König Developer Tools Specialist Microsoft Corporation Magnus Timner Transcendent Group Olov Mattsson Know IT Krav Testning Microsoft Team System Arkitektur Bygga Kodning Vinn en XBOX 360 Elite Alla
Läs mer