Jag börjar med att be om ursäkt för den här tråden. Jag vet att det är svårt att svara på "hur långt är ett snöre" är! :)

Men vad jag undrar är alltså vad det skulle kosta att köpa grunden till ett community. Vi tar nightlife.se som exempel. Tänk er den sidan (eller en sida av samma kvalité) fast med endast ett 10 tal bloggar, kanske 50 användare och några artiklar. Vad skulle man kunna tänka sig för pris: 10k, 20k, 50k, 80k, 100k ... någon som har en uppfattning?

Vad skulle ett sådant community kosta att koda från scratsch?

Beror på vem som gör det. Jag skulle kanske utan att veta exakt kravspec. kunna tänka mej att göra något liknande för en 10000kr. Sen finns det dem som gör billigare och dem som gör det för mer pengar. Så vem vill du ska skriva koden? Och när du vet det kan du fråga dem.

Well, med prototyp, design, utbildning, front-end, back-end, betalsystem, bokföringskoppling, specialfunktioner för liknande community? Byggt i t.ex. Zend/mysql

Grovt uppskattad tid (minst) ca 600 timmar x 950 kr/h = 570 000 kr

Men för 50 användare så skulle jag nog göra ett vääldigt förenklat system eller helst använda ett färdigt.

Eller Indien, ca 600 timmar x 100 kr/h = ca 60 000

Jag måste nog förtydliga mig lite. Editerar första posten..

Jo, men då ska man ha sjukt bra kompetens att jobba med utlandet eller via en webbyrå. Jag har arbetat med indien/kina och visst fungerar det bra om man själv vet vad man vill ha och kan väldigt mycket, och inte ber om komplexa applikationer. Det fungerar säkerligen i vissa fall men jag ser det som en mycket stor utmaning. Jag använder en mycket kompetent Kines för xhtml-kodning t.ex. och det fungerar finfint.

Haha, nej jag var inte nog snabb för att editera. Här kommer det som jag borde skrivit :)

Jag börjar med att be om ursäkt för den här tråden. Jag vet att det är svårt att svara på "hur långt är ett snöre" är! :)

Men vad jag undrar är alltså vad det skulle kosta att köpa grunden till ett community.

Antingen ett ungt community som precis börjat få medlemmar:

Vi tar nightlife.se som exempel. Tänk er den sidan (eller en sida av samma kvalité) fast som endast hunnit få ett 10 tal bloggar, kanske 50 användare och några artiklar. Vad skulle man kunna tänka sig för pris: 10k, 20k, 50k, 80k, 100k ... någon som har en uppfattning?


Eller bara koden & designen:

Vad skulle ett sådant community kosta att koda från scratsch?

Om vi tar bort betalsystem & bokföringskoppling?

Beror så klart på ambitionsnivån och hur det ska kunna växa... Det är ju stor skillnad om du anlitar någon som gjort ett community förut eller om du använder en "hobbysnickare".

