Sveikiname jus kompetentingas nepriklausomas kūrėjas . Nuo savo kuklios pradžios, galbūt dirbdami testuotoju, jūs perėjote į komandos kūrėją, paskui - į vyresnįjį kūrėją, o dabar padarėte dar vieną šuolį, didžiausią iš jų, - tiesioginį darbą su klientais.

Bet ten, kur kiti perėjimai buvo tiesiniai, šis paskutinis buvo eksponentinis. Anksčiau žygių užsakymus gaudavote iš darbdavio, kuris dirbo su klientais arba pats užsiėmė programinės įrangos verslu, dabar visos tos pareigos, kurios kažkada buvo paskirstytos tarp ekspertų bandymų, programų valdymo ir t. T. O dabar jūs dirbate su klientais, kurie nėra programinės įrangos verslas; jie yra kitame versle, kuriam reikalinga programinė įranga, ir jie neturi aiškios ir tikslios vizijos, ko nori iš tavęs. Tai kur kas didesnis iššūkis nei atrodo.

* Pastaba: * Čia aš apibūdinu mažesnius klientus, kurie nori vieno žmogaus armijos iš savo kūrėjo. Tai nėra vienintelis maršrutas, kurį gali eiti laisvai samdomas darbuotojas, ir tai nėra vieninteliai klientai, su kuriais dirbame „ApeeScape“, tačiau man labiausiai patinka maršrutas. Žinoma, jei dirbate komandoje, o ne pats , kai kurie iš žemiau pateiktų elementų nebus taikomi. Pavyzdžiui, jei naudojate Judrios metodikos arba Scrum , tikriausiai norėsite šiek tiek kitaip suformuoti savo etapus.

Nuo savo kuklios pradžios, galbūt dirbdami testuotoju, jūs perėjote į komandos kūrėją, paskui - į vyresnįjį kūrėją, o dabar padarėte dar vieną šuolį, didžiausią iš jų, ir tiesioginį darbą su klientais.

Jūs visi girdėjote apie aukščiausią bendravimo svarbą. Jūs negalite dirbti, gaudami kelis trumpus aprašymo sakinius per „Skype“ ir sakydami 'Iki pasimatymo po trijų mėnesių, kai baigsiu'. Turite bendrauti su savo klientu ir kiekviename savo darbo etape įsitikinkite, kad turite tikslių idėjų, nes iš tikrųjų retai klientas jums atsiųs vielinius rėmus ir išsamią funkcinę specifikaciją. Jūs gausite labai bendrą supratimą apie tai, ką programinė įranga turėtų daryti, atrodyti ir tekėti. Jei parašote paraišką pagal paviršutinišką aprašymą, nuo kurio paprastai pradedate, beveik nėra tikimybės, kad jūsų klientas bus patenkintas rezultatu. Kiekviename etape turite kartoti savo kelią arčiau susitarimo.

Jūs negalite dirbti, gaudami kelis trumpus aprašymo sakinius per „Skype“ ir sakydami „Iki pasimatymo per tris mėnesius, kai aš baigsiu“.

Daugelį metų dirbęs įmonėse, kurios pačios užsiėmė programinės įrangos verslu, kur visi komandos nariai buvo iš tos pačios kultūros, kalbėjo ta pačia gimtąja kalba, dirbo tame pačiame koridoriuje, kasdien susitiko ir t. T., Pažymėtina, kad įmonė vis tiek pusę laiko negavau to, ko norėjo. Nesuklyskite: iššūkis čia milžiniškas.

Kodėl programinės įrangos projektavimo dokumentai yra svarbūs

Taigi, kai imsitės naujo projekto, prieš net atidarydami „Xcode“ ar „Visual Studio“, turite turėti aiškius ir sutartus dizaino tikslus . Šie tikslai turėtų būti nustatyti specifikacijos dokumente. Jei klientas dar nerašė, turėtumėte jį parašyti ir pateikti jam peržiūrėti dar neatidarę savo IDE. Ir jei susiduriate su klientu, kuris sako: „Mes neturime laiko projektavimo dokumentams“, atvirai, turėtumėte nueiti nuo projekto nes jūsų laukia nemalonumai. Specifikacija neturi būti ypač ilga; tai gali būti tik keli puslapiai, bet bent jau turėtų būti išdėstyta vartotojo sąsaja, įtraukti laidų rėmai (jei yra vartotojo sąsajos komponentas) ir nustatyti užbaigimo etapai.

