Čestitam, vi ste kompetentni neovisni programer . Od svojih skromnih početaka, možda radeći kao ispitivač, napredovali ste do timskog programera, zatim starijeg programera, a sada ste napravili još jedan skok, najveći od svih, do izravne suradnje s klijentima.

Ali tamo gdje su ostali prijelazi bili linearni, ovaj posljednji bio je eksponencijalan. Dok ste u prošlosti zapovijedi za marširanje dobivali od poslodavca koji je radio s klijentima ili se sam bavio softverskim poslom, sada su sve one odgovornosti koje su se nekad dijelile između stručnog testiranja, upravljanja programima itd. Vaše. A sada radite s klijentima koji se ne bave softverskim poslom; oni su u drugom poslu kojem je potreban dio softvera i nemaju jasnu i preciznu viziju što žele od vas. Ovo je daleko veći izazov nego što se čini.

* Napomena: * Ovdje opisujem manje klijente koji žele jedinstvenu vojsku od svog programera. To nije jedina ruta koju freelancer može proći i to nisu jedini klijenti s kojima radimo u ApeeScapeu, ali to je ruta u kojoj najviše uživam. Naravno, ako radite u timu i ne na svoju ruku , neki od dolje navedenih neće se primijeniti. Na primjer, ako upotrebljavate Agilne metodologije ili Ološ , vjerojatno ćete htjeti malo drugačije strukturirati svoje prekretnice.

Od svojih skromnih početaka, možda radeći kao ispitivač, napredovali ste do programera tima, zatim višeg programera, a sada ste napravili još jedan skok, najveći od svih, do izravnog rada s klijentima.

Svi ste čuli za vrhovnu važnost komunikacije. Ne možete raditi dobivanjem nekoliko rečenica kratkog opisa preko Skypea i izgovaranjem 'Vidimo se za tri mjeseca kad završim.' Morate biti u komunikaciji sa svojim klijentom i u svakoj fazi svog rada budite sigurni da imate sukladne ideje o cilju, jer rijetko će vam klijent poslati žičane okvire i detaljne funkcionalne specifikacije. Dobit ćete vrlo općenitu ideju o tome što bi softver trebao raditi, izgledati i raditi. Ako napišete prijavu na temelju letimičnog opisa s kojim obično započinjete, gotovo da nema šanse da će vaš klijent biti zadovoljan rezultatom. U svakoj fazi morate ponoviti svoj put bliže dogovoru.

Ne možete raditi tako što ćete preko Skypea dobiti nekoliko rečenica kratkog opisa i reći 'Vidimo se za tri mjeseca kad završim.'

Budući da su godinama radili u tvrtkama koje su se i same bavile softverskim poslom, gdje su svi u timu bili iz iste kulture, govorili su isti materinji jezik, radili u istom hodniku, svakodnevno se susretali itd., Bilo je vrijedno pažnje da društvo još nije dobio ono što je želio pola vremena. Ne pogriješite: ovdje je izazov ogroman.

Zašto su važni dokumenti za dizajn softvera

Dakle, kad preuzmete novi projekt, prije nego što uopće otvorite Xcode ili Visual Studio, morate imati jasne i dogovorene ciljeve dizajna . A ti bi ciljevi trebali biti utvrđeni u specifikacijskom dokumentu. Ako ga klijent nije napisao, trebali biste ga napisati i predati mu na pregled prije nego što uopće otvorite svoj IDE. I ako naiđete na klijenta koji iskreno kaže: 'Nemamo vremena za projektne dokumente', trebali biste se udaljiti od projekta jer vas čekaju nevolje. Specifikacija ne mora biti osobito dugačka; to može biti samo nekoliko stranica, ali u najmanju ruku treba postaviti korisničko sučelje, uključiti žičane okvire (ako postoji komponenta korisničkog sučelja) i postaviti prekretnice dovršenja.

Bez ovog ćete dokumenta završiti u petlji okrutnih dvosmislenosti, klijenti koji osporavaju ono što su vam rekli ili ono što ste im vi rekli, ljutito šaljući izreze prethodnih komunikacija, tumačeći i prepirući se dok ne dođe vrijeme kada klijent zahtijeva da napravite promjene kako biste aplikaciju uskladili s onim što su zapravo tražili i očekuje da te promjene napravite bez plaćanja.

S ovaj dokument o softverskom dizajnu, imat ćete odgovor na bilo koji takav nesklad: kad se pojave nesuglasice, možete se pozvati na specifikaciju s kojom se klijent složio i odjavio, ističući da ste je do kraja ispunili. Umjesto ljutitih argumenata, napravit ćete izmjene i pojašnjenja u dokumentu. Ako ništa, klijent će se ispričati što je uopće pustio da nepreciznost promakne.

