Repetera Flashcards
(22 cards)
4+1 view model
Use case view: Describes the functionality of
the system from the perspective of outside
world. Usecase
Logical view: abstract description of a
system’s parts. Class
Process view: escribes the processes within
your system. Activity
Physical view: shows how the
abstract parts map into the final deployed
system.
Development view: shows
how your system parts are organized into
modules and components.
7 synder
Checklista vid dokumentering.
1. Brus = Inkonsekvent terminologi. Nya termer introduceras utan tydlighet.
2. Tystnad=Viktig info utelämnas, svårt för mottagaren att tolka.
3. Överspecificering=Lösningen beskrivs istället för önskade egenskaper.
4. Motsägelse=Inkonsekventa eller motstridiga krav.
5. Tvetydlighet=Oklara formuleringar med flera tolkningar.
6. Framåtreferensgrepp = Begrepp används innan de definerats.
7. Önsketänkande= Krav som inte är tekniskt eller ekonomiskt realistiskt.
six advantage
- Formal language = Well defined notation och clear definitions prevent misunderstandings.
- Concise = Simple and straightforward notation.
- Comperhensive = Covers all critical aspects os a system.
- Scaleable= Works for both small and large projects.
- Lessons learned=Reflects best practice from years of experience.
- Standard=Widley accepted and ensures compatibility across tools and terms.
Mötet mellan verksamhet och IT
I en verksamhet pågår en massa saker, och ibland uppstår då en del problem. Tex. dubbelarbete. Det som uppstår är ett behov som kanske kan lösas av ett IT-system.
Verksamheten sammanfattar problemen, behoven och krav på IT-systemet i en kravspecifikation. Kravspecifikationen tas emot av en till flera olika IT-leverantörer som svarar med att presentera olika lösningar i en lösningsspecifikation.
Mötet mellan olika roller:
Man har olika fokus ifrån olika roller. Tex från kund och leverantör. Kundens behov/mål kontra leverantörens. Kunden vill anpassa systemet efter verksamhetens krav och leverantören vill standalisera för att slippa anpassningar till olika kunder.
Dependency
When objects of one class work briefly with objects of another class
Association
When objects of one class work with objects of another class for some time
Aggregation
When one class owns but shares a reference to objects of another class
Composition
When one class contains objects of another class. Ex. If we have a class “house” and a class “room”. A house can exist whitout the room but the room can not exist without the house.
Inheritance
When one class is a type of another class.
Ex. If we have one class “person”, our class “techer” and “student” are a type of the class “person”.
Framgångs faktorer för en lyckad granskning
- Författaren har gjort grundläggande kontroller av dokumenter, stavfel, slarv osv.
- Granskarna har fått tillräcklig tid för att läsa dokumentet
- Tillräcklig information till mötesdeltagarna. Hur ska mötet gå till och vad ska vem granska?
- Rätt granskare valda, olika roller på granskarna.
- Långa diskussioner undviks, hur något specifikt ska designas tex.
- Håll start- och sluttider, rent hyffs.
5 problem med kravhantering
- Inte tillräckligt med tid
- Kommunikationsbrister mellan leverantör och kund.
- Underspecificerade krav som är för abstrakta.
- Ofullständiga och/eller dolda krav.
- Rörliga mål (ändrar mål, arbetsprocesser eller krav.
Fördelar med iterativt arbete
- Snabbare återkoppling: Genom att utöka kraven kontinuerligt blir det möjligt att se samband mellan kraven och justera dem i tid om felaktigheter upptäcks.
- Bättre överblick:Att överblicka kraven på rubriknivå är det lätt att förstå sammanhanget.
- Iterativt arbete stödjer pararella aktiviteter=Redan när kraven börjar tas fram kan utvecklare, arkitekt och testare inleda sitt arbete med kraven och börja skapa en design baserat på kraven.
Blackbox/Whitebox
Black box-tester
* Testfall som går ut på att
prova systemets funktionalitet
White box-tester
* Testfall som går ut på att
granska programkodens
beteende.
Personas
En insamlingsteknik.
Personas innebär at man skapar ett antal fiktiva personer som används i diskussioner om vilka krav ett system ska uppfylla.
Prestandatest
Test med normalastora mängder, för att se om systemet påverkas av normal belastning tex. användare.
Ska systemet användas av 100st testar man med 100st eller något mer men inte med 400st.
Stresstest
Är ett test där vi testar hur systemet påverkas av överbelastning. Görs på ungefär samma sätt som prestandatest men med betydligt mycket större mängder än vad som är tänkt normalt för systemet.
Säkerhetstest
Test för att se om systemet klarar att hålla obehöriga ute.
Hur går man tillväga för att ta fram en välgrundad och spårbar kravspecifikation?
Dokumentera alla identifierade krav i ett strukturerat format
Analysera, kategorisera och prioritera kraven
Skapa spårbarhet henom att ge varje krav ett unikt ID, dokumentera kravets ursprung och ange kopplingar mellan relaterade krav
Kravhantering beskrivs ibland som mötet mellan verksamhet och kravspecifikation. Förklara hur verksamhet och kravspecifikation samspelar vid kravhantering
Verksamhetens behov översätts till konkreta, mätbara krav i kravspecifikationen
Tex:
Verksamhetsbehov: “Vi behöver effektivare orderhantering”
Kravspecifikation: “Systemet ska kunna registrera en order inom 30s”
Ange och beskriv ett användningsområde för textuell kravspecifikation vid anskaffning av existerande IT-system.
Som ett underlag för leveransutvärdering och jämförelse av befintliga system
Förklara varför det är viktigt att arbeta systematiskt med kravhantering
Det blir mer strukturerat då man har något att utgå från. Mindre missförstånd och mer effektivt arbete
