ProPlanner. Uppdragsgivare: Torbjörn Jönsson, AstraZeneca. Ett projekt för kursen Programutvecklingsprojekt 2D1954

Transkript

1 ProPlanner Projekt medlemmar: Björn Sundman, Projektledare Pierre Evans, Webbansvarig Christer Wanngård, sekreterare Tymon Pigon, Juridikansvarig Alireza Golestanizadeh Bernt Nylin Uppdragsgivare: Torbjörn Jönsson, AstraZeneca Ett projekt för kursen Programutvecklingsprojekt 2D1954

2 Innehållsförteckning 1. Problemstruktur Bakgrund Syfte Problembeskrivning Krav och avgränsningar Funktioner Datormiljö Hårdvara Mjukvara Användare Förslag till lösning Systemskiss Moduler Algoritmer Definitioner Indata Beräkningar Utdata Användargränssnittet Genomförande Systematiska metoder Hjälpmedel Ansvarsfördelning i gruppen Tidsplanering av aktiviteter Administration Implementation Arbete med dokumentation Projektbeskrivning Användarhandledning Systembeskrivning Riskanalys...10

3 1. Problemstruktur 1.1. Bakgrund Tillverkning av aktiv läkemedelssubstans karakteriseras idag av högt ställda krav på produktkvalitet och leveransförmåga. Utvecklingen av datortekniska hjälpmedel för att modellera och simulera kemiska och fysikaliska processförlopp har under senare år varit stark. För AstraZeneca är det viktigt att relevanta datortekniska verktyg utnyttjas som hjälpmedel för att effektivisera arbetet med att säkerställa processtabilitet, produktkvalitet och leveransförmåga. Därför görs nu en satsning inom området. Ett led i detta arbete är att öka samarbetet med högskola/universitet, t ex i form av exjobb och projektarbeten. För produktionsplanering (logistikhantering och kapacitetssimuleringar) saknas dock idag lättanvända verktyg speciellt anpassade för AstraZenecas processer och behov Syfte Syftet med detta projekt är att ta fram mjukvara i form av makron skrivna i Visual Basic och makrona skall köras i Microsoft Project. Makrona skall underlätta produktionsingenjörernas arbete med att schemalägga läkemedelsproduktionen på AstraZeneca. I dagsläget finns inget allmänt vedertaget system för schemaläggningen, eller med andra ord alla arbetar enligt egen metodik. Projektet kommer att leverera en enhetlig metodik för schemaläggning och planering av produktion Problembeskrivning Tillverkningen sker batchvis och kan delas upp i processteg som tar olika lång tid och som tar olika resurser i anspråk (tankar, reaktorer, centrifuger etc.). Den totala ledtiden för en batch kan uppgå till flera dygn och bestå av ett flertal processteg. Normalt tillverkas flera batcher efter varandra (kampanjvis). Det möjliggör att tillverkningen kan saxas, vilket gör att den sammanlagda ledtiden blir kortare än summan av de enskilda batchernas ledtid var för sig. Flera produkter kan vanligen köras i en processanläggning. Utrustningen saneras vid byte till ny produkt. Normalt sker ingen tillverkning under helg. Enbart vissa intermediat (mellan produkter) i en process är stabila för lagring, vilket är viktigt att ta hänsyn till vid planeringen av produktionen. Planerar man illa kan man till exempel vara tvungen att bryta produktionen redan på onsdag eftermiddag, för att man inte hinner tillverka nästa stabila intermediat före helgen. Detta innebär att dyr processutrustning blir stillastående.

4 1.4. Krav och avgränsningar Programmet skall klara schemaläggning av en eller flera batcher av samma produkt. Flera olika produkter kommer alltså inte kunna schemaläggas parallellt. Det kommer att finnas stöd för tre olika typer av arbetsskift: 3-skift, 4-skift och 5-skift. Programmet ställer vissa krav på indata: Användaren kan receptet. Det står angivet vilken resurs som ska användas. Tidsåtgången för varje delsteg. Vilka processer som är beroende av varandra Funktioner Den primära funktionen kommer att vara att optimera brytpunkternas längd i en given sekvens av olika steg och moment. Optimeringen kommer att minimera tidsåtgången för att köra dessa steg i den ordningen som är angiven av produktionsingenjörerna på AstraZeneca. För att programmet ska vara så flexibelt som möjligt så anropas alla beräkningar manuellt, på så vis undviker man störande och oönskade automatiserade moment. I samma anda är alla funktioner uppdelade i atomära delar så att användaren får full kontroll. Den funktionalitet som erbjuds är huvudsakligen: Brytpunktsoptimering med anpassning för lediga dagar. Detta innebär att programmet försöker ändra brytpunkternas längd, inom dom givna intervallen, så att den kortaste totala tillverkningstiden kan uppnås, processerna förskjuts även så att ingen tillverkning är schemalagd på en ledig dag (röda dagar). Men även Överbokning av resurser. Programmet kan kontrollera så att inga processer körs samtidigt på samma maskin. Notera att alla funktioner är av rådgivande karaktär. Det går t ex fortfarande att dubbelboka en resurs. Observera även att programmet inte på något sätt beräknar vilken ordning som delstegen ska köras i. Detta är en möjlig uppgift för programmet men som valdes bort pga. problemets komplicerade natur. Se Bilaga 1 NP-reduktion för mer detaljer Datormiljö Nedan följer en beskrivning utav den datormiljö som finns tillgänglig för processingenjörerna på AstraZeneca.