Om du t.ex. använder starcommunity som jag har för mig har skapat resedagboken och Handelshögskolan i Sthml:s community (välgjort säger studenterna iaf) så tror jag startavgiften ligger där någonstans på 500 000 kr.... men är osäker i dagsläget. (http://netstarcommunity.com/)

Ett krux är ju att du hela tiden måste utveckla sajten, och ett community blir snabbt komplext. Så en anställd programmerare är nog ett krav, iaf om det ska blir något stort.

Tack för alla snabba svar!

Om det är någon som kan peka på ett community och säga vad det kostade att koda & designa så vore det mycket intressant, speciellt om det ligger i prisintervallet 10k-50k kr.

Har ni andra tips, trix eller saker man ska tänka på när man kör igång en community så skriv gärna dem här.

Jag gillar din beskrivning i din signatur Martin, men jag måste fråga vem är beställaren av den siten ?
Är det Antipiratbyrån eller polismyndigheten hehe.

Om du verkligen har den siten så kan du ju bygga upp en nice utpressningsdatabas om den används väl.

Lycka till med ditt projekt och om någon vet priset för att fixa ett forum ungefär som WN så kan ni skicka mig ett PM för det kan komma på tal för en intresseförening att lägga upp ett liknande och jag sitter med i styrelsen och proklamerar starkt för en sådan resursfördelning.

Ber om ursäkt för att jag lånade din tråd lite Martin.

Att utveckla från scratch kostar säkert minst 0,5 MSEK (troligen det dubbla) som Micke04 skriver. Har du en budget på 50 kSEK så kan du lägga ned projektet på en gång och spara pengarna.

Har du däremot tänkt köpa ett färdigt system, så kanske 50-100 kSEK räcker en bit. Men då får du ta systemdesignen som det står och går så att säga och det kanske inte var meningen att lancera en kopia av 100-tals andra webbplatser.

Eftersom det är omöjligt att göra en seriös tidsuppskattning när man inte har en konkret kravspec att bedöma och räkna på så får mitt bidrag bli en mycket grov tillyxning utifrån min egen erfarenhet.

Även om man lägger ut själva kodandet i indien så måste kravspecen skrivas av beställaren på ett eller annat sätt. Det kostar ca 120-320 timmar (3-8 veckors jobb). Även förhandling och avtal med outsourcing företaget tar kanske 2-3 veckor.

Verksamhetskrav kanske 3-8 veckor, förhandling och avtal med outsourcing företaget tar kanske 2-3 veckor, systemanalys och systemdesign 6-12 veckorkodning tar, kodningen tar kanske ca 4-8 veckor , systemtestning tar minst 3 veckor. dvs 18-34 veckor

Till detta kommer projektledning, bemanning m.m. med ca 2-4 veckor.

En totalkostnad skulle kunna landa på mellan 20-38 veckor dvs 600-1520 timmar beroende på ambitionsnivå, arkitektur, utvecklingsverktyg, bemanning och brådska.

Verksamhetskraven ovan förutsätter att du har ganska klart för dig exakt vaddu vill ha för funktionalitet, annars måste man göra en verksamhetsanalys elelr förstudie som blir ytterligare några veckors jobb.

Ytterligare faktorer som kan påverka mycket är om man behöver göra användbarhetstester och analyser av användarnas betéende.

Tänk oxo på att indierna inte kan svenska särskilt bra så om webbsiten ska vara svensk- eller multispråkig så har du ytterligare en komplikation.

Sen tillkommer

Kravanalys
Projektledning
Tester
Systemdokumentation

Och eftersom typ 70% av alla it-projekt drar över tider alt inte håller budget, kan det vara bra att räkna med lite till.

Haha, nej det här är ett annat projekt! Tyvärr sparade jag inte databasen från piratminiräknaren. :)

Återigen, tack för alla svar!

Här kommer en fråga som många säkert inte kommer tycka om.

När man beställer sin hemsida, fungerar det att man i kravspec'en skriver "gör en fullständig funktion- & strukturuppbyggnads kopia av den här siten"?

Så man sparar in tiden det skulle ta att göra en kravspec. Det måste ju också vara lättare för programmerarna när dom har en sida som dom kan gå in och se hur den fungerar.

Jag menar inte att man ska kopiera den grafiskadesignen.. men att i övrigt göra en kopia.

Du kan prova skriva det till företaget som du beställer ifrån och se vad du får för svar.

Nej, så kan man INTE skriva!!!

Syftet med en kravspec är att beställaren ska precicera och specificera vad programmeraren ska göra! Man kan ALDRIG ta genvägar för att "slippa" kravspecandet". Att bygga ett dataprogram är som att bygga ett hus:

1 - Först måste man ha en idéskiss
2 - sen ber man arkitekten att göra en ritning av huset
3 - markberedning
4 - bygg en stabil grund
5 - bygg golv, väggar och sist taket
6 - kontrollera att allt stämmer

Varje människa med sunt förnuft i behåll fattar vad som händer om man skiter i att göra en ritning av huset, vad ska byggjobbarna göra då? Hur vet de vad de ska göra?

Det duger inte att säga: bygg ett hus som ser ut som grannens....

Jag känner att jag måste kolla upp lite mer hur en kravspec ser ut, för jag trodde det bara var en lista med olika funktioner som man vill ha med i sin hemsida.. och då tycker jag det borde gå lika bra att se på en redan färdig hemsida vilka funktioner som finns och hur de fungerar. Reverse engineering helt enkelt.

Nu har jag inte gjort många webbsidor åt andra, men min erfarenhet hittills är att ju mer detaljerad din kravspec är desto lättare blir arbetet för den som gör jobbet. Och i detta sammanhang sätter jag likhetstecken mellan "lättare" och "billigare".

Idealet är att du specificerar så långt att programeraren kan direkt översätta din spec till programkod, rad för rad. För dig är det nog orealistiskt att skriva så noga, men allt du kan göra för att underlätta för programeraren lär göra det jobbet billigare.

Nej, man ska aldrig skriva till en programmerare hur han ska koda. Det är programmerarens jobb.

Kolla på http://www.upedu.org/upedu/

Där har du allt du behöver (sen kan såklart dokumentationen variera breoende på projektmodell)

Här får du exempel på ett kravspec som jag skrev för ett år sedan i ett litet projekt på universitetsnivå.

http://files.dimme.net/Requirements_specif...tion_team26.pdf