Svi želimo zadovoljne klijente. Svi želimo prijateljski radni odnos. I svi želimo ponos zbog dobro obavljenog posla. Ali to se ne može postići ako postoji bilo kakva neodređenost oko toga što je zapravo posao je . Ako vaš klijent kaže da je projektni dokument previše dodatnog posla, vaš je posao objasniti mu da stvaran dodatni će se posao pojaviti kad treba izvršiti reviziju zbog neke vrste nesporazuma. Ako klijent još inzistira na tome da napredujete bez takvog dokumenta, trebali biste prihvatiti činjenicu da ste u neizvodljivoj vezi i otići.

Što bi zapravo trebala specificirati specifikacija softverskog dizajna?

To bi u najmanju ruku trebao biti opis željene prijave, kriteriji za završetak i prekretnice. Zapamtite, dijelite ono što je najbolje opisati kao dokument sa zahtjevima i funkcijama, a ne kao specifikaciju implementacije. I ako specifična implementacija nije navedeni cilj klijenta, na vama je način na koji ćete to učiniti.

Korisničko sučelje

Većina projekata su aplikacije, a ne knjižnice ili okviri. Ali ako slučajno imate jednu od ovih za isporuku, smatrajte se sretnima jer korisničko sučelje je daleko najproblematičnija komponenta vašeg predloška projektnog dokumenta , i gotovo uvijek dovodi do nesporazuma. Mnogi će vam klijenti poslati savršene ilustracije koje je u grafičkom uređivaču izradio grafički dizajner koji nije programer. Ali problem je u tome što ove ilustracije ne govore ništa o animacijama, kontrolnim stanjima (npr. Je li ovaj gumb onemogućen? Nestaje li kad je neupotrebljiv?) Ili čak koje radnje treba izvršiti kada se pritisne gumb.

Mnogi će vam klijenti poslati savršene ilustracije koje je u grafičkom uređivaču izradio grafički dizajner koji nije programer. Ali ove ilustracije ne govore ništa o animacijama, upravljačkim stanjima ili čak koje radnje treba izvršiti kada se pritisne tipka.

Prije nego što započnete pisati kod iza ovih ilustracija, trebali biste moći odgovoriti na sva ta pitanja. Konkretno, trebali biste znati:

1. Jesu li kontrole uvijek vidljive i / ili omogućene? Pod kojim se uvjetima mijenjaju njihova stanja?
2. Izgleda kao bitmapa - je li to gumb?
3. Koji se prijelazi događaju između tih stanja i pogleda? A kako ih treba animirati?

Ako je na vama da generirate korisničko sučelje za suglasnost klijenta, učinite isto obrnuto: upotrijebite žičani alat i stvorite cjelovit set rasporeda zaslona, ​​uključujući sve varijante koje prikazi prikazuju u različitim stanjima aplikacije. Ovo može biti iscrpan i naporan posao, ali nećete požaliti - može vas spasiti od ponovnog pisanja ogromnih količina koda i ponovnog stvaranja sučelja zbog manjeg nesporazuma s glavnim implikacijama. Ako izrađujete dvostruku aplikaciju (npr. Za obje iPhone i iPad), stvorite zasebne žičane okvire za oboje.

Važne su i dimenzije zaslona. Postoje (prema pisanju članka) tri veličine iPhone zaslona. Odvojeni žičani okviri za zaslone od 3,5 ”i 4” vjerojatno su pretjerani, ali možda ćete ih morati napraviti; u većini slučajeva možete jednostavno promijeniti proporcije.

Ako vam klijent isporučuje grafiku, pobrinite se da je pravilno veličine s odgovarajućim omjerima slike; morfiranje bilo koje bitmape koja sadrži tekst ili objekte (poput krugova) uvest će izobličenja. Ako se ne podudaraju, recite klijentu da ih ponovno stvori s odgovarajućim veličinama. Ne pretpostavljajte da možete razvući ekran od 3,5 inča u 4 ”i samo se s njim valjati.

Funkcionalnost

Ključna pitanja koja treba postaviti u dokumentu za dizajn prijave:

• Što aplikacija radi i koliko brzo to radi?
• Koji su mogući uvjeti kvara i kako se s njima postupa?
• Koje se jednokratne operacije rade pri prvom izvršavanju (tj. Nakon instalacije)?
• Ako korisnik stvori unose bilo koje vrste (npr. Oznake), koja su ograničenja?

Generalizirajte ove ideje i budite što detaljniji i temeljitiji - jer ovdje pogreške ili nesporazumi znače prepisivanje koda.

Prekretnice

Predložak vaše specifikacije trebao bi rasporediti jasne prekretnice. Ako vaš klijent napiše dizajn funkcionalnog i korisničkog sučelja, trebali biste se naknadno dogovoriti oko niza prekretnica. Ponekad su to i pragovi naplate, ali u najmanju ruku pružaju jasnu metriku prema završetku. Prekretnice mogu biti u pogledu funkcionalnosti i / ili komponenata; mogu biti čak i zasebne aplikacije ako svirka uključuje niz isporučenih rezultata. Kad je moguće, miljokazi bi trebali biti približno jednaki u trajanju.

Primjer specifikacije softverskog dizajna