5 Hårdvara Makrona skall kunna köras på den hårdvara som finns tillgänglig på AstraZeneca. I princip räcker det med en dator som klarar ett Microsoft operativsystem samt att datorn kan köra programmet Microsoft Project Mjukvara Programmet kommer att vara ett antal makron i Microsoft Project. Programmet ska fungera på Microsoft Project 2000, som används på AstraZeneca. Makrona är skrivna i Visual Basic Användare Programmet kommer att användas av produktionsingenjörer på AstraZeneca som redan har kunskap i Microsoft Project samt är väl insatta i problematiken. En betaversions demonstration för de presumtiva användarna kommer att hållas någon gång i mitten av projektet. 2. Förslag till lösning 2.1. Systemskiss Se Bilaga 3 - Systembeskrivning Moduler Vi har en huvudmodul vid namn fitalgorithm som utför själva arbetet av att anpassa arbetsmomenten till arbetstiderna. Dessutom kan man modifiera kalendern för olika skift och införa ledigheter under arbetsdagar. En debug-ruta finns tillgänglig som visar meddelanden under körning. Det går även att få upp en ruta där man kan se och redigera beroenden mellan olika delsteg av schemaläggningen. Man kan också be programmet hitta resurskrockar i schemaläggningen som tydligt kommer att markeras. Modulerna är helt fristående från varandra och det enda som är av intresse är deras algoritmiska aspekter. Dessa diskuteras närmare i nästföljande kapitel Algoritmer Nedan följer en beskrivning av hur vårat program beter sig, vad för slags indata den nyttjar och vilken sorts utdata den returnerar.

6 Definitioner Tillverkningen sker på maskiner av olika slag som vi har valt att kalla resurser. Minsta möjliga tidsenhet kallas för ett moment. Ett moment har en specificerad tidsåtgång och tar en eller flera resurser i anspråk. Varje resurs kan bara köra ett moment i taget. Tillverkningen sker i delsteg som består av ett eller flera moment. När produktionen av ett delsteg har påbörjats kan den bara pausas på speciellt angivna platser, så kallade brytpunkter. Brytpunkterna kan ha olika tillåten längd. Under det att produktionen av ett delsteg befinner sig i en brytpunkt så är den respektive resursen upptagen. När delstegen är färdiga är de antingen färdiga för leverans eller så er de sig i en så kallad vilotid, som liksom brytpunkten har en given tidsram men som inte tar några resurser i anspråk Indata Programmet använder sig av MSProjects kalender funktion. Där ska anges vilka dagar och tider som man arbetar. Programmet läser från ett MSProject ark där varje delsteg deklareras som en task och arbetsmomenten deklareras som subtasks. I arket måste också alla beroenden finnas angivna samt använda resurser och tidsåtgång för varje moment. Brytpunkterna ska deklareras som milestones. Brytpunkter deklareras alltid med namnet brytpunkt och dessutom kan man ange minlängd och maxlängd. Detta görs genom att lägga till en anteckning i MSProject. Anger man ingen maxlängd så används ett fastställt standardvärde. Vilotider deklareras som milestones som beror av sina respektive delsteg. Vilotider deklareras på samma sätt som brytpunkter. En viss restriktion på indata är att det inte får existera några cykliska beroenden mellan följder av steg Beräkningar Våra moduler finns förklarade i våran systembeskrivning. Se Bilaga 3 - Systembeskrivning Utdata Utdata presenteras på samma form som indata. Visualisering av resultatet sker på konventionellt sett i MSProject. Förhoppningen är att visualiseringsfunktionaliteten i MSProject är tillräcklig för användarens behov.