Var noga med skall- och bör-krav. Fokusera på mål, syfte och slutresultat. Undvik för många skall-krav som kan fördyra och försvåra ett projekt helt i onödan.

Håller med om beskrivningen att ju mer relevant information som finns dokumenterat i kravspecen desto billigare blir utvecklingsarbetet.

Kodningsjobbet brukar normalt normalt vara 15-20% av hela projektkostnaden.

Kravspecen ska inte beskriva för programmeraren hur han ska programmera, men däremot ska den besriva vadbeställaren förväntar sig att få levererat. Det ska vara så detaljerat att det för en tredje part ska vara möjligt att testa verenda (verksamhets-)funktion med de angivna exempel på indata och att man vid testet får ut det förväntade resultatet.

Det går exempelvis inte att skriva som ett krav att:

Krav xyz: Applikationen ska kunna exportera till Excel.

Om beställaren egentligen menar att man vill kunna:

Krav xyz: Exportera vinst efter avskrivningar, bokslutsdispositioner och skatt samt nettoomsättning per år från markerade räkenskapsår och visa nyckeltalen för vinstmarginal per produktgrupp i ett cirkeldiagram i Excel med tydlig text med en bakgrund av olika färger i varje "tårtbit" i cirkeldiagrammet. Färgerna ska vara Grön, Gul, Brun, Orange. Maximalt 4 år behöver visas åt gången. Excel ska startas utan vidare handgrepp från användaren.

Ni fattar vad jag menar...

Det har visat sig att användningsfall är ett sätt att beskriva krav som lättast kan förstås av både beställare och leverantörens systemanalytiker. Enligt Agile metoden så använder man User-Stories men som är både funktionella och icke-funktionella krav. Bda dessa vägar är till för att undvika missförstånd mellan beställare och leverantör.

Det är bara ca 16% av alla IT-projekt som är framgångsrika i den bemärkelsen att de levereras i tid, med beställda funktioner och till avtalad budget. Övriga 84% är mao misslyckade. Till strsta delen beror detta på att parterna slarvat med kraven från början. Man har kastat sig in i ett projekt utan att ha vettiga krav eller med helt orelistiska förväntningar på vad leverantören kan åstadkomma, underfinansiering är ett annat av de viktigaste orsakerna till misslyckande.

Ett mycket bra sätt att skriva de första trevande kraven är att använda Användningsfall (AF). Ett AF är ett konkret och explicit rutin för hur beställaren har tänkt att systemet ska användas. Exempel på ett anvndningsfall i ett bokföringssystem kan vara "Registrera en verifikation" eller "skapa nytt bokföringsår" eller "gör ett bokslut".

Sen ska varje användningfall beskrivs i detalj ur beställarens/användarens synvinkel, det ska vara så detaljerat att en testledare ska kunna skriva ett konkret testfall för det aktuella användningsfallet.

Detta var de funktionella kraven. Sen ska man även ha med icke-funktionella krav som lagkrav, tekniska begränsningar, xml-format på överföringar till skattmasen, grossisten elelr vad det kan vara. Eventuella befintliga databaser eller data som inte enkelt kan omformas.

Sen ska den som är kravanalytiker ta sig an beställarens kravspec och översätta den till en systemdesign och i den vevan skriva en systemspecifikation, den ska sedan prgrammeraren kunna använda i sitt arbete för kodningen.

Paralellt ska någon med kompetensen testledare ta sig an att skriva en testspecifikation. Dvs göra ett testdokument som testaren sedan kan använda för att veta vad de ska testa.

I mycket små projekt kan givetvis dessa roller bemannas av samma fysiska personer, men resultatet brukar bli bäst om det är experter inom respektive område.

åtmindstonde tycker jag man ska skilja ut tre roller Beställare (kravspec+acceptanstest), Systemdesigner (kravanalys, systemdesign, databasschema, systemdokumentation), Programmerare (kodning+installation).

Den här tråden var bra. Steg för steg vid idé, Vid idé, vilka steg ska man ta.

Jag jobbar vidare med mitt lilla projekt. Nu undrar jag om det går att "slå ihop" flera olika forumdatabaser, från olika typer/versioner av forum, till en enda? Så man kan behålla alla trådar och svar.

Om informationen finns i en relationsdatabas för varje forum så kan det vara möjligt. Du bör dock betrakta själva migreringen från gamla system till det nya som ett eget projekt för varje gammalt system du migrerar. Ofta har de helt olika förutsättningar.

Det beror naturligtvis på hur mycket jobb det är för varje gammalt system om det ska vara ett eget projekt.

Jag kan tänka mig att varje gammalt forum måste ha helt avskiljda "konferenser" i det nya systemet.