Innan vi g\u00e5r in p\u00e5 \u00e4mnet objektorienterad analys och design (vilket \u00e4r d\u00e5 de flesta av oss f\u00e5r ut det roligaste av det vi g\u00f6r f\u00f6rutom att faktiskt skriva kod), \u00e4r det viktigt att f\u00f6lja upp n\u00e5gra fler saker ang\u00e5ende f\u00f6rst\u00e5else av kundernas krav .<\/p>\n
I f\u00f6rra inl\u00e4gget n\u00e4mnde jag:<\/p>\n
\nOm du tar dig tid att f\u00f6rst\u00e5 vad de vill fr\u00e5n b\u00f6rjan, s\u00e5 beh\u00f6ver inte kraven vara ett 50-sidigt dokument som beskriver hur varje enskild modul m\u00e5ste fungera.<\/p>\n<\/blockquote>\n
Till exempel, n\u00e4r jag s\u00e4tter ihop krav (eller ett Statement of Work) som jag brukar kalla dem n\u00e4r jag skickar dem till kunder, \u00f6verstiger jag s\u00e4llan tio sidor, och det \u00e4r ofta f\u00e4rre.<\/p>\n
Och \u00e4ven om det finns tillf\u00e4llen d\u00e5 det \u00e4r l\u00e4ngre, tror jag att en del av anledningen till att utveckla en kort upps\u00e4ttning krav kommer med de prelimin\u00e4ra diskussionerna f\u00f6r att se till att du och kunden\/kunderna har utvecklat ett gemensamt spr\u00e5k som ni kan arbeta med.<\/p>\n
N\u00e4r du g\u00f6r det beh\u00f6ver kraven och arbetsbeskrivningen \u2013 vad du \u00e4n v\u00e4ljer att kalla dem \u2013 inte vara lika l\u00e5nga.<\/p>\n
Att skriva en arbetsf\u00f6rklaring<\/h2>\n
F\u00f6rst skulle jag vilja skilja mellan ett arbetsutl\u00e5tande<\/strong> och krav<\/strong> i samband med detta inl\u00e4gg.<\/p>\n
\n
- Krav<\/strong> \u00e4r vad kunden vill ha byggt.<\/li>\n
- Arbetsf\u00f6rklaringen beskriver<\/strong> vad du ska g\u00f6ra, hur du kommer att g\u00f6ra och f\u00f6r hur mycket.<\/li>\n<\/ul>\n
Jag kommer att t\u00e4cka det senare mer i detalj i det h\u00e4r inl\u00e4gget. Men det r\u00e4cker med att s\u00e4ga att krav kan komma i form av diskussioner, dokumentation eller b\u00e5de och f\u00f6r kunden.<\/p>\n
Innan jag hoppar in p\u00e5 de olika delarna av det jag tar med i en arbetsf\u00f6rklaring, finns det n\u00e5gra saker som jag tycker \u00e4r v\u00e4rda att n\u00e4mna:<\/p>\n
\n
- Skriv inte en arbetsbeskrivning f\u00f6rr\u00e4n du har f\u00e5tt alla krav fr\u00e5n kunden.<\/li>\n
- Se till att kunden vet vad han kan f\u00f6rv\u00e4nta sig av en arbetsbeskrivning.<\/li>\n
- Om du ska ta dig tid att skriva en arbetsbeskrivning, best\u00e4m om du ska ta betalt f\u00f6r tiden eller inte och se till att kunden \u00e4r medveten om att de kommer att beh\u00f6va betala f\u00f6r det eller inte<\/li>\n<\/ol>\n
Detta \u00e4r en av de saker som \u00e4r frilansare f\u00f6r frilansare eller byr\u00e5 f\u00f6r byr\u00e5. Med det sagt, h\u00e4r \u00e4r de delar av en arbetsf\u00f6rklaring som jag brukar ta med.<\/p>\n
F\u00f6rbereda en arbetsbeskrivning<\/h3>\n
N\u00e4r jag f\u00f6rbereder en arbetsbeskrivning har jag en mall som jag anv\u00e4nder. Jag kommer att ge en uppdelning som t\u00e4cker mycket av det h\u00e4r.<\/p>\n
S\u00e5 h\u00e4r fungerar varje avsnitt:<\/p>\n
1 Arbetsbeskrivning<\/h4>\n
Syftet med detta dokument \u00e4r att [definiera ett f\u00f6rslag till l\u00f6sning f\u00f6r PROJEKTET].<\/p>\n
Kraven f\u00f6r projektet har tillhandah\u00e5llits av [KUNDENS NAMN], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. Villkoren i avtalet \u00e4r en kombination av de som \u00f6verenskommits av [KUNDNAMN] och [DITT NAMN p\u00e5 AGENTENS NAMN].<\/p>\n
2 \u00d6versikt \u00f6ver krav<\/h4>\n
Syftet med detta dokument \u00e4r att [definiera ett f\u00f6rslag till l\u00f6sning f\u00f6r PROJEKTET].<\/p>\n
Kraven f\u00f6r projektet har tillhandah\u00e5llits av [KUNDENS NAMN], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. Villkoren i avtalet \u00e4r en kombination av de som \u00f6verenskommits av [KUNDNAMN] och [DITT NAMN p\u00e5 AGENTENS NAMN].<\/p>\n
3 Spr\u00e5k och teknik<\/h4>\n
Webbservern, mjukvaran, verktygen och tillv\u00e4gag\u00e5ngss\u00e4ttet som kommer att anv\u00e4ndas f\u00f6r att bygga l\u00f6sningen.<\/p>\n
4 webbl\u00e4sare som st\u00f6ds<\/h4>\n
Om detta \u00e4r ett webbaserat projekt, t\u00e4ck sedan de webbl\u00e4sare som st\u00f6ds, om det kommer att finnas responsiv funktionalitet eller inte, och hur de tidigare punkterna kommer att testas.<\/p>\n
5 Spr\u00e5k och teknik<\/h4>\n
Webbservern, mjukvaran, verktygen och tillv\u00e4gag\u00e5ngss\u00e4ttet som kommer att anv\u00e4ndas f\u00f6r att bygga l\u00f6sningen.<\/p>\n
6 Projektkrav och milstolpar<\/h4>\n
Vanligtvis den l\u00e4ngsta delen av dokumentet. Den sammanfattar:<\/p>\n
\n
- Kraven,<\/li>\n
- Hur varje krav kommer att byggas och levereras,<\/li>\n
- Eventuella ytterligare anteckningar som kunden b\u00f6r vara medveten om.<\/li>\n<\/ul>\n
7 F\u00f6reslagen tidslinje<\/h4>\n
Detta \u00e4r baserat p\u00e5 de milstolpar som beskrivs i f\u00f6reg\u00e5ende avsnitt och feedback fr\u00e5n kunden.<\/p>\n
8 Andra faktorer<\/h4>\n
Diverse saker som du v\u00e4ljer att inkludera s\u00e5som vad du eller din byr\u00e5 v\u00e4ljer att ta med till projektet, hur f\u00f6rsenad feedback kan p\u00e5verka projektet, och s\u00e5 vidare.<\/p>\n
9 Ber\u00e4knad kostnad<\/h4>\n
Detta inkluderar den totala kostnaden f\u00f6r projektet och en valfri uppdelning av betalningsplanen.<\/p>\n
Det \u00e4r n\u00f6dv\u00e4ndigt<\/h3>\n
Jag vet: Jag har sagt detta f\u00f6rut i tidigare inl\u00e4gg i den h\u00e4r serien. Det h\u00e4r \u00e4r inte den mest glamor\u00f6sa delen av det vi g\u00f6r. Ist\u00e4llet skulle vi ist\u00e4llet hoppa direkt in i programmering.<\/p>\n
Men hur vet du vad du ska bygga (och bygga det bra) om vi inte har tagit itu med problemet vi f\u00f6rs\u00f6ker l\u00f6sa?<\/p>\n
Och det \u00e4r vad allt som leder fram till objektorienterad analys och design ger oss.<\/p>\n
Objektorienterad analys<\/h2>\n
Nu n\u00e4r vi har f\u00e5tt pappersarbetet (eller till och med "aff\u00e4rsgrejer" som vissa kanske h\u00e4nvisar till det) ur v\u00e4gen, \u00e4r det dags att b\u00f6rja arbeta oss in i programmering.<\/p>\n
Innan du g\u00f6r det \u00e4r det dock viktigt att analysera kraven och best\u00e4mma vilka delar av projektet som kommer att tj\u00e4na vilket syfte. Till exempel:<\/p>\n
\n
- Beh\u00f6ver vi n\u00e5gon redan existerande programvara?<\/li>\n
- Beh\u00f6ver vi skriva n\u00e5gra adaptrar eller datalagerkod?<\/li>\n
- Hur kommer vi att bygga applikationslagret och enheterna inom det?<\/li>\n
- Vad s\u00e4gs om front-end<\/li>\n<\/ul>\n
Och f\u00f6r m\u00e5nga \u00e4r det h\u00e4r det roliga b\u00f6rjar. S\u00e5 jag \u00e4r sugen p\u00e5 att b\u00f6rja prata igenom detta ocks\u00e5. Vi b\u00f6rjar i n\u00e4sta inl\u00e4gg.<\/p>\n