<p>I dagens mjukvaruutvecklingsprocess används olika hjälpmedel för att underlätta och automatisera vissa delar av processen. CASE-verktyg används exempelvis för att översätta konceptuella scheman till SQL-scheman. En användare av dessa hjälpmedel förutsätter att producerat resultat blir det samma som om det gjordes manuellt. På grund av att det kan alltid förekomma mänskliga fel när översättningen görs manuellt anses CASE-verktygen också som hjälpmedel för att upprätthålla kvalitet. Att CASE-verktygen utför det arbete på det sätt deras leverantörer påstår är ett basvillkor som inte får sopas under mattan.</p><p>Målet med projektet var att göra en systematisk analys av CASE-verktygs förmåga att översätta konceptuella scheman till SQL. Genom att identifiera eventuell semantikförlust i översättningsprocessen vore det möjligt att generera en representativ mängd testscheman för att testa andra CASE-verktygs översättningsförmåga.</p><p>För att undersöka CASE-verktygs översättningsförmåga utförde jag tester på två mycket använda CASE-verktyg. Först gjorde jag en pilotstudie för att samla information och öka min kunskap om både CASE-verktygen och översättnings-processen. En senare testning, med mer komplexa scheman, utfördes för att ge grund till mer generella slutsatser. Samtliga tester utfördes genom att översätta konceptuella scheman till SQL och sedan tillbaka till konceptuella scheman igen. Genom att jämföra det ursprungliga schemat med resultatet var det möjligt att konstatera eventuell semantikförlust i processen.</p><p>Även om jag hade anat att en del av den semantik som uttrycks på den konceptuella nivån skulle förloras i översättningen till SQL var testresultaten mycket förvånande. CASE-verktygen klarade endast översätta ett fåtal konceptuella konstruktioner (primitiver) på ett korrekt sätt. När mer komplexa scheman testades visade det sig att ökad komplexitet var inte ett problem om CASE-verktyget klarade översättning av de primitiver som användes i scheman.</p><p>Att utforma en representativ mängd testscheman för att testa andra CASE-verktyg var ett av målen med dess studier. De CASE-verktyg som används i dag använder olika konceptuella notationer. En bra början är att testa om ett CASE-verktyg klarar av att korrekt översätta samtliga primitiver som stödjs av notationen och/eller CASE-verktyget. Hur testningen utformas vidare är beroende av vad som skall modelleras och då vad som anses viktigt att kunna uttrycka i konceptuella scheman.</p>

<p>Metoder för systemutveckling består av ett antal faser där verksamhetsanalysen ingår innan själva utvecklingen påbörjas. Systemutveckling är en form av verksamhetsutveckling eftersom utveckling av informationssystem förbättrar verksamheten.</p><p>Detta arbete beskriver metoder för två områden, systemutveckling och verksamhetsutveckling. I min bakgrund definierar jag olika begrepp som jag anser vara centrala och viktiga för dessa områden. Jag gör sedan en beskrivning av tre metoder för systemutveckling, en metod för verksamhetsanalys och två metoder för verksamhetsutveckling med avseende på aspekter som beskrivs i verksamhetsanalysen.</p><p>I mitt arbete finns en huvudfrågeställning, Är det möjligt att använda systemutvecklingsmetoder och främst verksamhetsanalysen i andra avseenden än vid systemutveckling? och även ett antal övriga frågeställningar.</p><p>För att kunna besvara frågeställningarna har jag genomfört litteraturstudier. Intentionen var även att genomföra intervjuer, men p.g.a. att litteraturstudierna tog väldigt lång tid beslutade jag mig för att utesluta metoden.</p><p>För att besvara min huvudfrågeställning kommer jag att utifrån mitt ramverk, F3, göra en jämförelse av vilka aspekter som beskrivs av verksamheten i verksamhetsanalysen.</p>