Be šį dokumentą pateksite į aštrią pašaipą, kai klientai ginčys tai, ką jums pasakė ar ką jūs jiems sakėte, piktai siuntinėdami ankstesnių pranešimų iškarpas, aiškindamiesi ir ginčydamiesi, kol ateis laikas, kai klientas to pareikalaus atliekate pakeitimus, kad paraiška atitiktų „tai, ko jie iš tikrųjų paprašė“, ir tikitės, kad atliksite tuos pakeitimus nemokėdami.

Su Šiame programinės įrangos projektavimo dokumente turėsite atsakymą į bet kokį tokį ginčą: iškilus nesutarimams, galite nurodyti specifikaciją, kurią klientas sutiko ir pasirašė, nurodydamas, kad laiške ją įvykdėte. Vietoj piktų ginčų atliksite dokumento pakeitimus ir paaiškinimus. Jei kas, klientas atsiprašys, kad iš pradžių leido praslysti.

Mes visi norime patenkintų klientų. Mes visi norime draugiškų darbo santykių. Mes visi norime pasididžiavimo gerai atliktu darbu. Tačiau jų negalima pasiekti, jei yra kokių nors neaiškumų, koks iš tikrųjų yra darbas yra . Jei jūsų klientas sako, kad dizaino dokumentas yra per didelis papildomas darbas, tai jūsų darbas paaiškinti jiems, kad tikras papildomas darbas atsiras, kai dėl kažkokio nesusipratimo reikės atlikti pataisas. Jei klientas vis tiek primygtinai reikalauja, kad žengtumėte be tokio dokumento, turėtumėte susitaikyti su tuo, kad jūsų santykiai neveikia, ir nueikite.

Ką turėtų iš tikrųjų nurodyti programinės įrangos projektavimo specifikacija?

Tai turėtų būti bent jau norimos paraiškos aprašymas, užbaigimo kriterijai ir gairės. Atminkite, kad bendrinate tai, kas geriausiai apibūdinama kaip reikalavimų ir funkcijos dokumentas, o ne diegimo specifikacija. Ir nebent konkretus įgyvendinimas yra nurodytas kliento tikslas, kaip jūs jį pritaikysite, priklauso nuo jūsų.

Vartotojo sąsaja

Dauguma projektų yra programos, o ne bibliotekos ar sistemos. Bet jei atsitiks, kad vienas iš šių būdų bus pasiekiamas, suskaičiuokite, ar jums pasisekė, nes vartotojo sąsaja yra pats problemiškiausias jūsų dizaino dokumento šablono komponentas ir beveik visada sukelia nesusipratimų. Daugelis klientų atsiųs jums tobulas iliustracijas, kurias grafiniame redaktoriuje sukūrė grafikos dizaineris, kuris nėra programuotojas. Tačiau problema yra tokia: šiose iliustracijose nieko nėra pasakyta apie animacijas, valdymo būsenas (pvz., Ar šis mygtukas išjungtas? Ar jis dingsta, kai jo negalima naudoti?) Ar net kokius veiksmus reikia atlikti paspaudus mygtuką.

Daugelis klientų atsiųs jums tobulas iliustracijas, kurias grafiniame redaktoriuje sukūrė grafikos dizaineris, kuris nėra programuotojas. Tačiau šios iliustracijos nieko nepasako apie animacijas, valdymo būsenas ar net kokius veiksmus reikia atlikti paspaudus mygtuką.

Prieš pradėdami rašyti kodą už šių iliustracijų, turėtumėte galėti atsakyti į visus šiuos klausimus. Tiksliau, turėtumėte žinoti:

1. Ar valdikliai visada matomi ir (arba) įjungti? Kokiomis sąlygomis keičiasi jų būsenos?
2. Panašu, kad bitų žemėlapis - ar tai mygtukas?
3. Kokie perėjimai vyksta tarp šių būsenų ir pažiūrų? Ir kaip juos reikėtų animuoti?

