Analyysi. Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien.

Slides:



Advertisements
Samankaltaiset esitykset
MBLiq Multibase Oy. Multibase Oy / 2006 / Pihlajatie 19, Helsinki puh: MBLiq – prosesseihin integroituva • MBLiq kattaa kaikki likviditeetin.
Advertisements

Case: UNIC-Services Oy. UNIC-Services Oy  Perustettu 1993, perustaja Saara Remes- Ulkunniemi  Yritys tarjoaa koulutuspaveluita eri puolilla Suomea 
Suunnitelma ohjelmiston testaukseen
S ysteemianalyysin Laboratorio Teknillinen korkeakoulu Kimmo Berg Optimointiopin seminaari - Kevät 2005 / 1 Sähköinen kaupankäynti Kimmo Berg.
Tietojärjestelmät ja Systeemisuunnittelu
4. Vaatimusten hallinta Ohjelmistotuotantoprosessin tavoitteena
Tietokannan suunnittelu
Tekninen suunnit-telu
Ohjelmiston elinkaarimallit
Tietojärjestelmän suunnittelu
Performance testing of TETRA 1. SISÄLTÖ  TETRA standardointi  ICT- yrityksen toteutus  Testaus- prosessi  Motivaatio testaukseen  Vaiheet/ osa-prosessit.
S Tiedonsiirto ja yhteyskäytännöt tietoliikenteen perusasioita top-down -lähestymistapa ohjelmistotekniikan näkökulma tavoitteena toimivat sovellukset.
Systemaattisen käyttöliittymäsuunnittelun tuottamien vaatimusten erot alkuperäisiin vaatimusmäärittelyn vaatimuksiin verrattuna Ville Nordberg,
Olioperustainen ohjelmistoprosessi
3. Spesifikaatioiden laatiminen
Oliosuunnittelu.
Suunnittelu.
Pro gradu -tutkielmat ohjelmistotestauksesta
XML -kielen perusteet SIMO Seminaari Antti Mäkinen.
Ohjelmistojen suunnittelumenetelmät ja –työkalut
Selainkäyttöliittymän tuotantoprosessi Klikkaamalla pääotsikoista tietosi karttuu. Sininen mökki toimii paluupainikkeena. Selainkäyttöliittymän tuotantoprosessi.
Oleelliset vaikeudet OT:ssa 1/2
Ohjelmistotekniikka ja projektinhallinta, 4 op
Tutkimussuunnitelman ja opinnäytetyön rakenne
JHS:N SUOSITUKSET VAATIMUSMÄÄRITTELYLLE SEPPO RÄSÄNEN SAVONIA-AMMATTIKORKEAKOULU TERVEYSALA, KUOPIO Ohjelmistotekniikka ja projektinhallinta,
Esitutkimus (tarvekartoitus)
Heikki Salokanto Valvoja: prof. Jukka Manner Ohjaaja: DI Pekka Pajuoja, TEKES Sovelluskehitysympäristön virtualisoinnin tuomat edut ja haitat.
KULTTUURIYMPÄRISTÖN PALASISTA KOKONAISUUDEKSI Maakuntamuseoiden teemapäivät Jyväskylä 20. – MUSEOVIRASTO Elisa El Harouny
Oppimisfoorumi Tilanne AKTIVA ▲ Hyria Koulutus Oy ▲ VirtuaaliAMK.
Merlinin ylläpito-organisaatio Asiakaspalvelu (help desk) Palvelukeskus (tuotanto)
HAJAUTTAMISEN IDEAA SEPPO RÄSÄNEN SAVONIA-AMMATTIKORKEAKOULU TERVEYSALA, KUOPIO Ohjelmistotekniikka ja projektinhallinta, 4 op.
5.2 Suunnittelu/jatkuu Käsikirjoitukset -Asiakäsik. -Tuotantokäsik. Suunnittelu -Laajuus -Tyyli / lay-out - Mediavalinta.
Ohjelmistotuotanto.
T Loppudemo Kaffetauko eAuction
T Loppukatselmus OtaShop2 Halme, Inkinen, Karanko, Kosunen, Kärkkäinen, Larmo, Ojanen.
Johdanto Teppo Räisänen, Principal Lecturer Oulu University of Applied Sciences, School of Business and Information Management
Vaatimusten ja käyttöliittymäratkaisujen suhde nykyisessä vaatimusmäärittelyssä ja kuinka prosessia voisi kehittää Marju Kettunen, Seminaari:
Uudelleenkäyttö. Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim.
SerAPI-Potilaslista osa I: Alustus , Kuopio Juha Mykkänen, Marko Sormunen, Assi Pöyhölä, Hannu Virkanen.
– Ohjelmistojen mallintaminen, mallintaminen ja UML.
Jouni Juntunen Oulun seudun ammattikorkeakoulu Liiketalouden yksikkö
Verkkojulkaisuprojekti – osa 1 Teppo Räisänen
Vaatimustenhallinta.
Tik Tietojenkäsittelyopin ohjelmatyö Palautuspalaveri 1 Projektin esittely lyhyesti Projektin tilanne Vaiheen lopputulokset Seuraavan vaiheen (MÄ)
Pakkanen * * * Komponenttipohjaisen sovellustuotannon menetelmäpilotti PlugIT-seminaari Annamari Riekkinen ja Kirsi Karvinen FixIT-DoIT / HIS-tutkimusyksikkö.
T Projektikatselmus Ampel Projektisuunnitteluvaihe (Versio 1.0)
Ohjelmistotekniikka kevät 2003 CASE-välineet. Ohjelmistotekniikka kevät 2003 Mitä ovat CASE-välineet? Computer Aided Software Engineering Tietokoneavusteinen.
Ohjelmistotekniikka - Määrittely (Analysis) Kevät 2003 Hanna-Kaisa Lammi LTY/Tite.
Ohjelmistotekniikka - Vaatimustenhallinta, osa 2 Kevät 2003 Hanna-Kaisa Lammi LTY/Tite.
Ohjelmistotekniikka - Vaatimustenhallinta Kevät 2003 Hanna-Kaisa Lammi LTY/Tite.
Ohjelmistotekniikka ja projektinhallinta, 4 op
Tietojärjestelmät ja Systeemisuunnittelu
Ohjelmistotekniikka kevät 2003 Ohjelmistotekniikan määritelmä Ohjelmistotekniikka (Software Engineering) tarkoittaa pätevien insinööriperiaatteiden vakiinnuttamista.
Ohjelmistotekniikka Vaatimustenhallinta Kevät 2002 Päivi Ovaska LTKK/Tite.
Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.3.
Uudet palvelut (räätälöity): Tomin kommentit Painopiste on kuvassa mielestäni huono, tässä vaiheessa ja tätä ennen pitää panostaa eniten Jos näissä vaiheissa.
GISBLOOM hanke. Missä olemme Tavoitteet: asiakkaiden - vesienhoidon sidosryhmien/paikallistason/toteuttajien tietotarpeiden tyydyttäminen – valmiuksien.
Kurssin aihepiiri: ohjelmistotuotannon alkeita ● [wikipedia]: – Ohjelmistotuotanto on yhteisnimitys niille työnteon ja työnjohdon menetelmille, joita käytetään,
Kansallinen palveluväylä PERTIVA-kokous
Työkaluja tehtävien tueksi
Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4
Ohjelmistotekniikan menetelmät, Johdatus ohjelmistotuotantoon
THL - Eurykleia Henkilöstö- ja talousasioiden suunnittelu- ja raportointijärjestelmän määrittely TP 1 agenda Ongelman kuvaus, tavoitteet, rajaukset,
Vaatimusmäärittely kehitysprosessissa
Ohjelmistotekniikan menetelmät, Johdatus ohjelmistotuotantoon
Vaatimusanalyysin hallintatyökalu
PSK Kevätseminaari 2013 Risto Koivunen
Video 4: Avoimen ja yhteisen rajapinnan hallintasuunnitelma
Avainresurssit ja kyvykkyydet
– Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon
Esityksen transkriptio:

