9 svar · 1 638 visningar · startad av Compusa
Sitter med en akademisk rapport lagom innan jul och tänkte se om man kunde få lite tips och inspiration av personer som sysslat med liknande. I ett av avsnitten i rapporten ska resultatet av implementation av mjukvaran beskrivas. Det första jag tänker som resultat är koden som skrivits och hur "programet" ser ut och fungerar. Står lite still i min trötta hjärna så tips/punkter som kan vara bra att ta upp, mottages gärna :)
Flödesschema?
UML
Syfte och förutsättningar.
Tankar om olika vägar.
Scenariobeskrivning av ett händelseflöde
UML beskrivning. Kolla Thogether eller Star Team
Hårdvaruförutsättningar
Kodningsförutsättningar
Kända problemområden.
Testupplägg.
Resultatet av implementationen av mjukvaran tycker jag låter som någon slags utvärdering. Hur bra uppfyller mjukvaran kravspecen? Uppfyller programmet sitt syfte, dvs skapade det värde för användaren? En heuristisk utvärdering kan du göra själv, eller så kan du låta en användare (någon annan än du själv) testa applikationen medan du dokumenterar resultatet.
Tack för alla tips, dags att skriva :)
För att redovisa resultaten av en implementation bör du väl utföra test-casen som bör vara definerade ända från kravspecstadiet och nedåt. Genom att följa dem och presentera resultaten är du "home free". Hur pass omfattande testerna ska vara beror på de övergripande kraven för applikationen. Det har alltså inget med UML att göra, så länge det handlar om implementation. Om du ska ha med design kan du ta med UML eller nåt annan beskrivande teknik/språk. Är det en rapport över utveckling från idé till färdig produkt får du tugga igenom hela utvecklingsmodellen som innehåller alla steg i detalj. Isf kan du söka lite på exempelvis "waterfall model" eller liknande. Finns en hel del bra sidor att besöka om det är det senare du söker.
Vilken standard följer rapportskrivning för mjukvara? Jag menar, olika områden har ju lite olika standarder även om dessa inte skiljer sig så mycket åt. Någon som vet?
PeW skrev:
För att redovisa resultaten av en implementation bör du väl utföra test-casen som bör vara definerade ända från kravspecstadiet och nedåt. Genom att följa dem och presentera resultaten är du "home free". Hur pass omfattande testerna ska vara beror på de övergripande kraven för applikationen. Det har alltså inget med UML att göra, så länge det handlar om implementation. Om du ska ha med design kan du ta med UML eller nåt annan beskrivande teknik/språk. Är det en rapport över utveckling från idé till färdig produkt får du tugga igenom hela utvecklingsmodellen som innehåller alla steg i detalj. Isf kan du söka lite på exempelvis "waterfall model" eller liknande. Finns en hel del bra sidor att besöka om det är det senare du söker.
I detta projekt använder vi varken UML eller Use cases och det beror på att mjukvaran vi utvecklat är en agent-baserad mjukvara. Vi använder oss av Prometheus Methodology vilken är anpassad för att designa bdi-agenter.
Cassady skrev:
Vilken standard följer rapportskrivning för mjukvara? Jag menar, olika områden har ju lite olika standarder även om dessa inte skiljer sig så mycket åt. Någon som vet?
Det där är nog lite olika tror jag men vi skriver efter IMRAD-standarden:
* Introduction
* Methods
* Result
* Discussion
Projekt har vi hållit på med i två månader, dock är dokumentation väldigt omfattande, ett axplock: ;)
* Rapport
* SRS
* SDS
* SDS Agent Platform
* Tesplan, test cases osv
* Project Plan
Compusa skrev:
I detta projekt använder vi varken UML eller Use cases och det beror på att mjukvaran vi utvecklat är en agent-baserad mjukvara. Vi använder oss av Prometheus Methodology vilken är anpassad för att designa bdi-agenter.
Jo, nu har jag inte projekterat agenter men väl en del "vanlig" mjukvara och realtids/säkerhetskritiska system. UML är ju bara en i raden av sätt att modellera och till vissa saker fungerar andra ADL's bättre, bl.a för att på ett tidigt stadie få med semantiken att ha till analysen. Till realtid är UML inget vidare, t.ex. Men själva utvecklingsprocessen för mjukvara brukar inte skilja sig märkbart, ivf som jag vet. En del apps har högre krav på sig än andra och där krävs mer detaljerad analys/testning. För att skriva en vanlig akademisk rapport om det skulle jag ta med hela utvecklingsprocessen och ha en betoning på analys/test. Det jag möjligen skulle undvika att ta med är kostnader, vilket är av ringa akademiskt intresse.
Projekt har vi hållit på med i två månader, dock är dokumentation väldigt omfattande, ett axplock:
* Rapport
* SRS
* SDS
* SDS Agent Platform
* Tesplan, test cases osv
* Project Plan
Skulle vilja lägga till utvärdering och underhåll. Annars ser det "normalt" ut, såsom jag fått lära mig. Hur de gör i "det riktiga" livet har jag dock ingen aning om :e
