| fullrecord |
[{"key": "dc.contributor.advisor", "value": "Tuunanen, Tuure", "language": "", "element": "contributor", "qualifier": "advisor", "schema": "dc"}, {"key": "dc.contributor.author", "value": "Puttonen, Heidi", "language": "", "element": "contributor", "qualifier": "author", "schema": "dc"}, {"key": "dc.date.accessioned", "value": "2018-11-15T07:03:29Z", "language": null, "element": "date", "qualifier": "accessioned", "schema": "dc"}, {"key": "dc.date.available", "value": "2018-11-15T07:03:29Z", "language": null, "element": "date", "qualifier": "available", "schema": "dc"}, {"key": "dc.date.issued", "value": "2018", "language": "", "element": "date", "qualifier": "issued", "schema": "dc"}, {"key": "dc.identifier.uri", "value": "https://jyx.jyu.fi/handle/123456789/60186", "language": null, "element": "identifier", "qualifier": "uri", "schema": "dc"}, {"key": "dc.description.abstract", "value": "Erilaisten ketterien j\u00e4rjestelm\u00e4kehitys menetelmien kasvanut suosio on vaikuttanut perinteiseen tapaan ymm\u00e4rt\u00e4\u00e4 j\u00e4rjestelm\u00e4vaatimusten hallintaa. Ketteriss\u00e4 j\u00e4rjestelm\u00e4kehitys projekteissa vaatimusm\u00e4\u00e4rittely prosessin t\u00e4ytyy mukautua kehitysymp\u00e4rist\u00f6\u00f6n, jossa keskityt\u00e4\u00e4n pienempiin osakokonaisuuksiin valmiiden tuotteiden asemesta, joissa muutos on jatkuvaa ja miss\u00e4 asiakkaan odotetaan olevan vahvasti osallisena. T\u00e4m\u00e4 vaikuttaa luonnollisesti my\u00f6s j\u00e4rjestelm\u00e4vaatimuksiin liittyviin riskeihin. T\u00e4m\u00e4 pro gradu tutkielma selvitt\u00e4\u00e4 kuinka j\u00e4rjestelm\u00e4vaatimusten riskej\u00e4 hallitaan ketteriss\u00e4 j\u00e4rjestelm\u00e4kehitysprojekteissa, sek\u00e4 miten ketter\u00e4n j\u00e4rjestelm\u00e4kehitys filosofian valinta vaikuttaa projektin j\u00e4rjestelm\u00e4vaatimusten riskikentt\u00e4\u00e4n.\nTutkielman teoreettinen osuus tarkastelee j\u00e4rjestelm\u00e4kehitys alan ajankohtaista kirjallisuutta. Yhdist\u00e4m\u00e4ll\u00e4 tietoa j\u00e4rjestelm\u00e4kehityksen yleisest\u00e4 riskien hallinnasta, vaatimusten riskien hallinnasta ja ketter\u00e4st\u00e4 j\u00e4rjestelm\u00e4kehityksest\u00e4, kirjallisuuskatsaus muodostaa kuvan j\u00e4rjestelm\u00e4vaatimusten riskien hallinnan keskeisit\u00e4 ominaisuuksista ketteriss\u00e4 kehitysprojekteissa: N\u00e4iss\u00e4 projekteissa my\u00f6s itse vaatimusten riskien hallinnan t\u00e4ytyy sopeutua iteroivaan toimintatapaan ja jatkuviin muutoksiin. T\u00e4m\u00e4 lis\u00e4\u00e4 my\u00f6s riskien muutosalttiutta ja samalla tarvetta muokata riskianalyysin laajuutta sopimaan kulloiseenkin kehitys iteraatioon. Samoin kirjallisuuskatsaus paljastaa kuinka j\u00e4rjestelm\u00e4vaatimusten riskien hallinnan pit\u00e4\u00e4 olla l\u00e4pin\u00e4kyv\u00e4\u00e4 ja mahdollisuuksien mukaan ottaa mukaan my\u00f6s projektin muita sidosryhmi\u00e4 varsinaisen kehitystiimin lis\u00e4ksi.\nEmpiirisess\u00e4 osuudessa kirjallisuuskatsauksen tuloksia rikastetaan tapaustutkimuksella. Siin\u00e4 Requirements Risk Prioritization -metodia k\u00e4ytet\u00e4\u00e4n vaati-musten riskien hallintaan ketter\u00e4ss\u00e4 j\u00e4rjestelm\u00e4kehitysprojektissa. Tapaustutkimus paljastaa kuinka yl\u00e4tasolla my\u00f6s ketter\u00e4t projektit kohtaavat saman tyyppisi\u00e4 haasteita kuin perinteisempi\u00e4 kehitysmenetelmi\u00e4 k\u00e4ytt\u00e4v\u00e4t projektit. Tapaustutkimuksesta kuitenkin selvi\u00e4\u00e4 nelj\u00e4 riskiryhm\u00e4\u00e4, jotka tulosten mukaan ovat keskeisess\u00e4 roolissa ketteriss\u00e4 projekteissa. N\u00e4m\u00e4 riskiryhm\u00e4t liittyv\u00e4t asiakkaan rooliin ja k\u00e4ytt\u00e4j\u00e4kokemukseen, ketter\u00e4n j\u00e4rjestelm\u00e4kehityksen prosesseihin, j\u00e4rjestelm\u00e4vaatimusten laajuuteen ja projektitiimiin. Tapaustutkimus my\u00f6s korostaa kuinka t\u00e4rke\u00e4\u00e4 ketteriss\u00e4 projekteissa on pysty\u00e4 kommunikoimaan j\u00e4rjestelm\u00e4vaatimusten riskeist\u00e4 siten, ett\u00e4 kaikki sidosryhm\u00e4t pystyv\u00e4t niit\u00e4 ymm\u00e4rt\u00e4m\u00e4\u00e4n \u2013 erityisesti asiakas, jonka odotetaan olevan aktiivinen osallistuja projektissa. T\u00e4ss\u00e4 kommunikaatiossa ketter\u00e4t projektit voivat hy\u00f6ty\u00e4 erilaisten ty\u00f6kalujen k\u00e4yt\u00f6st\u00e4, kuten Requirements Risk Prioritization menetelm\u00e4, jota t\u00e4ss\u00e4 tapaustutkimuksessa testattiin\nYleisesti t\u00e4m\u00e4n tutkimuksen tulokset korostavat kuinka j\u00e4rjestelm\u00e4vaatimusten riskien arviointi on haastavaa ketteriss\u00e4 projekteissa erityisesti koska sen tekeminen vaatii laajaa tietoa projektista itsest\u00e4\u00e4n sek\u00e4 sit\u00e4 ymp\u00e4r\u00f6iv\u00e4st\u00e4 organisaatiosta. Henkil\u00f6n tai henkil\u00f6iden, jotka kyseist\u00e4 analyysi\u00e4 tekev\u00e4t t\u00e4ytyy p\u00e4\u00e4st\u00e4 k\u00e4siksi t\u00e4h\u00e4n tietoon. Samaan aikaan ketter\u00e4 prosessi pakottaa analysoijan keskittym\u00e4\u00e4n riskeihin pienemm\u00e4ss\u00e4 laajuudessa kerrallaan kuitenkaan unohtamatta niiden riippuvuuksia projektin kokonaisriskiymp\u00e4rist\u00f6\u00f6n. Vaikka j\u00e4rjestelm\u00e4vaatimusten riskit ovat eritt\u00e4in t\u00e4rkeit\u00e4, niit\u00e4 ei kuitenkaan koskaan voida arvioida ja hallita irrallisena projektin muusta riskikent\u00e4st\u00e4.", "language": "fi", "element": "description", "qualifier": "abstract", "schema": "dc"}, {"key": "dc.description.abstract", "value": "The grown popularity of agile development methods has affected the traditional understanding of requirement management. In these kinds of projects, requirement engineering process needs to adapt to an agile environment where the focus on development is in smaller iterations instead of ready products, changes happen often, and a customer is expected to be highly involved in the process. This naturally effects on requirement related risks that agile projects may face. This Master\u2019s thesis investigates how the requirements risk management is done in agile projects and how selecting an agile development method affects requirement risks.\nThe theoretical part of this study reviews contemporary research literature from the IS field. By combining knowledge from IS development risk management, requirement risk management, and agile development it was possible to summarize some key attributes of requirement risk management in agile projects. In these projects also, requirement risks management needs to adapt to the iterative development cycles and constant changes. This increases the volatility of the requirement risks as well as the need to adjust the scope of the risks assessment to fit the size of the development scope of any given time. Similarly, the prominent role of the customer in agile IS projects emphasize how also the requirements risk management should be transparent and involve, not only the project team but also different project stakeholders.\nThe empirical part of this study further enriches these finding by testing the Requirements Risk Prioritization method in a case study, in an agile project where it was used as a tool to identify and prioritize requirement related risks. The case study revealed how in higher level agile projects face similar risks as projects where more structured methods are used. However, this study identified four other types of risks that seem to play an increasingly important role in the agile projects. These types related to customer\u2019s role or user experience of the system, agile development process itself, requirements scope as well as projects team. The case study also highlights the importance of communication about requirement related risks in a way that it is understandable for all the stakeholder \u2013 especially when the customer is expected to be involved. Lastly, it showcases how agile projects could benefit from having a tool to support this kind of communication.\nResults of this study also show how assessing requirements risks is challenging in agile projects since the people doing that needs to have a wide range of knowledge from the project as well as the organization where it exists. This\nindividual or individuals should have also an access to that information. At the same time the agile process forces them to be able to do a similar assessment for risks on a smaller scale while not still forgetting to consider requirement risks as a part of project\u2019s overall risk environment: No matter how important requirements risks are, those never exist in a vacuum and should not be managed as such.", "language": "en", "element": "description", "qualifier": "abstract", "schema": "dc"}, {"key": "dc.description.provenance", "value": "Submitted by Paivi Vuorio (paelvuor@jyu.fi) on 2018-11-15T07:03:29Z\nNo. of bitstreams: 0", "language": "en", "element": "description", "qualifier": "provenance", "schema": "dc"}, {"key": "dc.description.provenance", "value": "Made available in DSpace on 2018-11-15T07:03:29Z (GMT). No. of bitstreams: 0\n Previous issue date: 2018", "language": "en", "element": "description", "qualifier": "provenance", "schema": "dc"}, {"key": "dc.format.extent", "value": "95", "language": "", "element": "format", "qualifier": "extent", "schema": "dc"}, {"key": "dc.format.mimetype", "value": "application/pdf", "language": null, "element": "format", "qualifier": "mimetype", "schema": "dc"}, {"key": "dc.language.iso", "value": "eng", "language": null, "element": "language", "qualifier": "iso", "schema": "dc"}, {"key": "dc.rights", "value": "In Copyright", "language": "en", "element": "rights", "qualifier": null, "schema": "dc"}, {"key": "dc.subject.other", "value": "requirements risks", "language": "", "element": "subject", "qualifier": "other", "schema": "dc"}, {"key": "dc.title", "value": "Requirements risk management in agile software development projects", "language": "", "element": "title", "qualifier": null, "schema": "dc"}, {"key": "dc.type", "value": "master thesis", "language": null, "element": "type", "qualifier": null, "schema": "dc"}, {"key": "dc.identifier.urn", "value": "URN:NBN:fi:jyu-201811154710", "language": "", "element": "identifier", "qualifier": "urn", "schema": "dc"}, {"key": "dc.type.ontasot", "value": "Pro gradu -tutkielma", "language": "fi", "element": "type", "qualifier": "ontasot", "schema": "dc"}, {"key": "dc.type.ontasot", "value": "Master\u2019s thesis", "language": "en", "element": "type", "qualifier": "ontasot", "schema": "dc"}, {"key": "dc.contributor.faculty", "value": "Informaatioteknologian tiedekunta", "language": "fi", "element": "contributor", "qualifier": "faculty", "schema": "dc"}, {"key": "dc.contributor.faculty", "value": "Faculty of Information Technology", "language": "en", "element": "contributor", "qualifier": "faculty", "schema": "dc"}, {"key": "dc.contributor.department", "value": "Informaatioteknologia", "language": "fi", "element": "contributor", "qualifier": "department", "schema": "dc"}, {"key": "dc.contributor.department", "value": "Information Technology", "language": "en", "element": "contributor", "qualifier": "department", "schema": "dc"}, {"key": "dc.contributor.organization", "value": "Jyv\u00e4skyl\u00e4n yliopisto", "language": "fi", "element": "contributor", "qualifier": "organization", "schema": "dc"}, {"key": "dc.contributor.organization", "value": "University of Jyv\u00e4skyl\u00e4", "language": "en", "element": "contributor", "qualifier": "organization", "schema": "dc"}, {"key": "dc.subject.discipline", "value": "Tietoj\u00e4rjestelm\u00e4tiede", "language": "fi", "element": "subject", "qualifier": "discipline", "schema": "dc"}, {"key": "dc.subject.discipline", "value": "Information Systems Science", "language": "en", "element": "subject", "qualifier": "discipline", "schema": "dc"}, {"key": "yvv.contractresearch.funding", "value": "0", "language": "", "element": "contractresearch", "qualifier": "funding", "schema": "yvv"}, {"key": "dc.type.coar", "value": "http://purl.org/coar/resource_type/c_bdcc", "language": null, "element": "type", "qualifier": "coar", "schema": "dc"}, {"key": "dc.rights.accesslevel", "value": "openAccess", "language": null, "element": "rights", "qualifier": "accesslevel", "schema": "dc"}, {"key": "dc.type.publication", "value": "masterThesis", "language": null, "element": "type", "qualifier": "publication", "schema": "dc"}, {"key": "dc.subject.oppiainekoodi", "value": "601", "language": "", "element": "subject", "qualifier": "oppiainekoodi", "schema": "dc"}, {"key": "dc.subject.yso", "value": "ohjelmistokehitys", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "riskienhallinta", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "kehitt\u00e4misprojektit", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "ketter\u00e4t menetelm\u00e4t", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "vaatimustenhallinta", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "riskinarviointi", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "software development", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "risk management", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "development projects", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "agile methods", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "requirements engineering", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.subject.yso", "value": "risk assessment", "language": null, "element": "subject", "qualifier": "yso", "schema": "dc"}, {"key": "dc.format.content", "value": "fulltext", "language": null, "element": "format", "qualifier": "content", "schema": "dc"}, {"key": "dc.rights.url", "value": "https://rightsstatements.org/page/InC/1.0/", "language": null, "element": "rights", "qualifier": "url", "schema": "dc"}, {"key": "dc.type.okm", "value": "G2", "language": null, "element": "type", "qualifier": "okm", "schema": "dc"}]
|