Otsikon mukainen keskustelunavaus. Eli te, jotka olette tehneet isompia projekteja, millaisilla työkaluilla olette projektit suunnitelleet? etenkin kiinnostaisi projektit joissa on ollut useampi ohjelmoija mukana.
Teoriaa(ei kokemusta):
Ideointi
Suunnitelma(automaatio kaavio tms./yms.)
Työnjako
Toteutus
Ajo
Tähän mennessä olen yleensä lähtenyt sokkona koodaamaan. Jälki on ollut sen mukaista.
Täytyy yrittää muuttaa tapoja.
Ei suunnittelussa ole kyse välineistä vaan suunnittelun tuloksesta. Kirjoita vaikka vessapaperille, jos saat sen pysymään lukukelpoisena ja löydät aina oikean kohdan. Hyvän suunnitelman kirjoittamisessa hiha loppuu ehkä kesken.
Ensin kannattaa suunnitella, mitä oikeastaan tehdään eli millaisia ominaisuuksia suurin piirtein pitäisi olla. Riippuu täysin ohjelmasta, miten helppo tämä vaihe on: Hyötyohjelmalla on selvä tarkoitus, josta pääsee liikkeelle, ja töissä suuren osan hommasta hoitaa pomo tai tilaaja. Esimerkiksi harrastelijan peliohjelmoinnissa kädet taas ovat äärimmäisen vapaat.
Pitää valita kieli, ehkä kirjastot ja ohjelmointityyli (kuten OOP) ja käydä läpi muut perustavanlaatuiset toteutuskysymykset, joita on vaikea jälkikäteen muuttaa.
Ohjelman perusrakenne vaikuttaa projektin aloittamiseen olennaisesti: jos tarkoituksena on tehdä modulaarinen ja helposti mukautettava palapeli, täytyy usein rakentaa melkoisesti enemmän perustuksia kuin yhtenäiselle, kerralla alusta loppuun koodattavalle purukumille. Jos muokkauksen tarvetta koskaan tulee, ensimmäinen tapa alkaa heti maksaa takaisin alussa vaatimaansa vaivaa, mutta toisaalta jos on tarkoitus tehdä nopeasti toimiva ratkaisu yksittäiseen, ehkä väliaikaiseen ongelmaan, jälkimmäinenkin vaihtoehto voi tuntua toimivalta.
Puhun seuraavaksi töissä PHP:llä toteutettavasta, melkoisen mutkikkaasta web-sovelluksesta, joten tekstiä ei voi suoraan soveltaa kaikille ohjelmoinnin aloille.
Projektin perusvaatimukset tulivat aiemman version ja asiakaspalautteen pohjalta. Kokemuksen perusteella lähestymistavaksi valittiin tuo modulaarinen; aiempi huono valinta saattoi osittain olla koko uuden projektin taustalla. ;) Jatkosuunnittelun välineenä on ollut enimmäkseen fläppitaulu (eli hienot kaaviot), parista erityisen hankalasta kohdasta on lisäksi tehty UML-kaavioita ja sanallista dokumentaatiota. Tietokantakaavio on MySQL Workbench -ohjelmassa, joka osaa myös generoida tauluille CREATE-rivit kaikkine vierasavaimineen.
Hyvin valitun lähestymistavan ansiosta suurpiirteinen suunnittelu on riittänyt; kukin suunnittelee sitten omalla tavallaan ne pienemmät moduulit, joita toteuttaa. Joskus tulee pieniä tai suurempia umpikujia, jotka yleensä johtuvat siitä, että keksitään uusia ominaisuuksia, jotka eivät suoraan istu aiempaan koodiin. Useimmat ratkaisut eivät kuitenkaan ole rajoittaneet jatkovaihtoehtoja merkittävästi, eli joko ne ovat osuneet nappiin tai niillä ei tosiaan ole ollut suurta merkitystä. :)
Kynällä ja paperilla on hyvä aloittaa ja näillä pääsee myös aika pitkälle.
Suunnittelu ei ehkä ole se ohjelmistoprojektin osa, jossa ensimmäisenä tarvitaan hienostuneita työkaluja. Huomattavasti enemmän hyötyä pienissä ja vähän isommissakin projekteissa on mielestäni esimerkiksi testaustyökaluista. Vastaukseen tietenkin vaikuttaa myös se, mikä kaikki mielletään suunnitteluksi ja kaikenmoista kikkaretta on kyllä tarjolla:
http://en.wikipedia.org/wiki/Computer-Aided_Software_Engineering
"Suunnittelen" projektini matkimalla ammattilaisten tekeleitä. ^^
Tässä yksi malli tosielämästä, jossa tavoitteena tehdä ylläpidettävä tuote, ei yksitttäistä projektia
1. Business vaatimukset määrittävät ohjenuorat, jotka ohjaavat SW-projektia
* esim modulaarisuus, päivitettävyys, toimintavarmuuus
2. Asiakasvaatimukset määrittävät ohjelmiston toiminnan
----
3. Vaatimusten pohjalta suunnitellaan ohjelmistoarkkkitehtuuri
4. Vaatimusten pohjalta luodaan SW:n toiminnallinen ylemmän tason kuvaus (sanallista + kuvallista helppotajuista)
5. Toimminnallisen kuvauksen pohjalta suunnitellaan SW (esim. UML)
----
6. Koodaus (< 20% koko projektista)
7. Testaus
Räätälöity rankalla kädellä V-mallista omiin tarpeisiin :)
20 % koodausta kuulostaa erittäin vähältä. :o Riippuu toki, miten tarkka tuo sanallinen suunnitelma on; jos se käsittää esimerkiksi jokaisen funktion tarkan kuvauksen, minusta suuri osa koodaustyöstä on jo siinä tehty.
ajv kirjoitti:
...toimintavarmuus...
Ihan uteliaisuudesta: keksitkö jonkin tapauksen, jossa tämä ei kuuluisi (ammattilais)projektin vaatimuksiin? :)
No joo, ehkä tuota on vähän vaikea yleistää. Tottakai ohjelmiston kuin ohjelmiston tarvitsee toimia varmasti, mutta jos sillä ohjataan konetta, joka voi aiheuttaa vaaratilanteen tai jopa ihmishengen vaarantumisen, niin silloin nuo toimintavarmuuden vaatimukset tulevat ihan lakipykälistä ja ovat ehkä erilaiset, kuin "tavallisessa" hyötyohjelmassa. Ehkä myös pankkisovelluksissa on korkeammmat toimintavarmuusvaatimukset kuin esim. jossain piirrustusohjelmissa - tämäkin riippuu varmaan ihan firmasta :)
Oletetaan, että ollaan tekemässä järjestelmää ihmisten käytettäväksi ja sillä tulee olemaan käyttöliittymä (muussa tapauksessa seuraava kappale vaatii muutoksia).
Selvitetään, mikä on ratkaistava ongelma ja suunnitellaan siihen ratkaisu. Tämän hoidan aivan projektin alussa tekemällä käyttäjätarkkailuja ja -haastatteluja. Niiden perusteella kerättyjen käyttötilanteiden perusteella suunnitellaan käyttöliittymäratkaisun paperiprototyyppi. Tätä protoa sitten testataan käyttäjien kanssa ja ilman heitä. Viikon tai parin jälkeen, kun suunnitelmat ovat ~85% valmiita, edetään tekniseen toteutukseen. Loput 15% täsmentyvät ohjelman toteutuksen myötä, kun ohjelmaa päästään käyttämään, mutta mitään suuria muutoksia ei ole odotettavissa.
Teknisessä toteutuksessa mietitään ensin, että millä ympäristöllä ja kielillä systeemi kannattaa toteuttaa. Kun ne on valittu, niin mietitään toteutusjärjestys ja järjestelmän yleinen rakenne paperilla tai valkotaululla, jonka jälkeen ryhdytään kirjoittamaan koodia (ohjelmointi on suunnittelua http://www.developerdotstar.com/mag/articles/
Elikkä yhteenvetona suunniteluvälineet ovat: paperi, kynä ja ohjelmakoodi.
Lupaa kaikki mitä asiakas pyytää.
Aliarvioi työn määrä.
Aliarvioi budjetti vielä reilummin.
Aloita tukiorganisaatio muutos.
Lopuksi ihmettele, miksi deadline paukkuu.
Potki pois koodareita, palkkaa lisää myyjiä. Goto alku...
keksi jotain hämärää
luonnostele ideoita paperille tekstin ja omituisten kuvien avulla
et käsitä kryptisestä paperista aamulla yhtään mitään
tai
alat toteuttaa koodia sen kummemmin miettimättä puhtaalle tekstinkäsittelyohjelman ikkunalle, jolloin
keskeytät projektin tylsistyttyäsi tai menetettyäsi mielenkiinnon
tai
saat projektin valmiiksi
Kiitos vinkeistä ja ajatuksista. Auttoi hyvin kartottamaan omien menetelmien tehokkuutta kun on jotain mihin vertaa. Itse olen tähän mennessä kirjoittanut ohjelman suunnitelman paperille, jos ei ole ollut kone lähellä. Sitten, tosin pisimmät projektit kestäneet kaikki alle viikon, joten suurempia suunnitelmia ei ole tarvittu. Lisäksi nämä aikaisemmat projektit ovat olleet vähemmän modulaarisia. Nyt aloittelen hieman pidempää projektia. Näistä avuista kiitokset.
Ohjelmistoprojektin toteutuksesta taitaa olla yhtä monta mielipidettä kuin on tekijääkin. Menetelmissä on vähän sama kuin ohjelmointikielissä, toinen sopii paremmin toiseen ja toinen toiseen. Mutta lyhyesti...
Ideoinnin voi aloittaa kirjoittamalla paperille/tiedostoon vapaata kuvausta mitä ohjelma tekee ja mitä siltä haluaa. Kuvauksen tarkoitukena on vain tallettaa ideat ohjelman toiminnasta, jotteivät ne unohdu ennen tarkempaa suunnittelua. Porukalla ideointiin hyvä apuväline on fläppitaulu/liitutaulu ja joku mindstorm-kaavio tyyppinen piirrustelu. Ideoinnin dokumentointiin työkaluna on hyvä käyttää jotain uml-kaavio ohjelmaa.
Suunnittelu, toteutus, testaus, Valitse kunnollinen IDE-ympäristö joka sisältää työkalut näihin. Eli ainakin UML-kaavio ohjelmisto, (kääntäjä), version hallinta, automaattinen testaus, bugi-raportointi.
Edellisiin voi käyttää esim netbeans IDE:ä tai eclipse:ä. Netbeans on ammattilaistasoinen kehitysympäristö, eclipse voi tarvita säätöä.
Jos et uml-mallinnusta hallitse ja teet harrastelija pohjalta niin kiinnitä kumminkin huomiota versionhallintaan ja bugi-raportointiin. Versionhallinta takaa että homma pysyy kasassa (vaikka on monta tekijää) ja hallittu bugi-raporointi auttaa korjaaman virheet järjestelmällisesti. Bugi-raportoinnissa voi käyttää vaikkapa bugzillaa.
Automaattinen testaus vaatii jonkin verran opettelua, jos sitä ei ennestään osaa, mutta suuressa projektissa testauksen automatisointi on melkein välttämätön, säästää paljon aikaa kun ei tarvitse aina käsin kaikkea testata esim uuden/korjatun komponentin lisäyksen yhteydessä.
Ja vähäisinpänä mainittakoon projektin aikataulunsuunnittelu. Ohjelmistona voi käyttää esim openoffice:a ja gantt chart -pakettia (jos ei muuta vastaavaa löydy). Aikataulu kannattaa laatia huolellisesti, jotta se pitää paikkansa eikä projekti myöhästy aiotusta ;)
K_L kirjoitti:
Lupaa kaikki mitä asiakas pyytää.
Aliarvioi työn määrä.
Aliarvioi budjetti vielä reilummin.
Aloita tukiorganisaatio muutos.
Lopuksi ihmettele, miksi deadline paukkuu.
Potki pois koodareita, palkkaa lisää myyjiä. Goto alku...
Kiitos tuottamastasi nostalgiasta :D
Aihe on jo aika vanha, joten et voi enää vastata siihen.