7 2.2. Användargränssnittet Vi kommer att skapa en toolbar med ikoner för våra makron, ett fönster där man kan se de olika beroendena som man har angivit och ett kalenderfönster där man kan välja olika skiftformer. Dessa kommer att finnas tillgängliga i vår Microsoft Project mall. Toolbar: Lista beroenden: Välj kalender:

8 3. Genomförande 3.1. Systematiska metoder Vi kommer att använda Praktisk Projekt Styrning (PPS) som projektstyrningsmetod och Extreme Programming som produktionsmetod Hjälpmedel Gruppen använder sig av flera tekniska hjälpmedel för att samordna arbetet och kommunikationen bland medlemmarna. En webbplats för projektet etablerades tidigt. Där kan medlemmarna hitta och lägga upp användbara länkar samt lägga upp arbetet i en lätt tillgänglig form. Adressen till webbsidan är: CVS - Concurrent Versions System används för att samordna redigeringen av filer och kod. CVS håller koll på olika versioner och sammanfogar dokument som är redigerade av olika användare. Vi använder oss även flitigt av e-post kommunikation för att samordna arbetet så väl som möjligt Ansvarsfördelning i gruppen Vi har fördelat ansvaret i gruppen på följande sätt: Björn Sundman, projektledare och samordnare Pierre Evans, webbansvarig. Ansvarar för att information finns tillgängligt i lämpliga format på projekthemsidan. Christer Wanngård, sekreterare. För protokoll vid möten. Tymon Pigon, juridikansvarig. Arbetet har delats upp inom gruppen, i 3 subgrupper, på följande sätt: Björn Sundman och Christer Wanngård ansvarar för den matematiska modellen och algoritmkonstruktionen. Bernt Nylin och Pierre Evans står för GUI/Interface Tymon Pigon och Alireza Golestanizadeh ansvarar för input och output formatering i MSProject och Visual Basic.

9 3.3. Tidsplanering av aktiviteter Vecka Händelse 6 Möte med uppdragsgivare. Projektstart 7 Möte där riskanalys färdigställs. Fördelning av arbetsuppgifter. Algoritmanalys. Preliminär specifikation ska vara klar senast fredag. 8 Programutvecklingen påbörjas. Algoritmer ska vara fastställda Deadline för inlämning av preliminär specifikation Preliminär demonstration av betaversion för användare fredagen den 28/3. 14 Bokning av förhandsvisning 15 Återbesök på Astra för demonstration av Demo 16 Ytterligare finesser och uppdatering läggs till 17 Ytterligare finesser och uppdatering läggs till 18 Dokumentation färdigskrivs Slutgiltig presentation 21 Utvärdering 3.4. Administration Tabell över möten: Datum Beskrivning Fredagen den 31/1 Initialt möte. Diskussion kring mål och val av projektroller. Torsdagen den 6/2 Möte med uppdragsgivare Måndagen den 10/2 Riskanalys och fördelning av arbetsuppgifter. Fredagen 14/2 Möte på AstraZeneca med Torbjörn Jönsson och Espen Eiesland 3.5. Implementation Funktionen fitalgorithm implementeras först av två gruppmedlemmar för att känna lite på VB och få en känsla för de problem som finns. Denna implementation påbörjades i vecka 9. Övriga funktioner kommer att implementeras senare och kommer då att involvera fler gruppmedlemmar Arbete med dokumentation Projektbeskrivning Projektet är hela examinationen på kursen Programutvecklingsprojekt 2D1954 och går ut på att vi skall känna på och prova hur det är att arbeta i form av projekt.

10 Användarhandledning Se Bilaga 2 - Användarhandledning Systembeskrivning 4. Riskanalys. Se Bilaga 3 - Systembeskrivning. Under projektets början gjordes en riskanalys av projektmedlemmarna och följande risker identifierades: 1. Vi projektmedlemmar saknar kunskap och erfarenhet av MSProject och Visual Basic. 2. Versionskompatibilitet mellan olika versioner av MSProject. 3. Konflikter inom gruppen. 4. Sjuka medlemmat/barn. 5. Brist på engagemang hos oss gruppmedlemmar eller hos Torbjörn Jönsson. 6. Dålig kontakt/kommunikation med Torbjörn. 7. Dålig kontakt med presumtiva användare. 8. Ofullständig och dålig planering. 9. Problemet är inte lösligt under rimlig tid (datalogiskt: problemet ligger i NP) Efterföljande diskussion angående händelsernas sannolikhet att inträffa samt hur stor inverkan respektive händelse har på projektet resulterade i följande riskmatris: Sannolikhet att händelse inträffar Hur stor inverkan en händelsen har på projektet hög medel låg Hög 2 medel 9 4 låg 5,6,7,8 1 3