<p>This final year project is dedicated to investigate the problem domain of system maintenance management. The purpose is to find problems in the system maintenance management of today. Whether there is any problem that can be elicitated in the requirements engineering’s phase that could help to obtain more maintenance management friendly systems and if it is not possible to obtain more maintenance management friendly, what else can be done?</p><p>It has been learned that there are many problems today in the problem domain and the most great ones are the system documentation, stress and a systemknowledge lack among developers, system managers and system users.</p><p>The requirements that have been found for this problem is good documentation, and use of simple solutions in the creating of the system.</p>

<p>etta examensarbete behandlar år 2000 problemet i Skaraborg. Rapportens inledning försöker sammanfatta vad år 2000 problemet är, vad man kan göra åt det och vilka effekter som kan uppkomma.</p><p>Examensarbetet försöker besvara fyra övergripande frågeställningar:</p><p>· Har Skaraborgs företag fått upp ögonen för år 2000 problemet?</p><p>· Är det ett problem ?</p><p>· Hur stora är företagens problem?</p><p>· Vad gör dessa företag åt problemen?</p><p>För att besvara dessa frågeställningar har en enkätundersökning utförts. Denna undersökning innefattade små, medelstora och stora företag samt offentlig sektor. Undersökningen visade att de flesta verksamheterna tagit problemet på allvar. År 2000 problemet visade sig också vara ett problem, hur stort var dock svårt att förutsäga. Varje företag hade en egen strategi för hur anpassningsarbetet skulle ske.</p>

<p>Den här rapporten handlar om upper-CASE samt dess effekter, möjligheter och de hinder som finns för dess införande. Fem personer i fem organisationer har frågats ut med enkät eller intervju om deras erfarenheter och synpunkter. I tre av organisationerna användes upper-CASE-verktyg i systemutvecklingen och i två användes det ej.</p><p>· De förra ansåg alla att underlättad dokumentation, förbättrad kommunikation mellan projektmedlemmar, förbättrad kvalitet hos det färdiga systemet samt en viss tidsvinst i systemutveckling var effekter som uppnåtts av användandet av upper-CASE. Det utvecklade systemet blir också lättare att förvalta ibland. Av negativa effekter tyckte man sig se ett visst beroende av CASE-leverantörens support. Det verkar också som att gränssnittet brister i vissa verktyg. Användandet av upper-CASE i en organisation kan påverka kunskaperna hos användarna. I en organisation yttrade sig detta på så vis att mängden människor med samma kompetens - skill set - växte. Detta underlättade matchning uppgift - kompetens i systemutveckling.</p><p>· Ett av de konsultföretag som ej använde upper-CASE arbetade oftast efter kundens metod. Eftersom upper-CASE-verktyg ofta har en metod inbakat blev det klumpigt att använda sådana. Ett tecken hittades på att faktorer som ekonomi och användbarhet gör att upper-CASE kanske bidrar dåligt i systemutveckling hos små organisationer, i jämförelse med lower-CASE.</p><p>· Underlättad dokumentation, förbättrad kommunikation, och ökad kvalitet var fördelar som sågs av samtliga organisationer i den här undersökningen.</p>