Analyysi

Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla

Tietojärjestelmän osat Laitteisto Tietokannat Dokumentit Ihmiset Toiminta- ja käyttösäännöt Huomioitava jokaisen osan vaatimukset ja rajoitukset!

Järjestelmän hahmottaminen 1/2 1.Asiakkaan tarpeiden yleinen kartoitus 2.Soveltuvuustutkimus Kustannus – hyöty Teknologian saatavuus/järkevyys Tietosuoja Tuotantovaihtoehdot (alihankinta) 3.Kustannus- ja aikarajoitteet 4.Kaupallinen ja tekninen analyysi Potentiaaliset asiakkaat/käyttäjät Laite- ja sovellusympäristö

Järjestelmän hahmottaminen 2/2 5.Järjestelmän jako komponenteiksi Laitteisto Ohjelmisto Tietokannat Inhimilliset tekijät (käyttäjät) -> Mitä osia täytyy uusia? -> Mitä rajoituksia olemassa olevat osat tuovat? -> Kuinka suuri osa järjestelmästä on yleensä tarpeen automatisoida? (esim. integrointitilanteet)

Ohjelmiston vaatimukset 1.Vaatimusmäärittely –Ongelmallisin osa ohjelmistotuotantoprosessia 2.Vaatimusten hallinta –Täytyy olla systemaattista

Kustannusarvioinnin vaikeus 1.Toistuvat vaatimusten muutokset 2.Puuttuvat vaatimukset 3.Riittämätön kommunikointi käyttäjien kanssa 4.Vaatimusten heikko spesifiointi 5.Riittämätön analyysi Kustannusarvio on helpompi laatia vaatimusten jälkeen!