Ovdje ću postaviti strukturu primjera odgovarajućeg projektnog dokumenta. Naravno, ovaj predložak treba prilagoditi prema potrebi. Za drugi primjer vidi Specifikacija uzorka Joela Spolskog , na temelju ovaj zapis . Dokumentu pristupa nešto drugačije, ali dijeli sličan osjećaj.

kapitalni proračun je jedan:

Izjava o ciljevima

Uključite kratki odlomak koji opisuje projekt i njegovu publiku.

Opis funkcije

Što znači aplikacija čini ? Na koja će se stanja aplikacije (opisi osnovnih scenarija na visokoj razini) korisnik susresti?

Na primjer, vaš funkcionalni opis može izgledati ovako:

• Prvo trčanje
• Stvaranje novog _____ (igra, pretraživanje itd.)
• Operacije
• Pozadina i ponašanje u prvom planu

Korisničko sučelje

Uključite žičane okvire za svaku stranicu, s detaljnim opisima:

• Svaka kontrola, uključujući stanja (omogućeno / onemogućeno / istaknuto) i operacije.
• Podržane orijentacije i prijelazi između njih.
• Zastupljena funkcionalnost.
• Rukovanje pogreškama.
• Dimenzije i ograničenja.

Evo žicnih okvira povezanih s mojom najnovijom iOS aplikacijom NotifEye:

Ako ste zainteresirani, napravio sam ove makete koristeći Balsamiqov alat za žičane okvire .

Na primjer, vaš Opis korisničkog sučelja može izgledati kao:

• Navigacijska traka
  • Lijeva kontrola navigacije: povratak na početnu stranicu
  • Naslovna traka: trenutni zaslon ili naziv operacije
  • Novi gumb: stvorite novu stvar
• Pogled na stol
  • Odjeljak 0: Naslov odjeljka
  • Odjeljak 0 redaka:
    • Kontrola retka 0 (npr. Slika)
    • Redak teksta 0
    • Redak teksta 2

Prekretnice

Kao što je gore opisano, rokovi za završetak i očekivani rezultati.

Na primjer, odjeljak prekretnica u predlošku dokumenta za dizajn može izgledati ovako:

1. Fasadna aplikacija koja prikazuje zaslon i s privremenim prijelazima i primjerima slika / teksta
2. Komunikacijski protokol: aplikacija se povezuje na mrežu / poslužitelj
3. Funkcionalna prekretnica 1:…
4. Alfa aplikacija (s punom funkcionalnošću)
5. Stabilnost
6. Otpustite

Osiguravanje da softverska dokumentacija ostaje relevantna

Ne želim implicirati da je faza dizajna gotova nakon što ste se vi i vaš klijent dogovorili o specifikacijskom dokumentu. Uvijek će biti pojedinosti koje nitko od vas nije razmatrao, a i vi i klijent ćete se, gledajući srednje rezultate, susresti s novim idejama, promjenama u dizajnu, neočekivanim nedostacima u dizajnu i neizvodljivim prijedlozima.

Dizajn će se razvijati, a promjene bi trebale biti zabilježene u vašem dokumentu. U svojih 25 godina iskustva, niti jednom nisam radio na projektu gdje se to nije dogodilo - a to uključuje i moje vlastite aplikacije (tj. Gdje sam bio vlastiti klijent). Već tada sam stvorio projektni dokument s detaljnim specifikacijama i prilagodio ga prema potrebi.

Iznad svega, ostanite u kontaktu. Barem nekoliko puta tjedno kontaktirajte svog klijenta, prijavite svoj napredak, zatražite pojašnjenje i pobrinite se da dijelite identična viđenja. Kao lakmusov test za vašu komunikaciju, pokušajte osigurati da vi i vaš klijent date isti odgovori na ova tri pitanja:

1. Na čemu je programer upravo radio?
2. Na čemu programer trenutno radi?
3. Na čemu će programer raditi sljedeće?

Razumijevanje osnova

Što znači kratica SDD?

SDD je kratica za dokument dizajna softvera ili opis dizajna softvera.

Što je funkcionalni projektni dokument?

Dokument funkcionalnog dizajna opisuje mogućnosti, izgled i funkcije softverskog proizvoda koje treba u konačnici izvršiti. Dokumenti o dizajnu nazivaju se i funkcionalnim specifikacijama ili dokumentima funkcionalnih specifikacija (FSD) ili specifikacijama funkcionalnih zahtjeva.

Što je projektni dokument na visokoj razini?

Projektni dokument visoke razine (HLDD) opisuje arhitekturu koja se koristi u razvoju određenog softverskog proizvoda. Obično uključuje dijagram koji prikazuje predviđenu strukturu softverskog sustava. Budući da je ovo dokument na visokoj razini, često se koristi netehnički jezik.

Što se nalazi u dokumentu o softverskom dizajnu?

Dokument o softverskom dizajnu (SDD) obično opisuje dizajn podataka softverskog proizvoda, dizajn arhitekture, dizajn sučelja i proceduralni dizajn. Sadržaj i organizacija SDD-a određena je standardom IEEE 1016.