Andrew Hunt, Dav

[ Pobierz całość w formacie PDF ]
.Po uzyskaniu pozy-tywnej oceny układu elementów należy ten prototyp wyrzucić i od nowa zaim-plementować odpowiednie rozwiązanie, tym razem z uwzględnieniem odpo-wiedniej logiki biznesowej i w docelowym języku programowania.Podobnie,możemy zdecydować się na opracowanie prototypów wielu algorytmów odpo-wiedzialnych za właściwe rozmieszczanie paczek w kontenerze.Testy funk-cjonalne można zakodować na wysokim poziomie, korzystając z takich językówjak Perl, natomiast niskopoziomowe testy wydajnościowe warto zaimplemento-wać w języku bliższym instrukcji maszynowych.W każdym przypadku po podję-ciu dotyczącej prototypu decyzji należy przystąpić do ponownego kodowaniaodpowiednich atrybutów w ich środowisku docelowym, gdzie będą narażonena oddziaływanie nieco innych czynników.Właśnie na tym polega tworzenieprototypów.72 u� Rozdział 2.Postawa pragmatycznaModel z kodem smugowym ma na celu rozwiązywanie nieco innego problemu.Tworząc kod smugowy, chcemy dowiedzieć się, jak nasza aplikacja będzie funk-cjonowała jako całość.Chcemy pokazać naszym użytkownikom, jak opisywaneinterakcje będą wyglądały w praktyce.Chcemy też udostępnić programistomszkielet architektury, w ramach którego będą implementowali swój kod.W tymprzypadku moglibyśmy skonstruować kod smugowy składający się na przykładz uproszczonego algorytmu rozmieszczenia przesyłek (być może w kolejnościdodawania do kontenera) oraz prostym, ale działającym interfejsem użytkownika.Po połączeniu wszystkich komponentów aplikacji w jedną całość dysponujemyframeworkiem, który możemy prezentować zarówno użytkownikom, jak i pro-gramistom zaangażowanym w projekt.Z czasem uzupełniamy ten frameworko nowe funkcje oraz wypełniamy stosowane wcześniej namiastki procedur.Warto jednak pamiętać, że sam framework pozostaje niezmieniony, zatemmożemy być pewni, że system będzie zachowywał się tak jak w momencie ukoń-czenia prac nad pierwszym kodem smugowym.Wspomniane rozróżnienie jest na tyle ważne, że warto je powtórzyć.W wynikutworzenia prototypu powstaje tymczasowy, jednorazowy kod.Kod smugowy jestuproszczony, ale kompletny, zatem stanowi fragment szkieletu docelowego sys-temu.Tworzenie prototypów jest jak rozpoznanie, próba zebrania cennych da-nych wywiadowczych przed wystrzeleniem pierwszego pocisku smugowego.Pokrewne podrozdziałyl� Odpowiednio dobre oprogramowanie w rozdziale 1.l� Prototypy i karteczki samoprzylepne w rozdziale 2.l� Pułapka specyfikacji w rozdziale 7.l� Wielkie oczekiwania w rozdziale 8.11 Prototypy i karteczki samoprzylepneWiele różnych branż używa prototypów do sprawdzania przyszłych rozwiązańw najróżniejszych obszarach; tworzenie prototypów jest nieporównanie tańszeod produkcji w pełnej skali.Na przykład producenci samochodów nierzadkobudują wiele odmiennych prototypów przed wyborem ostatecznego projektunowego modelu.Każdy prototyp jest projektowany z myślą o przetestowaniukonkretnego aspektu samochodu parametrów aerodynamicznych, stylistyki,właściwości konstrukcyjnych itd.Model z gliny być może jest budowany z myśląo testach w tunelu aerodynamicznym, natomiast model z drewna balsy i mocnejtaśmy samoprzylepnej ma trafić do działu stylistyki itd.Niektórzy producencisamochodów idą jeszcze krok dalej i ograniczają się do modelowania swoich autw komputerze, dodatkowo ograniczając koszty.W ten sposób ryzykowne lubniesprawdzone elementy można łatwo wypróbować bez konieczności konstru-owania właściwego produktu.Prototypy i karteczki samoprzylepne t� 73Prototypy oprogramowania buduje się w ten sam sposób i z tych samych po-wodów z myślą o analizie i ujawnieniu czynników ryzyka oraz o stworzeniudodatkowej szansy wprowadzenia korekt znacznie mniejszym kosztem.Tak jakproducenci samochodów możemy stworzyć prototyp z myślą o przetestowaniujednego lub wielu konkretnych aspektów realizowanego projektu.Technikę tworzenia prototypów zwykle utożsamiamy z pisaniem jakiegoś kodu,jednak prototypy nie zawsze muszą mieć postać programów.Tak jak producencisamochodów możemy konstruować swoje prototypy z różnych materiałów.Naprzykład karteczki samoprzylepne doskonale sprawdzają się w roli budulcaprototypów tak dynamicznych aspektów jak przepływ pracy czy logika aplikacji.Prototyp interfejsu użytkownika można narysować na tablicy, opracować w pro-gramie graficznym jako pozbawiony funkcji szkic lub zbudować przy użyciuprogramu do konstruowania interfejsów.Prototypy projektuje się z myślą o uzyskiwaniu odpowiedzi na zaledwie kilkapytań, zatem z natury rzeczy są tańsze i szybsze w tworzeniu niż aplikacjetrafiające do środowiska produkcyjnego.Kod może ignorować nieistotne szcze-góły (nieważne w danej chwili, ale być może bardzo ważne dla użytkownikawłaściwego produktu w przyszłości).Jeśli na przykład tworzymy prototyp gra-ficznego interfejsu użytkownika, możemy całkowicie pominąć problem niepra-widłowych wyników czy danych.Jeśli jednak przedmiotem analizy są aspektyobliczeniowe i wydajnościowe, możemy zrezygnować z atrakcyjnego graficznegointerfejsu użytkownika (a być może nawet z jakiegokolwiek interfejsu tego typu).Jeśli znajdujemy się w środowisku, w którym nie możemy ani na momentpominąć żadnego szczegółu, powinniśmy odpowiedzieć sobie na pytanie, czykonstruowanie prototypu w ogóle ma sens.W takim przypadku być może lep-szym rozwiązaniem będzie przyjęcie modelu programowania analogicznego dopocisków smugowych (patrz podrozdział Pociski smugowe we wcześniejszejczęści tego rozdziału).Co może być przedmiotem prototypuJakiego rodzaju aspekty warto wybierać do zbadania przy użyciu prototypu?Wszystko, z czym wiąże się jakieś ryzyko.Wszystko, czego wcześniej nie pró-bowano lub co ma krytyczne znaczenie dla ostatecznego systemu.Wszystko, cojest niedowiedzione, eksperymentalne lub wątpliwe.Wszystko, co budzi naszdyskomfort [ Pobierz całość w formacie PDF ]