<p>"Kravhantering - Kvalitet vid kravspecifikation" är titeln på detta arbete som lägger tyngden på processen kravinsamling vid utveckling av informationssystem. Rapporten ger en slutsats av en undersökning som har genomförts med hjälp en av litteraturstudie och ett antal intervjuer. Rapporten är författad under perioden januari till juni år 1997 av Marie Ryberg och är baserad på författarens erfarenheter, litteraturstudie och intervjuer. Syftet med rapporten är att motivera behovet av kvalitet vid kravinsamling och att klargöra begrepp, problem och metoder inom kravinsamling. Denna rapport riktar sig till personer inom systemutvecklingsbranschen.</p><p>Rapporten ger ett inledande kapitel med historia och utveckling inom systemutveckling. Begrepp inom systemutveckling förklaras och min uppfattning av informationssystem utreds. Två betydande begrepp inom detta arbete är krav och kravspecifikation. En kravspecifikation är en samling krav och att dessa krav är korrekt dokumenterade lägger rapporten stor vikt vid. Kravinsamlingen sker inom kravhanteringen. Tre aspekter på kravhantering presenteras, av tre olika författare. Kravhanteringen syftar till att ge en god bild över hur man finner krav på informationssystem. Till slut ges en beskrivning av kvalitet vid kravhantering.</p><p>Efter insamlat material presenterar jag mina problemställningar. Här redovisas även problemavgränsning och förväntat resultat. Dessa problemställningar undersökas sedan med hjälp av en eller flera relevanta metoder. Utifrån ett antal möjliga metoder diskuteras metodvalet.</p><p>Genomförandet har utförts med hjälp av två metoder, litteraturstudier och ett antal intervjuer. Med hjälp av dessa metoder har jag kunnat samla in information för att få svar på mina problemställningar. Genomförandet analyseras sedan, med egna värderingar om det insamlade materialet.</p><p>Slutsatser utifrån analysen redovisas med koppling till problemställningarna. Därefter följer en diskussion om arbetsprocessen och förslag till fortsätta studier. Till slut redovisas erfarenheter och kritisk granskning av arbetet.</p>

<p>Konventionella databassystem är passiva. Detta innebär att databasen förändras genom explicita användarkommandon. Ett aktivt databassystem är ett databassystem som bevakar situationer (events) av intresse och, när de inträffar, utlöser ett lämpligt beteende (action) förutsatt att ett visst villkor (condition) är uppfyllt [Kim95]. De aktiva databassystemen sägs ha ett aktivt beteende. Detta beteende kan t ex specificeras i sk ECA-regler.</p><p>I de passiva databassystemen kan det aktiva beteendet efterliknas på två olika sätt. Bägge lösningarna medför dock problem. Den första lösningen innebär att applikationsprogrammen byggs ut med kod för villkor och handling samt med kod för att kunna kontrollera om händelsen har inträffat. En av nackdelarna med denna lösning är att samtliga relevanta applikationsprogram måste sökas upp och justeras då villkoret och/eller handlingen ska förändras.</p><p>I den andra lösningen ställer applikationsprogram frågor med jämna mellanrum till databasen (pollas) för att kontrollera om villkoret är uppfyllt. Det största problemet med att polla databasen är att fastställa den lämpligaste pollningsfrekvensen. Då pollningsfrekvensen är för hög överbelastas databasen och dess prestanda blir lidande. Om databasen däremot pollas för sällan uppstår en tidsfördröjning innan händelsen upptäcks. I vissa fall kanske inte händelsen upptäcks alls. Enligt [L&L95] blir problemet med pollning större desto fler applikationsprogram som pollar databasen.</p><p>Ett tänkbart användningsområde för aktiva databaser är computer-integrated manufacturing (CIM) [Gat95] m.fl. Enligt [Kus90] är CIM ett koncept antaget av företag för att förbli konkurrenskraftiga. CIM skulle även kunna sägas utgöra ett verktyg genom vilket företag försöker spara tid och pengar.</p><p>Pollningen antas inverka negativt på tillverkningen i CIM. Jag har försökt visa att antagandet är riktigt genom att i en experimentcell utforma tre olika situationer där pollningsfrekvensen är olika samt en situation där en aktiv databas används. I arbetet har följande problemställningar undersökts:</p><p>· Vilka blir effekterna på genomflödet och på kapacitetsutnyttjandet om databasen pollas med olika frekvenser och om en aktiv databas används i den specifika tillämpningen i cellen?</p><p>· Är det möjligt att göra några ekonomiska vinster, dvs att spara in tid och kapital eller att öka intäkterna, genom att slippa polla i det aktuella scenariot och istället använda en aktiv databas?</p><p>Resultaten av arbetet visar att pollningen inverkar negativt på såväl genomflödet som på kapacitetsutnyttjandet i scenariot samt att bägge faktorernas värden förbättrades då en aktiv databas användes. Med andra ord kan pollningen anses inverka negativt på tillverkningen. Det visade sig även vara möjligt att göra ekonomiska vinster i scenariot genom att ersätta den passiva databasen med en aktiv. Hur omfattande vinsterna blev berodde bl a på vilken pollningsfrekvens den passiva databasen pollades med innan den aktiva databasen infördes. Vilka resultaten blir i andra situationer är dock svårt att uttala sig om.</p>