Jei nuo jūsų priklauso sugeneruoti vartotojo sąsają, kad klientas sutiktų, atlikite tą patį veiksmą atvirkščiai: naudokite vielos rėmo įrankį ir sukurkite visą ekrano išdėstymo rinkinį, įskaitant visus variantus, kuriuos rodiniai rodo skirtingose ​​programos būsenose. Tai gali būti išsamus ir varginantis darbas, tačiau jūs nesigailėsite - tai gali jus sutaupyti nuo naujo daugybės kodų rašymo ir sąsajų atkūrimo dėl nedidelio nesusipratimo, turinčio didelių pasekmių. Jei kuriate dvigubą programą (pvz., Abiem „iPhone“ ir „iPad“), sukurkite atskirus laidinius rėmus abiem.

Ekrano matmenys taip pat yra svarbūs. Yra (rašymo metu) trijų dydžių „iPhone“ ekranai. Atskirų laidų rėmeliai 3,5 ir 4 colių ekranams tikriausiai yra per dideli, tačiau gali tekti juos sukurti; daugeliu atvejų galite tiesiog pakeisti proporcijas.

Jei jūsų klientas jums pateikia grafikos, įsitikinkite, kad jos dydis yra tinkamas, atsižvelgiant į tinkamus formato santykius; morfijavus bet kokį bitmap, kuriame yra teksto ar objektų (pvz., apskritimų), atsiras iškraipymų. Jei jie nesutampa, liepkite klientui juos iš naujo sukurti pritaikius dydžius. Nemanykite, kad galite ištiesti 3,5 colių ekraną į 4 colių pliūpsnį ir tiesiog su juo riedėti.

Funkcionalumas

Pagrindiniai klausimai, kuriuos reikia užduoti paraiškos projekto dokumente:

• Ką programa veikia ir kaip greitai tai daro?
• Kokios yra galimos gedimo sąlygos ir kaip jos tvarkomos?
• Kokios vienkartinės operacijos atliekamos pirmą kartą vykdant (t. Y. Po įdiegimo)?
• Kokie yra apribojimai, jei vartotojas kuria bet kokio tipo įrašus (pvz., Žymes)?

Apibendrinkite šias idėjas ir būkite kuo išsamesni ir kruopštesni, nes klaidos ar nesusipratimai reiškia kodo perrašymą.

Etapai

Jūsų specifikacijos šablonas turėtų išdėstyti aiškius etapus. Jei jūsų klientas rašo funkcinės ir vartotojo sąsajos dizainą, vėliau turėtumėte susitarti dėl gairių rinkinio. Kartais tai yra ir atsiskaitymo slenksčiai, tačiau jie bent jau pateikia aiškią metriką link užbaigimo. Tarpiniai tikslai gali būti funkcionalumas ir (arba) komponentai; jie gali būti net atskiros programos, jei koncerte yra daugybė rinkinių. Kai įmanoma, etapų trukmė turėtų būti maždaug vienoda.

Programinės įrangos dizaino specifikacijos pavyzdys

Čia išdėstysiu tinkamo projektinio dokumento struktūros pavyzdį. Žinoma, šis šablonas turėtų būti koreguojamas pagal poreikį. Kitą pavyzdį žr Joelio Spolsky pavyzdžio specifikacija , remiantis šį rašymą . Jis prie dokumento priartėja šiek tiek kitaip, tačiau panašios nuotaikos.

koks yra artumo principas

Tikslų pareiškimas

Įtraukite trumpą pastraipą, kurioje aprašomas projektas ir jo numatoma auditorija.

Funkcinis aprašymas

Ką veikia programa padaryti ? Su kokiomis programos būsenomis (aukšto lygio pagrindinių scenarijų aprašymais) susidurs vartotojas?

Pavyzdžiui, jūsų funkcinis aprašymas gali atrodyti taip:

• Pirmasis bėgimas
• Naujo _____ kūrimas (žaidimas, paieška ir kt.)
• Operacijos
• Fonas ir įgytas elgesys

Vartotojo sąsaja

Kiekviename puslapyje įtraukite laidinius rėmus, išsamiai aprašydami:

• Kiekvienas valdiklis, įskaitant būsenas (įjungtas / išjungtas / paryškintas) ir operacijas.
• Palaikomos orientacijos ir perėjimai tarp jų.
• Atstovaujamas funkcionalumas.
• Klaida tvarkant.
• Matmenys ir apribojimai.

