I huvudet på en utvecklare Utvecklarperspektivet Konflikter! Har vi egentligen konflikter mellan beställare och utvecklare? Nej, men " olika faktorer styr när man blir nöjd " det är svårt att skilja systemutveckling från verksamhetsutveckling (= turbulens) " svag förståelse: mycket en språk- och intressebarriär, ej nödvändigtvis en intressekonflikt " ej medverkan i de andras aktivititeter leder ofelbart till osämja Verkliga problem! Låg produktivitet " Avtar med antalet personer. Kompensera med gruppuppdelning; ger ännu fler parter att hantera " Att öka takten är snudd på omöjligt " Människor är inte plug&play-kompatibla! Projektmedlemmar " Vi är olika; bra och dåliga! Dåliga odds från första början pga upphandlingen " Fast pris + låsta krav = betong Offertvarianter Risk Löpande räkning Blandformer Fast pris med böter Fast pris Chans att få kontrakt Låtsasvärld Upphandling! Beställaren låtsas veta alla framtida krav! Leverantören låtsas tro på det, och låtsas vidare att det går räkna ut fix kostnad för att konstruera systemet! Utvecklarna låtsas att utveckling är statiskt och använder metoder som tar fyrkanter som indata och som producerar nya fyrkanter! Alla blir förvånade/upprörda när kraven inte håller KUNDEN Analys: behov LEVERANTÖREN Krav Analys: tid & pengar Offert
Förändringar! Mjukvara är just mjuk; ska gå att förändra! Lösningen är inte att låsa krav! Vad det kostar beror enbart på krav (som vi ju inte vet i förväg) Utvecklarens syn! Design för användbarhet " Inget som skiljer sig (i sak) från andra krav " Dock, det finns inga eller få konkreta användbarhetsmål om man frågar kravställare/användare/experter! " Alltså ligger svaret i hur man utvecklar, inte vad (hur är ej samma sak som val av utvecklingsmetod!) Användbarhetsprocess!! Lösningen? " Ej i krav " Ej heller i prototypen (i sig) " Alla sätt att överlämna designrepresentationer misslyckas (troligen) " Svaret ligger i metoden!! Så, om utvecklarna varit med i framtagandet av krav och prototyp så ökar chanserna Svaghet! Stor del ligger i my baby -syndromet; att man aldrig vill ändra på en egen (=vacker) lösning " Leder till ett enda utvecklingsspår mot målet; kan ej vara tillräckligt " Denna naturlag fungerar åt båda håll, men oftast är det utvecklarna som får skäll! Finns en mängd olika strategier för att undvika just den fällan! Här är 7 stycken: 1. Perfektionism! Hela tiden leta efter den ultimata lösningen; nuvarande lösning endast temporär! Bygger på att det existerar en killer app som löser alla våra problem " Inte riktigt sant " Eller Verkligheten! Worse is Better gäller tyvärr " Richard P. Gabriel vs. Nickieben Bourbaki # Good News, Bad News, How to Win Big # http://www.dreamsongs.com/worseisbetter.html " I korthet: # Enkelhet i kod > enkelhet i design # Enkel > korrekt # Enkel att bygga > enkel att använda
2. Projektledning! Arbetssätt är en fråga om inställning " Jämför hur coachning sker av målvakter i hockey och handboll! Kompetens och självförtroende " Duktiga utvecklargrupper tvekar inte att slänga bort saker som inte passar eller är bra nog. Det gäller nå denna nivå/attityd! # Coachning, team building # Ledargestalt # Utbildning, anställa den bästa i världen # Prestigelös miljö 3. Metodik! Arbeta på ett sätt som omöjliggör revirbevakande och rigida strukturer! Prototypdriven verksamhet är sådan, med stora vinster: " I en datorvärld kommer prototyper sanningen mycket nära " Prototyper kan dock bara ge svar på frågor; ingen generell räddningsplanka Metodik, hur bäst förstöra! Skapa moment som går emot allt mänskligt " Förutsätt konsekvent beteende av de som ska använda metoden # Om vi bara folk kunde vara konsekventa (och vara snälla, motionera mera, röka mindre ) så skulle det inte vara ett problem " Förutsätt att folk ska ändra beteende ifall någon vill det # Ingen byter personlighet pga metod! Metoder passar sällan i komplexa situationer 4. Verktyg! Genom att noggrant välja verktyg kan man uppnå många positiva effekter " Inga låsningar " Visionära! Nästan samma vinst som via prototyper! Papperslappar, skisser, Verktyg, hur bäst förstöra! Verktyg för kommunikation " Börja med 2 personer vid svarta tavlan " Ta bort närhet mellan personer (video) " Ta bort alla förklarande gester (telefon) " Se till att intonation inte kan användas till att förmedla vad som är viktigt (epost) " Se till att man inte kan ställa frågor (dokument)! Detta är vad de flesta metoder rekommenderar Verktyg, välj rätt Kommunikation Svarta tavlan Telefon Epost Formell notation Dokument Strukturerat dokument Verktyg
Verktyg, välj rätt byggnad! "Make sure there are whiteboards and coffee corners all over the building. (IBM) 5 vanligaste verktygen! För hand (ovanligt)! Färdigt bibliotek (toolkit)! Färdigt gränssnittsverktyg (builder)! Färdig applikationsverktyg (User Interface Management System)! Modell-baserade gränssnitt (kommer starkt) Handgjort! Ligger direkt ovanpå hårdvara! Bra kontroll! Höga prestanda! Svår utveckling, oflexibelt, hög tröskel! Ger ofta låg kvalité " Tänk videobandspelare Bibliotek! Hög tröskel; måste kunna alla delar i biblioteket! Kräver mycket kod/arbete! Utmärkta prestanda! Bra kontroll Hello, exempel i Java Bibliotek, byggklossar import javax.swing.*; class HelloWorldSwing { public static void main(string args[]) { JFrame mainwin = new JFrame("MainWindow"); JButton button = new JButton("Hello World"); mainwin.getcontentpane().add(button); mainwin.pack(); mainwin.show(); } }
Builder/RAD! Vanligaste lösningen idag " Visual Basic, Visual C++, Forte, etc! Kräver fortfarande att man kan hela biblioteket! Flexibel utveckling, stor frihet! Billigt! Ger initialt en snabb utveckling (falsk känsla dock) Builder/RAD funkar ej!! WYSIWYG saknar uttryckskraft " All förändring av utseende kräver en manuell förändring/operation # Jrf. kommandon i operativsystem: # Rename.htm.html abc/* # Byter filändelse på alla filer i mappen abc från.htm till.html http://www.javaworld.com/java world/jw-07-1999/jw-07- toolbox-p5.html! To paraphrase Fred Brook's wonderful essay "No Silver Bullet," well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think. UIMS! Större, tyngre, dyrare verktyg hjälper till med mer saker: hjälpsystem, underhåll, distribution, felhantering,! Endast för seriösa utvecklare! Tunga system Modellbaserat gränssnitt rubrik: textfält(ej inmatning), bakgrund=vit. varningsrubrik: rubrik, bakgrund=röd. 5. Designkriteria! Jobba mot förbestämda mål " Överenskomna " Gemensamma " Styrande! Målen riskerar bli förtäckta krav
6. Rationale! Att arbeta enligt Design Rationale kan hjälpa utvecklingsgruppen att ompröva alla lösningar! Motiverar lösningar även för andra, externa personer! Ger bättre kvalité på varje dellösning, men hjälper det egentligen? 7. extreme Programming (XP)! Förändringarna har förändrats " Verksamhet förändras hela tiden, alltså bör även systemen göra det! Ett nytt sätt att utveckla system " Kontinuerliga förändringar! " Testdriven process " 2 x personer = 1 dator " Inga dokument sparas " Gemensamma ståmöten " Långsiktig planering är osäker, alltså låter man bli sånt XP, del 2! Gör upp med gamla sanningar " Att tänka efter ger bättre kvalité än att göra nu # Fel: kvalité har med riktig användning att göra, inte planerad användning. T.ex. snabbast ta första tunnelbaneuppgången än den rätta " Att göra rätt sak från början är billigare än att rätta i efterhand # Fel: troligtvis behövs saken inte alls, om den sedan behövs gör man det då. " Dokumentation är viktig att spara # Fel: den är så dålig att den inte är värd något XP, del 3 " Planera noga för viktiga saker # Fel: om framtiden är oklar, och du kan fixa saker i efterhand, varför införa något som man misstänker kan vara bra? " Välj bästa lösningen # Fel: välj enklaste lösningen, för den är ändå bra nog (och enklare att ändra) " Se framåt # Fel: endast Saida kan det; gör endast vad du vet, inget mer XP, del 4 " Koda, testa sedan att det blev rätt # Fel: gör test först, koda sedan " Många rader kod/dag, och många funna fel i ett test är bra # Fel: få rader går snabbare att skriva, noll antal fel vore bättre Exempel
Telemedicin! Vag term, inte så populär längre. " Svårt hitta något som inte är tele numera. " Historisk benämning, medicin var ju ytterst lokal i början.! Termen innebär någon form av medicinsk utövning (råd, diagnos, hjälp, övervakning etc.) på distans. Historia, del 1! Wilhelm Einthoven (EKG) gjorde 1906 försök till konsultationer via telefon.! 1920 fanns verksamhet för sjöfart; brukar kallas starten för telemedicin. " Sahlgrenska + Göteborgs radio gav akutsjukvård för folk till sjöss.! Röntgen via telefon och satellit under 50-talet i USA. Historia, del 2! NASA " I rymden hör inte läkaren dig! Krig " Skadade befinner sig ofta i svåråtkomlig miljö! U-länder, rörlig befolkning, geografi (ex. Norge, Canada, Indianreservat)! Kompetenscentra (viktig del av modern medicin) Historia, Sverige! Sjöfart.! 1976; under pågående operation skicka vävnadsprov mellan Lund och Malmö.! 1980; skicka röntgen via teleledningar (långsamt och rätt dålig kvalité).! Nu; finns överallt men är ändå bristvara. Problem! Teknik ej utvecklat nog (då, inte nu?).! Indata är analog; analog överföring har alltid låg potential.! Bandbredd (fortfarande problem, realtid). " 256 x 256 x 12 (CT). " 2048 x 2048 x 12 (Lungröntgen).! Digitala format svåra (stora, dyra).! Säkerhet (kryptering, accesskontroll, brandväggar). Förhoppningar! Ekonomi. " Ökad effektivitet, samt färre transporter.! Kvalité. " Tillgänglighet. " Nära patient, hemsjukvård, tillgång till expertis, snabb behandling, second opinion.! Miljö. " En digital domän är ren.! Möjliggör ny metodik och verksamhet.! Vidareutbildning är extremt viktig!
En enkel form av telemedicin! Telefon! Telefon + TV (videokonferens) " Utbildningssyfte " Katastrofmedicin, sänder från trauma direkt " Konsultation med patient närvarande, en slags interaktivt beslutsstöd Kodning av information! Största problemet är utbyte av information: " Patientjournal finns ej då läkaren behöver den # Finns i källaren på Akademiska # Finns i Sverige, när benbrottet skedde på Mallorca # Finns hos husläkaren, men inte på akuten " Information finns, men kan ej läsas # Fel format # Okänt format Standarder kan hjälpa! Välj en standard " ACR/NEMA " Interfile (speciellt bildformat inom nuklearmedicin) " De facto (Philips, Siemens, GE, ) " Eget format " DICOM! http://www.dclunie.com/medicalimage-faq/html/ Ordkunskap # PACS Picture Archiving and Comm System. # CT Computer Tomography. # MR Magnetic Resonance. # XA Angiography. # US Ultra Sound. # Invasiv Intrång i kroppen. # In vivo/vitro Levande/provrör (glas). # Serie, studie Hierarki. # Modalitet indata-enhet (kamera). Teleradiologi! Förmedla bilder mellan radiologer.! Röntgendiagnostik.! Idé: " konsultation av extern expert (experter finns bara ett fåtal av). " Viss diagnostik måste ske snabbt, annars meningslöst sätta in åtgärder. Teleradiologi, del 2! Missbruk : systemen används inte för ursprunglig idé: " Undervisning " Ersätter film helt " Skickar bilder i förväg " Jourverksamhet (bakjour, i hemmet) " Kompetenscentra
Telepatologi! Undersöker vävnader.! Vävnader fryses och är allmänt ömtåliga (svåra och dyra att transportera).! Extrem bildkvalité krävs (mikroskop!).! Kräver extern kontroll av mikroskopet (ljus, position etc.). Exempel: Medicus Medicus Tidiga krav! Deutsche Telekom beställare.! Ville skapa produkter som använder ISDN, för att kunna sälja som mervärden till den tjänsten.! Specifikation: " Telekonferens. " Utbyte av bilder.! Beställaren om systemet: " Ska nyttja ISDN " Konferens " Säljande! Medicinsk personal: " Vara som förr, fast bättre " Katastofhjälp " Se motpart # Bild + ljud " Dela pekare Medicus, design Medicus, look&feel Bag Panel Folder Panel Session Panel Task Panel Status Panel Quit Panel Work Area
Senare krav! Jättestor bild! Stor bild! Funktionalitet! Användbar! Prisvärd Sittrond Krankenhaus Salem Onkologische Diagnostik Deutsches Krebsforschungszentrum CHILI, start av applikation CHILI, konferenslängd 120 100 250 80 200 60 150 40 100 20 50 0 01:00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 0 < 1min 1-2 min 2-3 mins 3-4 min 4-5 min 5-10 10-15 15-20 20-25 > 25 min min min min min
CHILI, konferenstidpunkt 1,000 900 800 700 600 500 400 300 200 100 0 1:00 4:00 7:0010:0013:0016:0019:0022:00 CHILI, NG! Bärbar variant (PDA)! UMTS, 3G! Scenarier " Bakjour " Personsökare med bildvisning " Bedside, under ronden " Övervakning av patient under kameran (undvika irradiation) CHILI wireless CHILI PDA, v.1 CHILI PDA, senaste Web-based Artificial Intelligence for Diagnostic Use (WeAidU)
Bakgrund! I västvärlden är hjärtsjukdomar kärlkramp, hjärtinfarkt mycket vanlig (och växande)! Sjukdomen är behandlingsbar (via medicinering, operation) och därför behöver vi ställa diagnoser snabbt och korrekt! Det svårt att ställa diagnos " http://www.montana.edu/wwwai/imsd/diabet es/myocard.htm Ord! Atherosclerosis " hardening of the arteries due to plaque build up and to excess glucose sugar levels in the blood! Cardiac catheterization " A small plastic tube travels through a blood vessel to the heart. Blood pressure and cardiac actions can then be measured! Coronary angioplasty " Angio is defined as vessel, and plasty is defined as repair. (ballong) Underlag för diagnos! Elektrokardiografi, EKG (lättanvänd metod, men diagnostiskt utbyte ej optimalt)! Sjukdomshistoria! Tidigare undersökningar! Hjärtbilder (finns dock få experter på tolkning) Bakgrund 1895 - Wilhelm Conrad Röntgen upptäcker att bremsstrahlung färgar fotografisk plåt 1896 - Henri Becquerel upptäcker radioaktivitet 1900 - Villard upptäcker gammastrålning 1938 - isotopen Technetium-99m 1946 - radioaktiv substans används på sjukhus för första gången 1958 - Hal Anger tillverkar första gammakameran Myokardscintigrafi! Ord " myos; cardia; scintillation; grafein " muskel; hjärta; ljusblixt; rita! Radioaktiv substans (Technetium-99m; gammastrålning med 140 kev; halvering 6h), sprutas in i blodet! Arbetande celler tar upp mest substans! Normala partier i hjärtat tar upp mer än partier med nedsatt genomblödning! Bild tas med strålningskänslig kamera Resultat! Bild rekonstrueras av olika bildplan! En bild tagen under stress, en vid vila
Problemställning! Inte alla läkare får tillräcklig träning! Erfarenhet tar lång att bygga upp! Det finns inte experter på alla kliniker! Hjälp inte alltid tillgängligt när det behövs! Sjukvården har svårt att investera i IT! Datorstöd är ofta besvärliga att använda Förslag till lösning! Automatisera tolkning av bilder! Gör enkla och användarvänliga program! Använd befintliga datorer! Tillverka program som uppdaterar sig själva till senaste versionen! Programmen bör vara gratis Tolka bilder! Artificiella neuronnätverk (ANN) Exempel på sjuka och friska Godtyckligt exempel Träna! ANN Testa!
Bra exempel