Ohjelmointi projektin hallinta?

Aluksi suunnittelen paperille mitä kaikkia muuttujia ja funktiota ohjelmaan tulisi... Tunnin päästä alan koodaamaan ja lappu kulkeutuu roskiin.

Jos tekis kunnon sunnitelman, niin se kyllä auttaisi huomattavasti projektin hallintaa. Varsinkin tollanen vähän isompi homma tuppaa välillä karkaamaan lapasesta.

Suunnittelu on a ja o. Silti jotkut tekevät vielä töissäkin jopa koodin ensin ja sitten vasta suunnittelun.

Vaikka UML:llä suunnittelee luokat, luokkakaaviot, luokkakuvaukset, atribuutit, relaatiotaulut, normalisoinnit, metodit, viestiyhteistyö -kaaviot, käyttötapauskuvaukset yms.

Noiden suunnittelujen pohjalta voi sitten tehä koodin aika nopeesti. Tosin noin laajaan suunnitteluun meneekin sitten jo aika paljon aikaakin.

Itselläni paha tapa lähteää pienestä liikkeelle.
ja sitten niitä ominaisuuksia alkaakin tulla mieleen joita olisi hyvä toteuttaa ja pian ohjelma onkin paisunut melkoisen isoksi.

Itse olen tehnyt menestyksekkäästi yli viikon kestäviä projekteja (pari peliä yms.). Kaiken A ja O on -- ainakin kun kielenä on Java tai C -- suunnitella luokat ja niiden rajapinnat (funktiot ja julkiset muuttujat) kunnolla. Mistään UML- yms- kaavioista en ole koskaan oikeasti hyötynyt.

Käytännössä omalla kohdallani valmiissa, isossa ohjelmassa on monta luokkaa, joilla on niin yksinkertaiset rajapinnat, ettei niiden sisältöä muita luokkia koodaillessa tarvitse miettiä, sekä niiden lisäksi kaksi luokkaa/tiedostoa, jotka kontrolloi kokonaisuutta. Ensimmäinen kontrolloiva tiedosto käyttöjärjestelmäpalveluiden ja toisen kontorollitiedoston välille, toinen kaiken muun hoitamiseen.

Onko muilla samaa tai parempaa strategiaa? :)

1. Ensin lähdetään liikkeelle siitä, mitä se ohjelma voisi tehdä (vaatimukset). Sitten heitetään roskiin ne piirteet, joita ei toteuteta ja täsmennetään, mitä tarkoitetaan niillä piirteillä, jotka toteutetaan. Eli jos ohjelma tekee esimerkiksi oikolukua niin täsmennetään, mitä se osaa oikolukea (ja mitä ei).

Millä testitapauksilla testataan ohjelman toimivuus?

2. Vasta tuon jälkeen lähdetään suunnittelemaan ohjelmaa. Mietitään millainen rakenne on luonteva ohjelmalle. Ei liian köyhä eikä toisaalta rönsyile liikaa sellaisiin ominaisuuksiin, mitä ohjelma ei käytä.

Mikä on ohjelman toteutusjärjestys?

Ohjelman rakenteen pitää myös tukea testattavuutta ja jäljitettävyyttä. Kas kun kaikkiin oikeisiin ohjelmiin jää virheitä. Sitten kun posahtaa niin pitää löytää reiän kohta helposti ja nopeasti.

3. Testataan ja korjataan. Joskus tehdään testiohjelmia testausta varten.

4. Palataan kohtaan 1. kun ollaan viisastuttu ohjelmaa tehtäessä.

0. Mitään noista vaiheista ei tehdä oikeassa ohjelmistokehitysympäristössä yksin vaan aina vähintään yksi tekee ja toinen syynää kussakin vaiheessa. Mitä vaativampi ympäristö niin sitä useampi syynää. Joskus on ollut 3 tekijää ja 15 selvittämässä, mitä pitää tehdä.

Myöskään koko putkea ei pidä antaa yhden jepen tehtäväksi, kun se johtaa optimistiseen näkemykseen projektin aikataulusta ja laadusta.