Please enable JavaScript.

Coggle requires JavaScript to display documents.

Projekt (Projekt hantering (Projektlednings aktiviteter, hanterings…

- - - - Företagets storlek, SW kund, SW storlek, SW typ, Organisations kulturen, SW utvecklings processen,
  - - - Projekt ledare är ansvarig för planeringen. Bedöma och schemalägga projekt utvecklingen och tilldela uppgifter.
    - - Projekt ledare uppskattar riskerna som kan påverka projektet, kontrollerar risker och tar handling mot problem som framhävs
    - - Välja människor för laget och etablera ett arbetssätt som leder till effektiv lag prestation
    - - Projektledare är ansvarig för att rapportera utvecklingen till kunderna och andra ledare av företaget i sig själv
    - - Första steget i ett system projekt involverar att skriva ett förslag för att vinna ett kontrakt. beskriver objekten i ett projekt och hur de ska utföras.
    - - Uppskatta riskerna och identifiera dem. skriva upp dem som en plan för att minimera dess effekt på projektet.
      - Viktigt för att osäkerheter finns bland odefinierade krav, krav ändringar, svårigheten att bestämma tid och resurser som krävs för SW utvecklingen och skillnader i individuell kunskaper
      - Måste förvänta risker, förstå effekten av de på projektet, produkten och affären.
      - Risk klassifikation
        
        Två dimensioner
        
        Typen av risk, teknisk eller organisatorisk?
        
        Vad påverkas av risken?
        
        Projekt risk, påverkar schemat och resurser
        
        Såsom, erfarna medarbetare lämnar projektet, ändringar i organisationell hantering med andra prioritering, ingen tillgång till hårdvara då de kan vara försenade.
        
        Produkt risk, påverkar kvaliten och prestationen av SW som utvecklas
        
        Ändring i kraven, specifikationen är försenade, storleken av systemet var underskattat. misslyckande av COTS fungerar inte som förväntat
        
        Affärs risker påverkar organisationen som utvecklar eller köper mjukvaran
        
        Teknologisk förändring, underläggande teknologi är gammal. Produkt konkurrens, konkurrenter har redan börjat marknadsföra sin, först på marknaden.
      - Risk hanterings processen
        
        Risk indentifikation
        
        Identifiera projekt, produkt och affärs risker
        
        Teknologisk risk
        
        Människo risk
        
        Organisatorisk risk
        
        verktygs risk (SW tools, support SW)
        
        Krav risk, förändringar av krav
        
        bedömnings risk, resurser för utvecklingen
        
        Risk analys
        
        hur stor chans de sker och konsekvenserna av riskerna. stora, medel, hög, katastrofala konsekvenser osv. hur stor chans? och vad vore effekten.
        
        Risk planering
        
        Skriva planer (strategi) om hur man undviker och minierar effekten av riskerna. Avoid, minimization, hanterings strategier.
        
        Risk kontrollering
        
        Kontrollera riskerna under hela projektet.
        
        Olika sätt att hantera risker se PP.s 23
        
        bedöm varje identifierad risk kontinuerligt för att se om de är mer eller mindre sannolik. effekten större eller mindre? varje nyckel risk skall diskuteras vid hanterings mötet.
        
        Risk indikationer se PP. 26
        
        What if frågor?
      - Risk mitigation (lindring)
        
        Vid problem som kan stoppa utvecklingen, måste man lindra risken för att inte stoppas
        
        Med detta skall man planera om projektet. Kan innebära att omförhandling med kunden med nytt schema.
    - - Viktigaste, uppgift för en ledare är peronsnal orienterade. måste förstå personalen. Dåligt personal hantering är misslyckad projekt
      - Viktiga faktorer:
        
        Respekt för deras olika kunskaper.
        
        Inkludera alla, deras åsikter skall inkluderas och tas till hänsyn
        
        Konsistens, behandlas på samma sätt utan favoriter
        
        Ärlighet om vad som sker och vad som går dåligt
      - Motivera personalen
        
        Menas att organisera arbetet och miljön så att de uppmuntrar till att jobba effektivt. annars är de inte motiverade till att jobba, arbetar långsamt och i princip inte bra för projektet.
        
        Olika motivationer
        
        Basic behov, mat sova osv
        
        Personal needs, respekt och självkänsla
        
        sociala behov, accepterad i en grupp
        
        Viktiga nöjdhets behov
        
        Sociala, fritids faciliteter, informella kommunikation som sociala nätverk
        
        Uppskattning, uppskattas för deras framgång och ev belöning
        
        självförverkligande, träning och ansvar
      - Olika personlighets typer
        
        Uppgift orienterade personer, motiverade av jobbet.
        
        Interaktions orienterade, motiverad av människor runt omrking
        
        Själv orienterad människa, motiveras av egen framgång och erkännande
  - - - högre grupp kvalite, man lär från varandra, kunskap är delad, refactoring och kontinuerligt förbättring är uppmuntrat. man jobbar kollektivt mot hög resultat, fixar problem.
    - - En mix av människor med olika aktiviteter
      - gruppen skall vara organiserat så att ala individer kan bidra med egna kunskaper
      - teknisk och hanterings kommunikation, viktigt med bra kommunkation
    - - file:///C:/Users/Gaming/Downloads/Project%20Management&Planning_vt17.pdf s 44
        file:///C:/Users/Gaming/Downloads/Sommerville%20-%20Software%20Engineering%209ed.pdf s. 616
- - - - Projekt planeringen är iterativ
        
        Förändringar är oundvikliga, kontinuerlig oversikt av krav, schema och risk ändringar. Ändringar i affärmål kan leda till förändringar i planen. återplanering
      - En plan inkluderar resurser tillgängliga i ett projekt, arbets nedbrytning, och schema för arbetets gång. Och identifiera risker och inställning mot riskerna.
        
        de olika delar i en plan
        
        Övriga: konfigurations hanterings plan, utplacerings plan, underhållnings plan, kvalite plan, valideringsplan.
        
        Introduktion
        
        Övarvakning och raport mekanismer
        
        Projekt organisation
        
        Projekt schema
        
        Risk analys
        
        Arbets nedbrytning
        
        HW och SW resurs krav
      - Fördel och nackdel
        
        Mot: många tidiga beslut måste omvärderas eftersom det kan ske förändringar i miljön.
        
        För: man planerar tidigt för allt tillåter organisationella problem, som personal. och de potentiella problem och beroendeskaperna är upptäckta innan projekt start, istället för innan projektets gång
      - Ledare använder planen för att hjälpa projekt beslut och ett sätt att mäta progression
      - En plan uppsatt gällande vad som ska göras, vem ska göra det, schemat för utvecklingen och arbets produkter.
      - Utveckling metod där alla steg är planerade i detaljer
        
        baserat på ingenjör projekt hantering tekniker, ett traditionellt sätt av hantering av stora SW utvecklings projekt
    - - Planerings steg
        
        Periodiskt/ development planning under projektet när man ändrar i planen med tanke på erfarenhet och kunskap som man fått under utvecklingen. beroende på vattenfall, agile osv blir det lättare att ändra i planen.
        
        Development planning
        
        Projekt schemat, kostnader och risker måste hela tiden ses om
        
        Projekt planen bör ändras kontinuerligt ju mer man lär sig om utvecklingen.
        
        Under start up phase
        
        Projekt startup planering
        
        Planen ska visa hur man kontrollerar projektet (strategi), vad som händer. genom ex informal diskussion med personalen om vad som händer
        
        Skapa detaljerad plan för att avgöra projektets budget och personal (resurser)
        
        Medveten om krav, men inte design och implementation
        
        Hur resurser skall användas
        
        hur projektet skall brytas ner i inkrement
        
        Vilken personal i projektet
        
        Förslag givning/Bjudgivning av kontrakt eller utveckling av systemjukvara. Behövs en plan vad gäller resurser osv.
        
        Skall inkludera plan med enkla krav. Målet är att tillge information som kan användas för att sätta ett pris för systemet till kunderna. Prissättning involverar avgörande om hur mycket en utveckling skall kosta med faktorer som, personal kostnader, hårdvara, mjukvara, osv.
        
        Prissättning
        
        Pricing to win
        
        Fler kostnader kan tilläggas när krav ändras och kan kompensera original priset som var lågt
        
        Om det är lägre än utvecklingskostander, så sänker man dem för att senare tillägga extra funktioner i andra versioner
        
        Priset är satt efter vad Sw utvecklare tror att köparen är villig att betala
        
        Prissättnings strategier
        
        Över pris (ökad )
        
        1 more item...
        
        Under pris
        
        1 more item...
        
        Faktorer som påverkar SW prissättningen
        
        Krav ändrings volatilitet låg pris i början, men med ändringar tar man ut kostnader
        
        Marknads möjligheter, för att få en fot i en marknad, tar man emot en låg kostnad för att senare tjäna stora cash
        
        Finansiell hälsa, vid ekonomisk svårigheter är de viktigt att sälja vid låg pris än inte, cash flow är viktigt i svåra tider. break even istället för konkurs
        
        Kostnad beräknings osäkerheter, osäkerheter kan ge högre kostnad för säkerhetsskull
        
        Kontrakt villkor, såsom om köparna får utveckla vidare eller skapa annat med källkoden
        
        Breda organisationer, ekonomi och politiska och affärmässiga avägningar influerar priset
        
        ingen enkel relation mellan utveckling kostnader och priset för kunderna
        
        Beräkningar för att upptäcka kostnader för utvecklingen och produktionen av Sw systemet, som hw,sw, transport, träning osv
    - - Iterativ och levereras i increment
        
        Olik plandriven, är funktioner av incrementen är inte planerade i förväg, utan bestäms under utvecklingen. vad som tas med beror på kundens prioritet och utvecklingen
        
        Kraven ändras kontinuerligt, så det är bra med flexibilitet i schemat
      - Planerings steg
        
        leveransklar planering
        
        planerar framöver vilka särdrag/kännetecken skall finnas med.
        
        Iterations planering
        
        kortsiktigt, fokuserar på att planera inkrement, 2-4 veckors arbete
      - Story based planning
        
        planeringen är baserat runt användar stories som reflekterar särdrag som skall inkluderas i systemet
        
        Man rankar stories, prioriterar
        
        insats poäng, som reflekterar deras storlek och svårighetsgrad av implementation
        
        Summera all insats poäng som krävs, är lika med totala tid för att skapa systemet
        
        Release och iteration planering
        
        Välja och renodla stories som reflekterar särdragen som skall implementeras i ett release system och vilken ordning de ska implementeras.
        
        Stories implementeras i varje iteration.
        
        Lagets hastighet är använd till att guidea valet av stories så att de kan levereras i en iteration
      - Uppgifts tilldelning
        
        Stories bryts ner i utvecklings uppdrag.
        
        uppdrag ca 4-18 timmar
        
        måste klaras för allt som implementeras i iterationen
        
        individuella utvecklare registrerar sig för en specifik uppgift som ska implementeras
        
        Fördelar med denna metod
        
        Hela laget får en översikt av uppgifter som skall klaras inom iterationen
        
        Utvecklarna har en känsla av ägarskap i uppgifterna då känner de sig motiverade till att klara de.
      - Leverera mjukvara
        
        En SW inkrement levereras alltid i slutet av varje iteration
        
        Om särdragen som ska ingå i inkrementet inte hinner bli klart, omfattningen av arbetet är då reducerat
        
        Tidsplanen utökas aldrig
      - Problem (nackdel)
        
        beroende av kunders bidrag och tillgänglighet
        
        svårt med representativa som har andra prioriterade arbeten
        
        vissa organisationer är mer vana vid traditionella ingenjör processer och har det svårt att anpassa till agile planerings process
      - Passar (fördel för):
        
        passar små stabila utvecklings grupper som kan diskutera stories med varandra
        
        Men, stora och geografiskt distribuerade medlemmar förändras alltid, det är i princip omöjligt för alla att vara involverade i ett collaborativt planering som är viktigt för agile project hantering
  - - - dela upp tid, insats, resurser som krävs för att utföra en uppgift
      - Organisera uppgifter samtidigt för optimal användning av arbetskraft
      - Minimera uppgift beroende, för att undvika försening som stör hela projektet, andra behöver vänta osv.
      - Beroende på projektledarens intuition och erfarenhet
      - Tidsplanerings processen
        
        Identifiera aktiviteter
        
        identifiera aktiviteters beroende
        
        Beräkna resurser för aktiviteter
        
        Tilldela uppgifter till personalen
        
        Skapa projekt schema diagram
        
        Presentation av Schema
        
        Grafisk beteckning
        
        Visar projektet i uppgifter, inte för små mellan 1-2 veckor
        
        Kalender baserad
        
        Bar schema, välanvänd, visar i form av aktiviteter eller resurser mot tid
        
        Aktivitet nätverk
        
        Visar uppgift besittningar och personal Se pp s86
        
        Varje aktivitet har:
        
        Tid
        
        Insats, personal dagar osv.
        
        Dead-line, då det ska vara klart
        
        slut tid, då man har slut möte, klart med tester osv.
        
        Milstolpar och leverable
        
        Milstoplar: steg i schemat som visar utveckling, tex då man lämnar över system för testning
        
        Leverable: produkter som kan överlämnas till kunder, tex krav document, eller system
        
        Lista uppifrån ner. Uppgift, insats (persondagar), Dagar, och besittningar
      - Problem
        
        Svårigheter med att beräkna problem och dess kostnader för lösning
        
        produktivitet är inte propotionellt till antalet personal
        
        Addering av personal till sena projekt försenar det för kommunikations kostnader
        
        Det oväntade sker alltid, tillåt oförutsedda risker i planeringen