Čia yra laidų rėmai, susiję su mano naujausia „iOS“ programa „NotifEye“:

Jei jus domina, aš panaudojau šiuos maketus „Balsamiq“ vielinio rėmo įrankis .

Pavyzdžiui, jūsų Vartotojo sąsajos aprašymas gali atrodyti taip:

• Naršymo juosta
  • Kairysis naršymo valdiklis: grįžkite į pagrindinį puslapį
  • Pavadinimų juosta: dabartinis ekranas arba operacijos pavadinimas
  • Naujas mygtukas: sukurkite naują dalyką
• Lentelės vaizdas
  • 0 skyrius: skyriaus pavadinimas
  • 0 skyriaus eilutės:
    • Eilučių valdiklis 0 (pvz., Vaizdas)
    • 0 teksto eilutė
    • 2 teksto eilutė

Etapai

Kaip aprašyta aukščiau, užbaigimo terminai ir numatomi rezultatai.

Pvz., Jūsų dizaino dokumento šablono etapai gali atrodyti taip:

1. Fasado programa, rodanti ekraną, su laikinais perėjimais ir vaizdų / teksto pavyzdžiais
2. Ryšio protokolas: programa prisijungia prie tinklo / serverio
3. Funkcinis 1 etapas:…
4. „Alpha“ programa (su visomis funkcijomis)
5. Stabilumas
6. Atleiskite

Įsitikinimas, kad programinės įrangos dokumentacija išlieka aktuali

Nenoriu pasakyti, kad projektavimo etapas bus baigtas, kai jūs ir jūsų klientas susitarsite dėl specifikacijos dokumento. Visada bus detalių, kurių nė vienas iš jūsų nepagalvojote, ir jūs, ir klientas, žiūrėdami į tarpinius rezultatus, susidurs su naujomis idėjomis, dizaino pakeitimais, netikėtais dizaino trūkumais ir neveikiančiais pasiūlymais.

Dizainas tobulės, o pakeitimai turėtų būti užfiksuoti jūsų dokumente. Per savo 25 metų patirtį aš niekada nedirbau projekte, kuriame taip neatsitiko - ir tai apima mano paties programas (t. Y., Kai buvau pats savo klientas). Jau tada sukūriau projektinį dokumentą su išsamiomis specifikacijomis ir prireikus jį pakoregavau.

Visų pirma palaikykite ryšį. Bent kelis kartus per savaitę susisiekite su savo klientu, praneškite apie savo pažangą, paprašykite paaiškinimo ir įsitikinkite, kad turite vienodų vizijų. Pabandykite užtikrinti, kad jūs ir jūsų klientas tai atliktų kaip lakmuso popierėlį tas pats atsakymai į šiuos tris klausimus:

1. Ką kūrėjas ką tik dirbo?
2. Prie ko šiuo metu dirba kūrėjas?
3. Ką kūrėjas dirbs toliau?

Suprasti pagrindus

Ką reiškia santrumpa SDD?

SDD reiškia programinės įrangos projektavimo dokumentą arba programinės įrangos aprašą.

Kas yra funkcinio projekto dokumentas?

Funkcinio dizaino dokumente aprašomos programinės įrangos gaminio galimybės, išvaizda ir funkcijos, kurias jis turi atlikti. Projektavimo dokumentai taip pat vadinami funkcinėmis specifikacijomis arba funkcinių specifikacijų dokumentais (FSD) arba funkcinių reikalavimų specifikacijomis.

Kas yra aukšto lygio dizaino dokumentas?

Aukšto lygio projektavimo dokumente (HLDD) aprašoma architektūra, naudojama kuriant konkretų programinės įrangos produktą. Paprastai jame pateikiama schema, vaizduojanti numatytą programinės įrangos sistemos struktūrą. Kadangi tai yra aukšto lygio dokumentas, dažnai vartojama netechninė kalba.

Kas yra programinės įrangos projektavimo dokumente?

Programinės įrangos projektavimo dokumente (SDD) paprastai aprašomas programinės įrangos produkto duomenų dizainas, architektūros dizainas, sąsajos dizainas ir procedūrinis dizainas. SDD turinį ir organizavimą nurodo IEEE 1016 standartas.