<p>ag har studerat och undersökt de problem som uppkommer när företag ska minska sina lager. Jag har koncentrerat mig på företag som har tillverkning och inköp mot lager.</p><p>Jag har undersökt de i litteraturen beskrivna problemen och sedan jämfört några av dem mot en fallstudie på ett företag som motsvarar ovanstående beskrivning.</p><p>Det finns många olika sorters lager, vilket har lett till att denna rapports tyngdpunkt ligger på hur företagens färdigvarulager kan minimeras.</p><p>De första fem kapitlen är en inledning och beskrivning av lagerproblematiken och de ligger till grund för mina problemställningar i kapitel 6. Sedan följer en beskrivning av genomförandet av min fallstudie hos Fiskars Sverige AB.</p>

<p>Verksamheter är idag utsatta för olika hot och faror, i form av både yttre och inre angrepp. Ett angrepp orsakar ofta ett avbrott och det kan bli mycket kostsamt. Att ringa in de olika riskerna och planera för hur de ska hanteras, kan spara mycket pengar och är således viktigt för verksamheten.</p><p>De yttre angreppen kan främst förebyggas med olika tekniska lösningar, medan de inre angreppen har en annan form av lösning. Den hotbild som finns mot företag idag, är att mer än en tredjedel av de angrepp som sker är av typen inre angrepp, därför är det viktigt att hitta de säkerhetsåtgärder som på effektivaste sätt kan förebygga dessa.</p><p>Med detta arbete har jag försökt belysa vilka de viktigaste säkerhetsåtgärderna är för att förebygga de inre angreppen. I rapporten har jag beskrivit kortfattat vad det finns för olika hot och faror mot en verksamhet. Det finns även en översiktlig beskrivning varför en verksamhet bör skyddas och hur den kan skyddas.</p><p>Genom att främst studera litteratur, men också genom att göra ett antal intervjuer har jag försökt besvara problemeställningen "hur kan inre angrepp förebyggas?". Resultatet och vilka slutsatser som jag har dragit finns redovisat i denna rapport</p>

<p>Det här arbetet handlar om hur ett företag kan minska sina lager men fortfarande tillfredställa kunderna. Arbetet kommer även ta upp vilka olika typer av lager det finns och varför ett säkerhetslager är bra att ha.</p><p>Det finns tre mål som de flesta tillverkande företagen vill uppnå för att förbättra sin konkurrenssituation och generera hög lönsamhet:</p><p>1. Hög service nivå mot kunderna</p><p>2. Låg kapitalbindning i lager</p><p>3. Den mest kostnadseffektiva operationsföljden, med de kortaste ställtiderna</p><p>Problemet med de tre ovanstående punkterna är att de motarbetar varandra. Hög kundservice kräver ofta stora lager för att man alltid ska kunna leverera i tid och att produktionen är flexibel för att kunna följa kundens varierande behov. Det här strider mot punkt två och tre där man vill ha små lager och så få förändringar i produktionen som möjligt.</p><p>Den här problematiken visar på hur mycket det finns att tänka på innan ett lager kan optimeras och hur svårt det kan vara att komma fram till vilken lagerstorlek som är lämplig. De flesta företag har ej heller råd med att bara uppfylla ett eller två av ovanstående mål. Uppfylls inte alla tre kan det bli väldigt kostsamt.</p>