Høgskolen i Telemark Sluttprøve 2014 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 og forelesningsnotater. Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2014.06.02 Time: 09:00-12:00 Oppgavesettet består av følgende: Antall sider: 19 (inkl. denne siden og vedlegg) Antall oppgaver: 5 Vedlegg: Ingen Hjelpemidler: Ingen 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å fagansvarlig for å få hjelp til å tolke noen av eksamensoppgavene. Hvis du mangler eventuelle forutsetninger for å løse oppgaven, må du definere passende antagelser selv. Vennligst bruk kulepenn. Korte og presise svar kreves.
Oppgave 1 (20%): Softwareutvikling Oppgave 1.1 (5%) Gi en kort oversikt over de ulike fasene i forbindelse med softwareutvikling. Faser i softwareutvikling: Kort beskrivelse av de ulike fasene i systemutvikling: Requirements: In the requirements we describe what the system should do. The requirementsinclude both functional requirements and non- functional requirements Design: In the design phase we use the specification and transform it into descriptions of how we should do it. Implementation: Coding Testing: Testing can be performed on different levels and by different persons. Testing is a very important part of software development. About 50% of the software development is about testing your software. 2
Deployment: Software deployment is all of the activities that make a software system available for use. Maintenance: Software Maintenance is defined as: The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. Oppgave 1.2 (5%) Hva er Scrum? Skisse: Scrum - Keywords: Scrum - a term used in Rugby football A Framework for Software Development An Agile Software Development method Iterative and Incremental Approach for Software Development, Software available to Customers every 2-4 weeks Simple to understand Flexible, but exremely difficult to master! Why? Daily Scrum Meetings Self- organizing and cross- functional Teams (3-9 persons) 3
Scrum Team: +++ o Product Owner o Scrum Master o Development Team Oppgave 1.3 (10%) Hva er hovedforskjellene mellom Agile (smidig) softwareutvikling og tradisjonelle plandrevne metoder for softwareutvikling. Gi noen eksempler i hver kategori. Smidig vs. plandrevet: Smidig utvikling: Dynamisk kravspesifikasjon Prioriterer å håndtere kravendringer underveis Inkrementell levering Eksempler: Scrum, XP, Lean, Kanban,.. Plandrevet utvikling: Statisk kravspesifikasjon Prioriterer å utvikle systemet basert på en forhåndsbestemt plan Oftest ett endelig produkt Eksempler: Fossefall, V.modell, Spiral metoden Noen eksempler i hver kategori. 4
(bør ha med minst 2 i hver kategori for full pott): + bør ha med litt om når man bør vruke Smidig og når man bør bruke plandrevet. Oppgave 2 (25%): Software- modellering Oppgave 2.1 (10%) Lag et Use Case diagram (bruksmønsterdiagram) for et minibank- system. Forklar i tillegg diagrammet med ord. Forklar kort hensikten med et Use Case diagram (bruksmønsterdiagram). Et use case (bruksmønsterdiagram) er en beskrivelse av hvordan systemet oppnår et mål av verdi for en aktør. Bruksmønster diagrammer (Use Case diagrams) brukes til å beskrive interaksjonen mellom brukere og systemer. Bruksmønstre beskriver interaksjonen mellom et system og eksterne aktører. Forslag til Use Case diagram (bruksmønsterdiagram) for et minibank- system: 5
+ Kjøp Ringetid Oppgave 2.2 (15%) Anta at du skal lage en webbutikk som selger datamaskiner, TVer, kameraer, osv. Lag et databasediagram (ER diagram) for dette systemet. Forklar i tillegg diagrammet/løsningen med ord. Forslag til ER- diagram: 6
Fordel å ha med datatyper også. Man må ha med forklaringer/beskrivelse av løsningen også. 7
Oppgave 3 (15%): Kildekodekontroll Oppgave 3.1 (5%) Forklar kort hensikten med kildekodekontroll. A version control system keeps track of all work and all changes in a set of files (typically your code files, but also other files) Allows several developers (potentially widely separated in space and time) to collaborate All Software Developers need it!! + Backup, jobbe med flere versjoner samtidig, Oppgave 3.2 (10%) Hvilke 2 hovedtyper kildekodekontroll har vi? Gi en kort beskrivelse av disse, samt eksempler på kildekodekontroll- systemer innenfor disse hovedtypene. Centralized/Client Server architecture: A server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes DVCS - Distibuted Version Control System: With a distributed version control system, there isn t one centralized code base to pull the code from. Different branches hold different parts of the code. Git is a DVCS. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used. DVCS uses Peer- to- peer approach. Here are a list with some of the most popular SCC systems on the market today (bør ha med minst 2 i hver kategori for full pott): Team Foundation Server (TFS) CVS SVN (Subversion) 8
Git Mercurial Bazaar LibreSource Monotone BitKeeper SCC systemer inndelt i de 2 hovedkategriene: TFS: TFS is a Source Code Control (SCC), Bug Tracking, Project Management, and Team Collaboration platform. TFS is tightly integrated with Visual Studio as Microsoft is the vendor of both Visual Studio and TFS SVN: SVN or Subversion uses an Open Source License. SVN was established in 2000. Subversion is probably the version control system with the widest adoption today. Many different Subversion clients are available (Tortoise SVN, Mac: Versions, Xcode (built- in support for SVN)). CVS: CVS, or Concurrent Versions System was established between 1986-1990. It is free of charge. CVS uses a client server architecture. It is widely supported in different IDEs (Eclipse, Xcode, etc.). Git: Git has become very popular today. Git is a Distributed Version Control System (DVCS). It was initially designed and developed by Linus Torvalds (Linux Guru) in 2005. Git is free of use. 9
Oppgave 4 (20%): Testing Oppgave 4.1 (5%) Forklar kort hva er hensikten med testing? Testing: Finding Bugs in the Software before it is released to the Customer Finding unwanted system behaviours Verify/Validate that the Software works as expected (according to the Specifications) Find bugs as soon as possible! Software systems not working = Money lost for the Customers! Oppgave 4.2 (5%) Forklar kort forskjellen mellom White- box testing og Black- box testing, samt eventuelle fordeler/ulemper. Blackbox- testing tester funksjonaliteten til en applikasjon. Dette kan illustreres slik: Fordeler med blackbox- testing: Fokuserer på å teste funksjonalitet o Abstraherer vekk de interne strukturene o Oversiktlig 10
Krever ikke høy teknisk kompetanse Finner krav som ikke er implementert riktig eller mangler Ulemper med blackbox- testing: Vi vet ikke hvor i koden det forekommer feil eller hva som egentlig forårsaker problemet Du har aldri mulighet til å oppdage feil du ikke har skrevet input for Sier lite om hvordan du for eksempel kan optimalisere ytelse Whitebox- testing tester de interne strukturene til systemet. Dette kan illustreres slik: Fordeler med whitebox- testing: Du ser nærmere på den faktisk logikken i koden for å forstå hva som foregår o Dette gir en mye grundigere analyse av eventuelle problemer Ulemper med whitebox- testing: Du må være ekspert og kjenne til koden din godt o Utfordrende for andre å sette seg inn i det som foregår Finner ikke krav som ikke er implementert Oppgave 4.3 (10%) Gi en kort oversikt over ulike testmetoder/nivåer. Enhetstesting: 11
Enhetstesting tester individuelle enheter av kildekode o I objektorientert 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 Integrasjonstesting: I integrasjonstesting setter vi sammen enheter til og gjør tester på komponenter. Regresjonstesting: Når vi benytter regresjonstesting utfører vi de samme testene om igjen etter hver kodeendring, selv om kodeendringen ikke nødvendigvis ligger i den koden som omhandler testen "Gamle" feil kommer ofte tilbake etter kodeendringer, og en av årsakene er at utviklere kan sjekke inn feil versjon av kode Det er ofte slik at en endring et sted i koden kan ha følger andre steder i programmet som man ikke forutså på forhånd Akeptansetesting Sluttest som kunden er innvolvert i FAT/SAT Skisse over testmetoder: 12
13
14
IA4412 Systemutvikling og dokumentasjon Sluttprøve med løsninger 2014 Oppgave 5 (20%): Deployment og Vedlikehold Oppgave 5.1 (5%) Forklar de ulike releasene som er vanlig i forbindelse med softwareutvikling. Typically we have the following Internal releases: Alpha Release(s) Beta Release(s) RC - Release Candidate(s) You are finished: RTM Release To Manufactoring You software is good enough and it is ready for Deployment! Oppgave 5.2 (10%) 15
Beskriv kort ulike typer dokumenter som typisk utarbeides ifm utvikling av software. Dokumentasjon ifm softwareutvikling: Eksempler på dokumentasjon som utarbeides ifm de ulike fasene i SDLC: 16
Kategorier: 17
Oppgave 5.3 (5%) Gi en oversikt (med eksempler) over ulike typer/kategorier av softwarevedlikehold (maintenance). Software Maintenance is defined as: The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. Ulike kategorier av vedlikehold (lærebok #1): Maintenance Corrective Adaptive Perfective Preventive Description Repair of defects relative to existing requirements. These defects are typically discovered by customers as they start using your software. Adapt your software to changes in the operationg environment, e.g., when a new OS is released or a new version of the hardware. As software systems evolve, it is very likely that it will occure changes in the external environment (OS, hardware, etc.) your software depends on. New features based on new user requests. The software must continuously adapt new needs or your software will become usesless. Changes in your software to make it easier to maintain. Changes from Corrective, Adaptive and Perfective makes your software more complex, more difficult to maintain, etc. Preventive maintenance in form of Refactoring should be done on a regular basis Evt. (lærebok #2): 18
19