Løsningsforslag. Sluttprøve Emne: IA4412 Systemutvikling og dokumentasjon. Klasse: IA2, A-vei Dato: Time: 09:00-12:00

Transkript

1 Høgskolen i Sørøst-Norge Løsningsforslag Merk! Løsningene som er skissert er ikke nødvendigvis de eneste riktige løsningene, samt noen av løsningsskissene er kun stikkordpreget/mangelfulle. For fullstendig beskrivelser og forklaringer, se lærebøker, forelesningsnotater, etc. Sluttprøve 2016 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans-Petter Halvorsen og Olav Dæhli Klasse: IA2, A-vei Dato: Time: 09:00-12:00 Oppgavesettet består av følgende: Antall sider: 17 (inkl. denne siden og vedlegg) Antall oppgaver: 8 Vedlegg: Ingen Hjelpemidler: Ingen hjelpemidler tillatt Sluttprøven teller 30% av sluttkarakteren. Kandidaten må selv kontrollere at oppgavesettet er fullstendig. Fagansvarlig besøker normalt ikke eksamenslokalene. Kandidater kan ikke kalle på fagansvarlige for å få hjelp til å tolke noen av eksamensoppgavene. Hvis du mangler eventuelle forutsetninger for å løse oppgaven, må du definere passende antagelser selv. Alle svar må begrunnes, selv om det ikke står dette eksplisitt i oppgaveteksten! Vennligst bruk kulepenn og skriv tydelig. (Hvis sensor ikke kan lese håndskriften har man ikke annet valg enn å gi 0 poeng)!

2 Oppgave 1 (15 %): Database (E/R) Diagram Logisk modell (E/R): Fysisk modell: Må ha med litt forklarende tekst i tillegg til diagrammet/diagrammene! Best Practice -regler: Here are some Best practice recommendations for creating tables in a database system: Tables: Use upper case and singular form in table names not plural, e.g., STUDENT (not students) Columns: Use Pascal notation, e.g., StudentId Primary Keys: If the table name is COURSE, name the Primary Key column CourseId, etc. Always use Integer and Identity(1,1) for Primary Keys Specify Required Columns (NOT NULL) i.e., which columns that need to have data or not 2

3 Data Types: Standardize on these Data Types: int, float, varchar(x), datetime, bit Use English for table and column names Avoid abbreviations! (Use RoomNumber not RoomNo, RoomNr,...) 3

4 Oppgave 2 (20 %): UML Diagram Use Case eksempel (10%): Må ha med litt forklarende tekst i tillegg til diagrammet/diagrammene! Klassediagram eksempel (10%): Eksempler på Klasser: Login Appointment User Doctor (arver fra User) Patient (arver fra User) 4

5 .. Må ha med litt forklarende tekst i tillegg til diagrammet/diagrammene! 5

6 Oppgave 3 (5 %): Kravspesifikasjon Funksjonelle/ikke-funksjonelle krav (4%) Eksempler på funksjonelle krav: Ansatte skal kunne registrere nye pasienter i databasen En lege skal kunne få generert en rapport med liste over alle sine timeavtaler en bestemt dag eller uke. En bruker skal fra kalendervisning kunne klikke på en ledig legetime og så reservere denne. En bekreftelse skal sendes brukeren pr. e-post. I kalendervisning skal brukere kunne endre mellom dag-, måned- eller årsvisning Eksempler på ikke-funksjonelle krav: Security: Systemet må sikres brukerautentisering og kryptering, så ikke pasientopplysninger kan komme på avveie. Reliability: 1) Backup må foretas av alle data hver natt. 2) Flere personer må kunne bruke systemet samtidig, uten at det risikeres dobbelt-booking av time (samtidighetskontroll). Usability: 1) Minimum åtte av ti testpersoner skal klare å bestille en time med systemet i løpet av 1 minutt, uten bruksanvisning. 2) Informative feilmeldinger skal gis ved feilsituasjoner. Performance: Innen 1 minutt skal brukeren ha fått en e-postbekreftelse på sin timebestilling. Supportability: Systemet skal minimum fungere med følgende nettlesere: Internet Explorer, Firefox, Chrome og Safari. Mulig å teste? (1%) Ja, det skal være mulig å teste et ikke-funksjonelt krav. Alle krav skal være kvantifiserbare, også de ikke-funksjonelle, sånn at det er mulig å teste dem. 6

7 Oppgave 4 (10 %): Scrum/Utviklingsprosesser Forslag til prioritert Backlog (4%) Hvem har ansvaret for prioritering av PBI? (1%) Product Owner eller Produkteieren på norsk. Dette er typisk kundens representant i prosjektet. Neste trinn? (1%) Starte selve utviklingen, dvs. Starte Sprint Planning og velge ut oppgaver fra Product Backlog inn i Sprint Backlogen for gjeldende sprint Burndown chart (1%) Et prosjektstyrings-verktøy som brukes i Scrum. Her trackes hvor mye som gjenstår dag for dag i gjennom sprinten. Plottet viser Tid (dager) vs. Remaining Work. Forskjellen? (2%) Forklar forskjellen på smidig (Agile) og plandrevet utvikling: Plandrevet: Prosessaktivitetene planlagt på forhånd. Progresjon måles i henhold til planen En tung prosess inkluderer mange aktiviteter og ofte roller. Krever formelle, detaljerte og konsistente prosjektdokumenter Ofte for-tunge Smidig (Agile): Planleggingen gjøres litt etter litt (inkrementelt) 7

8 Enklere å endre prosessen for å tilpasse endrede krav fra kunden Fokuserer mer på fundamentale prinsipper (f.eks. kontinuerlig testing ). Har færre formelle dokumenter og er ofte mer iterative Eksempler (1%): Eksempler på plandrevne prosessmodeller: Fossefallsmetoden V-modellen Spiral-metoden Eksempler på Smidige prosessmodeller: XP Scrum Kanban 8

