Formpipe
Platina och kvalité
Rasmus Staberg, Teknisk direktör, 2014
2014-04-08
04 08
1
Formpipe Presentation
Bakgrund
•
•
•
•
Platina släpptes som första release år 2000.
Fick pris för ”Best in show” från Bill Gates på .Net awards
Platina Life Science – startade 2008
• => mycket fokus på kvalité i utvecklingsprocessen
• => komplett kvalitetsledningssystem med fokus på
spårbarhet
”Det som inte är dokumenterat existerar inte”
2
Formpipe Presentation
Kvalitetsledningssystem
•
•
•
•
•
•
Baserat på GAMP 5 (riktlinjer inom läkemedelsbranschen)
Utvecklingsmodellen baserad på ISO standard
Täcker hela livscykeln – från rekrytering av personer med rätt
kompetens till release och underhåll av produkten
Består av ett repository av ”procedures”
Arbetssättet måste;
• 1. Dokumenteras
• 2. Förankras – utbildas på
• 3. Tillämpas – generera bevis på att man tillämpat rutinen
Formpipe blivit godkända vid ett antal ”audits” från olika
läkemedelsbolag
• Kunderna besöker oss under 1-3
1 3 dagar och går igenom våra
processer och säkerställer att vi följer dom (kan uppvisa
bevis)
3
Formpipe Presentation
Centralt med dokumentation – från beslut av funktion till release
•
•
•
•
•
Beslut dokumenteras i mötesanteckningar
URS – User Requirements Specification uppdateras med nytt krav
FRS – Functional Requirements Specification uppdateras
DDS – Detailed Design Specification uppdateras
SAD – Software Architecture Document uppdateras
•
Kodning
•
•
•
•
•
Testplan upprättas
Testfall uppdateras/skapas
Testprotokoll
TM – Traceability Matrix (spårbarhetsmatris) uppdateras
Användardokumentation skapas/uppdateras
4
Formpipe Presentation
Kravdokument (URS)
5
Formpipe Presentation
Funktionella krav (FRS)
6
Formpipe Presentation
Funktionella krav (FRS) – generella krav
7
Formpipe Presentation
Funktionella krav (FRS) – exempel på ett funktionellt krav
8
Formpipe Presentation
Detaljerad design spec (DDS)
9
Formpipe Presentation
Testfall – finns för alla nivåer av krav
10
Formpipe Presentation
Testprotokoll summerat
11
Formpipe Presentation
Spårbarhetsmatris mellan alla krav och testfall
12
Hur ser processen ut i verkligheten? verkligheten?
Produktägaren
d k
–
lista med
förbättringsförslag
(”tickets”)
Beslut om saker
som ska
utvecklas
Produktägaren
kallar till
styrgrupp
Styrgruppsmöte
Produktägaren
lämnar över till
projektledaren
Projektledaren
planerar arbetet
Kodgranskning
Testning
Beslut om saker
som måste
utredas/estimera
s vidare
Kravanalys –
kolla om vi
förstår hur vi ska
lösa uppdraget
Skapa ”paket”
och släppa en
release
Påverkan – kolla
om det påverkar
andra saker
Dokumentation
– vad behöver
skapas/ändras?
UTVECKLING
Platina QMS Process System
•
Så här
hä hänger
hä
processerna
ihop i våra rutiner
Alla rutiner lagras självklart i vårt interna Platina
•
Två typer av ändringar
• Förbättringar
 från Platina Portfolio
 från Support
•
Defekt rättningar


•
Inom utvecklingscykeln
Sparade defekter sedan
tidigare
Centralt med risk/påverkans
analys innan utveckling påbörjas
•
Påverkan av ny funktionalitet på
produkten utreds med hjälp av en
“Risk impact analysis checklist”
Formpipe Presentation
Vi hjälper utvecklaren att inte missa något - checklista
18
Formpipe Presentation
Vi hjälper utvecklaren att programmera rätt - guidelines
19
Formpipe Presentation
Vi kollar för säkerhets skull att utvecklaren gjort rätt –
kodgranskning i 130 punkter....
20
Formpipe Presentation
Vi följer upp bugg trender för att identifiera problematiska områden
21
Vi håller koll på vilka roller som är involverade I de olika processerna….
Och vem som ersätter vem om någon inte kommer till jobbet
Organizational Charter
Det finns även tydliga arbetsbeskrivningar till varje rollponsibilities
•
•
Training
Needs
ViIdentifying
i har
h ett antall standardutbildningar
d d bild
i
i våra
å olika
lik processer
Vi kollar i matrisen exakt vilka utbildningar respektive roll behöver
•
Training
Certificates
Man
få ett k
får
kursbevis
b i efter
f avklarad
kl d kurs
k
De roller som bara arbetar med kvalitetsibilities
•
•
•
Management Representative on Quality
• Utsedd av ledningen att bevaka alla de kvalitativa aspekterna
gällande verksamheten
Quality Manager (kvalitetschef)
• Bevakar på daglig basis att de upprättade rutiner följs och
identifierar avvikelser och genomför interna audits
Quality Assurance Representative
(kvalitetsrepresentant)
• Bevakar inom ett lokalt project de kvalitativa aspekterna och
rapporterar till kvalitetschefen
Testprocessenw. Test Ticket
Testning - dokumentation
•
•
•
•
Test Plan
• Skapas av test manager och godkänns av produktägare
Test Cases
• Skapas av test manager och godkänns av produktägare
Test Protocol
• Skapas av test manager och godkänns av projektledare
Test Report
• Vad som testats och på vilka miljöer
• Kända fel
• Sammanfattning av testresultat
• Godkänns av produktägare
Sedan får vi inte missa något vid release
release…... Release checklist
•
Product Owner performs physical and configuration audit for
release and fills checklist correspondingly.