Vaatimusanalyysi - Vaatimusten luokittelu Toiminnalliset vaatimukset –Mitä toimintoja vaaditaan? Ei-toiminnalliset vaatimukset –Suorituskyky- ja reaaliaikavaatimukset –Luotettavuus –Tietoturva –Siirrettävyys Rajoitteet –Hinta ja aikataulu –Lainsäädäntö ja standardit –Työkalut, menetelmät ja tyyliseikat (värit) –Lopputuotoksen esim. dokumentaation määrittely –(Oikeuksista sopiminen)

Vaatimusanalyysin vaiheet 1.Ongelman hahmottaminen. Ohjelmiston rooli järjestelmässä ja rajapinnat. Haastatellaan asiakasta. 2.Tuotteen hahmottaminen. Tieto, toiminnot, rajoitteet, liitännät. 3.Mallinnus pääkomponenttitasolla. Tietosisältö ja ulkoiset rajapinnat. 4.Määrittely 5.Katselmus asiakkaan kanssa. Parantelu.

Erilaiset dokumentit eri tarkoituksiin (Sommerville 1995) Requirements definition –Mitä järjestelmältä odotetaan? Rajoitukset? –Asiakkaalta saatavan informaation pohjalta –Johtajalle ymmärrettävällä abstraktiotasolla Requirements specification –Kuvaa tarkasti toiminnot –Muut asiat, jotka ovat asiakkaalle oleellisia –Voi toimia sopimuksena Software specification –Lisää yksityiskohtia –Tarkoitettu suunnittelun pohjaksi

Vaatimusprosessi (Sommerville 1995) Feasibility study Requirements analysis Requirements definition Requirements specificationc Feasibility report System models Requirements document Definition of requirements Specification of requirements Software Specification validointi

Vaatimusten validointi Oikeellisuus –Tarkempi analyysi saattaa muuttaa vaatimuksia Yhtenäisyys –Ei ristiriitoja Täydellisyys –Toiminnot ja rajoitteet Realistisuus –Toiminnallisuus, rajoitukset ja kustannukset

Vaatimusanalyysiprosessi (Sommerville 1995) 1.Toimialan ymmärtäminen (esim. marketti) 2.Vaatimusten keräys (arvioidaanko infolähteet?) 3.Luokittelu 4.Ristiriitojen ratkaisu (laitteisto ei jousta) 5.Priorisointi 6.Vaatimusten validointi

CASE: pankkijärjestelmä Järjestelmä Asiakkaat Automaatti, netti Muut pankit Transaktion peruutus Johtajat Statistiikka Asiakaspalvelu Tietokantavastaava Integrointi Tietoturvavastaava Markkinointi Kilpailu Ylläpito Laitteisto ja ohjelmisto Top-down –lähestymistapa ei onnistu!

Vaatimusdokumentin rakenne 1/2 1.Johdanto 1.1 Järjestelmän kuvaus: ohjelmisto, laitteisto, tieto ihmiset 1.2 Yleiskuvaus (sanallinen kuvaus ohjelmistosta, liitännöistä) 1.3 Ohjelmistoprojektin rajoitukset (raha, aika) 2.Tietosisällön kuvaus 2.1 Tietovuo (datan kulku) 2.2 Kontrollivuo (sisäinen suorituslogiikka) 2.3 Tiedon sisältö, merkitys ja muoto 3.Toimintokuvaus 3.1 Ohjelmiston rakenne 3.2 Rajoitukset käytölle 3.3 Suorituskykyvaatimukset 3.4 Kaaviot (rakenne, liitännät)

Vaatimusdokumentin rakenne 2/2 4.Dynaamisen käyttäytymisen kuvaus 4.1 Järjestelmän tilat 4.2 Herätteet ja toiminnot (reagointi ulkoisiin toimintapyyntöihin) 5.Validointimenettely 5.1 Suorituskykyvaatimukset Ohjelmiston toiminnan testaus Ohjelmiston tuottamat tuotokset Viiteluettelo (liittyvät dokumentit, standardit yms.) Liitteet

Vaatimusmäärittelyn ongelmat Ohjelmisto on aina uusi -> ei ole valmista täydellistä mallia vaatimusmäärittelylle Käyttäjien tarpeet hyvin vaihtelevia Asiakas on usein eri kuin käyttäjä Asiakas ei osaa määritellä tarpeitaan tarpeeksi yksityiskohtaisesti ja teknisesti (tai omalla kielellä) Asiakas on liian urautunut vanhaan toimintamalliin Tuottaja ei tunne sovellusaluetta tarpeeksi Asiakas kiinnittää liiaksi toteutusta Tuottaja pyrkii vaikuttamaan liiaksi vaatimuksiin

Vaatimusmuutosten ongelmat Kaikki asiakasvaatimuksia ei ymmärretä oikein aluksi Asiakasvaatimuksia jää huomaamatta Muutokset toimintaympäristössä (tavat, laitteistot) Jotkut vaatimukset osoittautuvat mahdottomiksi ja käyttökelvottomiksi Aikataulupaine -> ominaisuuksia jää toteuttamatta Kilpailijalta uusi tuote -> lisätään vaatimuksia Projektin alkuvaiheessa tehdään epäonnistuneita teknologiavalintoja