9 Oppgave 5 (10 %): Design/Arkitektur GUI (5%) Her finnes mange løsningsalternativer til GUI. Det er viktig at det er enkelt og intuitivt å bruke, minst mulig klikk for brukeren osv. Arkitektur (5%) Arkitektur: Typisk klient-server med database for lagring av data. Bruk av Webteknologi kan være en fordel med tanke på forenklet installasjon og vedlikehold, m.m. 9

10 Oppgave 6 (15 %): Enhetsesting 2 Enhetstester (10%) - 5% for hver Enhetstest-eksempel i Visual Studio: using System; using Microsoft.VisualStudio.TestTools.UnitTesting; using BankAccountNS; namespace BankTest { [TestClass] public class BankAccountTests { [TestMethod] public void TestMethod1() { } } } Sjekk: Assert.AreEqual(expected, actual, 0.001, Test failed because..."); Kjøring (3%) Kjøring av enhetstestene: Code coverage (2%) Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. 10

11 Depending on the input arguments, different parts of the code will be executed. Unit Tests should be written to cover all parts of the code 11

12 Oppgave 7 (10 %): Testing Forskjellen (4%) Enhetstester: Individuelle programenheter eller objekt-klasser testes. Fokus på å teste funksjonaliteten til objekter og metoder. Enhetstesting tester individuelle enheter av kildekode. I objekt-orientert programmering kan det være en hel klasse eller en metode Enheten testes helt isolert fra resten av systemet Formålet med en enhetstest er å forsikre at koden gjør akkurat det den skal. Integrasjonstester: I integrasjonstesting setter vi sammen enheter og gjør tester på komponenter. Ulike individuelle enheter er integrert til sammensatte komponenter. Fokus på å teste grensesnittet til komponenter. Eksempler (6%) Eksempler ifm. lege-timesystemet: Enhetstester: Integrasjonstester: 12

13 Oppgave 8 (15 %): Dokumentasjon Oversikt (5%) Typisk dokumentasjon ifm. software-utvikling: Dokument-kategorier: Process Documentation 13

14 Typisk Prosess-dokumentasjon: Development Plan (with Gantt Chart, Resources, etc.) Meeting documentation (included in VSO) Requirements & Design Document Test Plan (how to test, etc.) & Test Documentation (Test results, etc.) Product Documentation Typisk Produkt-dokumentasjon: System Documentation o How the System Works in a technical way. Use the Requirements & Design as the foundation. o Requirements & Design is about how it should be, while System Documentation is about how it became o Includes Technical Design and Platform Overview, Database Diagram, UML diagrams, CAD drawings, Code Documentation, Flow Charts, with explanations, etc. o How to deploy (how to install server-side logic), maintain, etc. User Documentation Typisk User-dokumentasjon: Installation Guide (you may include it as part of User Manual and/or System Documentation) User Manual(s) Innhold (10%) Software Development Plan (SDP): Introduction: This briefly describes the objectives of the project and set out the constraints (e.g., budget, time, etc.) that affects the management of the project Project Organization (Team Description) This section describes how the development team is organized, the people involved and their roles in the team. Software Process Model Description (Scrum, XP, Waterfall,...), etc. Risk Analysis Hardware and Software Resource Requirements 14

15 Work Breakdown (WBS, Work Breakdown Structure): Break down the project in into activities and identifies milestones Project Schedule: Shows dependencies between activities, the estimated time required to reach each milestone, allocation of people to activities. (5) and (6) is typically done in a Gantt Chart (created in e.g. Microsoft Project) Monitoring and Reporting Mechanisms: Definition of the Management Report that should be produced, when they should be produced, etc. Tools that you are using SRD/SDD (->SRD) Et løpende dokument som brukes til å gi en oversikt over hva som skal lages (Requirements)/utvikles og hvordan det skal lages/utvikles (Design). Brukes som en kontrakt mellom utviklingsfirma og kunde, samt brukes kontinuerlig av utviklere (når de skal lage/utvikle løsningen), testere (når de skal teste løsningen) og kunde (sike at løsningen blir slik de ønsker) underveis. Mye av innholdet lages i oppstarten av prosjektet (eller i forkant av prosjektet), men innholdet må oppdateres kontinuerlig når endringer oppstår, særlig med med smidig utvikling vil dette være tilfellet. Software Test Plan (STP): 15

16 Typisk innhold: Goals and Exit Criteria (Quality, Robustness, Schedule, Performance Goals of the Product,...) Items to be Tested/Inspected (Executables such as modules and components, Non-executables such as Requirements and Design specifications,...) Test Process/Methodologies (Unit, Functional, Acceptance, Regression Tests, Black-box, White-box, Test metrics, Bug report process,... ) Resources (People, Tools, Test Environment,...) Schedule (Test-case development, Test execution, Problem reporting and fixing,...) Risks (...) Major Test Scenarios and Test Cases (...) Beskrivelse av Testmiljø, hvor er testmiljøet? hvordan bruker man det? Evt hvordan setter man det opp, osv. Beskrivelse av Prosedyrer for Bug-rapportering. Hvor rapporterer man Bugs? Hvordan rapporterer man Bugs? Osv. User Manual: A cover page A title page and copyright page A preface, containing details of related documents and information on how to navigate the user guide A contents page A guide on how to use at least the main functions of the system (Text + Screen Shots) A troubleshooting section detailing possible errors or problems that may occur, along with how to fix them A FAQ (Frequently Asked Questions) Where to find further help, and contact details 16

17 A glossary and, for larger documents, an index 17