Hur gör ni när ni ska starta ett projekt? Börjar ni med att specificera vilka klasser ni ska använda och relationer mellan klasserna. Brukar ni alls specificera klasser eller får det ge sig efterhand?

Ska man ha databaser är det väl en bra idé att skissa upp tabeller och relationer mellan tabellerna.

Är det inte bra att börja med att prata med användaren. Ta reda på vad det efterfrågar och behöver.
Typ en kravanalys?

Tja, skulle väl vara en bra början, men sedan. När man fått veta kraven, brukar man då börja koda direkt, eller skissa man först upp ett klassdiagram eller liknande?

Det kan nog vara bra att utgå från. Men tro inte från att diagrammet kommer att gälla under hela utvecklingen. Det kommer säkerligen att ändras senare när du har fått ökat förståelse för önskemålen, hur "domänen" fungerar och efter att du har stött på problem.

Anledningen till att jag frågar är att jag verkligen skulle vilja veta hur det brukar gå till. Har aldrig utvecklat ett projekt från början utanför skolmiljön.

Det här är en väldigt generell fråga. Det du beskriver är ju i stora drag vattenfallsmodellen; något som i 20 år ansetts vara "på väg ut", men som fortfarande by far är det vanligaste;
-försök förstå problemet ("förstudie")
-gör en plan (kravspec, dokument), som användaren får kolla på.
-omvandla planen till en mer formell plan (klassdiagram, flödesscheman etc.)
-implementera planen
-testa implementationen
-leverera

Finns mycket problem med det sättet att jobba, kolla på XP, Agile, etc. för att få lite annan syn på det.

Som ett enkelt exempel kan man helt enkelt säga att med många alternativa sätt att arbeta går man ifrån komplicerade och stora dokument, och istället börjar skriva små grejer, testar om användaren tycker att de är bra, och efter hand sätta ihop alltihop till ett system där alla delar fungerar som användaren vill ha dem.

Klassdiagram och flödesscheman är i mitt tycke starkt överskattade. Man måste arbeta med själva koden för att se hur grejerna fungerar. Man kan göra upp såna dokument i efterhand (och det är dessutom ganska vanligt).

"Klassdiagram och flödesscheman är i mitt tycke starkt överskattade. Man måste arbeta med själva koden för att se hur grejerna fungerar. Man kan göra upp såna dokument i efterhand (och det är dessutom ganska vanligt)."

Det var ju precis detta jag undrade över, hur man gör nuförtiden. D.v.s. gör man upp klassdiagram o.d. i förväg och sedan börjar koda eller gör man som du skriver.

De flesta svaren här tyder på att ni anser att jag föreslår en modell och frågar om den är bra. Det är inte alls fallet. Det jag ville veta är hur man gör nuförtiden när man skapar projekt, kanske framförallt i något mindre firmor.

Vad man gör är att man arbetar med den gammaldagsa vattenfallsmodellen; gör kravspec, uppfyller den, och levererar. Oavsett vad folk säger är det i absolut majoritet (helt enkelt eftersom det är standardprinciper i andra sammanhang, ska du tillverka något i en fabrik skickar du ritningarna och förväntar dig att få tillbaka en vara).

Det är vad man förmodligen lär sig var man än är. Försök förstå problemet, kom överens om vad man ska göra och gör det. Det är vad jag och många med mig får dras med.

Det är alltså vad majoriteten gör. Vad man <b>bör</b> göra är en helt annan fråga. Och det är "inne" att inte arbeta så här, personligen är jag av åsikten att det också är vettigt att försöka hitta andra sätt att arbeta på. Men det är inte speciellt vanligt. Så frågan du ska ställa dig är väl snarare, vill du hitta bra sätt att arbeta på eller vanliga sätt att arbeta på?