[ Pobierz całość w formacie PDF ]
. 37Rozdział 2.f& Planowanie procesu rozwojuPrzykładowo: Wersja 1.0 edycja 89 2/24/2000 .To także idealny moment na wykonanie kopii zapasowej całej kompilacji.Kopia ta powinna zawierać zarówno bazędanych, jak i wszystkie pliki, które uległy modyfikacji przy przejściu z jednej kompilacji do drugiej.Ponieważ w projektwłożono już znaczące zasoby i czas, warto sporządzić tę kopię na osobnym nośniku.Aby upewnić się, że poszczególne części właściwie ze sobą współpracują, po stworzeniu nowej kompilacji każdorazowopowinieneś przeprowadzać testy integralności.Po stwierdzeniu, iż nowa kompilacja działa bez zarzutu, powinieneśdostarczyć je każdemu członkowi zespołu.Umieść kopię aplikacji w ogólnodostępnym katalogu, by każdy z programistówi testerów miał do niego dostęp.Jeśli to możliwe, skorzystaj z funkcji narzędzia służącego do kontroli wersji, takiego jakMicrosoft Visual SourceSafe.Dzięki temu będziesz mógł budować i śledzić tworzone kompilacje, a także ograniczyćproblemy powstające na skutek zmian dokonywanych przez kilku programistów.Jeśli nie korzystasz z Visual SourceSafe, procedury archiwizacyjne stają sięjeszcze ważniejsze.Niektóre kompilacje powstają na różnych etapach procesu rozwoju (patrz przykłady w tabeli 2.2 i na rysunku 2.8).Podczasfazy koncepcyjnej lub zbierania wymagań dobrze jest stworzyć jeden lub kilka prototypów, które pozwolą użytkownikomocenić wygląd proponowanego GUI.Pózniej, gdy kilka z podstawowych opcji już działa, bardzo przydatnym może okazaćsię przekazanie jednemu lub dwa użytkownikom edycji alfa.Dzięki temu będziesz znał ich opinię, co może pozwolić Ciznacznie zmniejszyć ryzyko niepowodzenia.Gdy aplikacja jest już prawie gotowa, dostarczenie użytkownikom do testówwersji beta znacznie podwyższy jakość produktu końcowego.Większość z tych edycji powstaje dla każdej z głównychwersji (duże zmiany) i mniejszych poprawek (małe zmiany).Przed wypuszczeniem ostatecznej wersji warto też oddaćużytkownikom do testów jedną lub kilka edycji-kandydatek (EK1, EK2 i tak dalej).Aby utworzyć edycję, wez prawidłowo działającą kompilację i przygotuj pakiet instalacyjny.Czynność ta może być takprosta jak spakowanie interfejsu bazy danych albo tak skomplikowana jak stworzenie profesjonalnego skryptuinstalacyjnego przy użyciu zawartego w Office 2000 Developer s Edition narzędzia instalacyjnego.W obu przypadkach,edycja powinna być przetestowana na kilku komputerach, aby upewnić się, że działa bez zarzutu (rysunek 2.7).Gdy produkt z pozytywnym wynikiem przejdzie fazę testów, przekaż go do zainstalowania użytkownikom.Do każdej wersjidołącz Informacje o edycji .Wylicz w nich nowe opcje, zmiany i znane problemy.Nawet jeśli użytkownik nigdy ich nieprzeczyta, przydają się one programistom, gdyż czytając je, wiedzą, co w danej edycji zostało zmienione.Nie zapomnij oaktualizacji dokumentacji użytkownika, za każdym razem, gdy dokonujesz zmian w aplikacji.Nieaktualna dokumentacja jestgorsza niż całkowity jej brak.Rysunek 2.7.Tworzenie edycjiW czasie trwania projektu utworzonych zostanie wiele edycji i kompilacji.Na rysunku 2.8 przedstawiono przykład cyklu,w którym tworzone są edycje i kompilacje.Każda kompilacja daje programistom, testerom, a czasami nawetużytkownikom okazję do przetestowania aplikacji i podzielenia się z resztą zespołu swoimi uwagami i spostrzeżeniami.Nazywane są one często usterkami lub problemami.W zależności od ich ważności w stosunku do kontynuacji rozwojuaplikacji poprawienie ich następuje już w następnej kompilacji lub też odkładane jest na pózniej. 38Część I f& Projektowanie bazy danychRysunek 2.8.Przykład cyklukompilacji i edycjiSzczegółowy projektMimo iż w większości opcji i zadań sposób ich implementacji w aplikacji jest oczywisty, zdarza się (w pięciu do dwudziestuprocent przypadków), że wymaga to chwili zastanowienia.Do typowych przykładów należą moduły, formularze nawigacyjne,skomplikowane algorytmy i rzadkie techniki automatyzacyjne.Projekt takich opcji lub zadań powinien być w jakiś sposóbudokumentowany.Pozostaw po swoich decyzjach i sposobie ich uwzględnienia w projekcie jakiś ślad.Może on przydaćsię tobie lub komuś innemu, gdy nadejdzie potrzeba dokonania pewnych zmian.Zachowaj dokumentację dotyczącą pro-jektu do czasu, gdy wyjaśnione zostaną wszelkie wątpliwości.Doskonałym sposobem na opisanie niestandardowych algorytmów jest umie-szczenie w procedurze lub funkcji komentarzy w pseudokodzie.Pseudokodjest to uproszczony kod VBA, dołączony jako komentarz opisującyimplementowany w danym miejscu kodu proces.Dokładna składnia nie jestważna.Opisujesz jedynie algorytm użyty w VBA.Poniższy przykładprzedstawia użycie pseudokodu w nagłówku procedury.Public Sub ProcessAllUpdates()' Comments : Get the updated mail from MAPI Inbox,' unattatch it and update the current database.' Parameters :' Returns :' Created : Tuesday, July 27, 1999 11:44 PM by Joe Developer' Pseudo Code :' --------------------------------------------------------------' Sub ProcessUpdates()' UpdateCount = 0' UnattatchAllUpdates()' Open a recordset from tblDownloadReceivedResults' For each in Recordset' ProcessOneUpdate()' If succesful Then' Delete Update file' Increment(UpdateCount)' Next' -------------------------------------------------------------- 39Rozdział 2.f& Planowanie procesu rozwojuKontrola projektuKontrola projektu polega na skonsultowaniu problemów wynikłych podczas tworzenia projektu oraz sposobów ichrozwiązania z osobami trzecimi.Konsultacja ta może być całkiem nieformalna, ale równie dobrze może przybrać formęoficjalnej prezentacji podczas zebrania członków zespołu.Często zdarza się, że podczas opisywania projektu innymosobom zauważasz nowe problemy lub lepsze rozwiązania.Inny programista często znajduje to, co Ty przeoczyłeś.Todoskonały moment, by wykryć błędy w aplikacji, zanim rozpoczniesz czasochłonne kodowanie i testowanie [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
. 37Rozdział 2.f& Planowanie procesu rozwojuPrzykładowo: Wersja 1.0 edycja 89 2/24/2000 .To także idealny moment na wykonanie kopii zapasowej całej kompilacji.Kopia ta powinna zawierać zarówno bazędanych, jak i wszystkie pliki, które uległy modyfikacji przy przejściu z jednej kompilacji do drugiej.Ponieważ w projektwłożono już znaczące zasoby i czas, warto sporządzić tę kopię na osobnym nośniku.Aby upewnić się, że poszczególne części właściwie ze sobą współpracują, po stworzeniu nowej kompilacji każdorazowopowinieneś przeprowadzać testy integralności.Po stwierdzeniu, iż nowa kompilacja działa bez zarzutu, powinieneśdostarczyć je każdemu członkowi zespołu.Umieść kopię aplikacji w ogólnodostępnym katalogu, by każdy z programistówi testerów miał do niego dostęp.Jeśli to możliwe, skorzystaj z funkcji narzędzia służącego do kontroli wersji, takiego jakMicrosoft Visual SourceSafe.Dzięki temu będziesz mógł budować i śledzić tworzone kompilacje, a także ograniczyćproblemy powstające na skutek zmian dokonywanych przez kilku programistów.Jeśli nie korzystasz z Visual SourceSafe, procedury archiwizacyjne stają sięjeszcze ważniejsze.Niektóre kompilacje powstają na różnych etapach procesu rozwoju (patrz przykłady w tabeli 2.2 i na rysunku 2.8).Podczasfazy koncepcyjnej lub zbierania wymagań dobrze jest stworzyć jeden lub kilka prototypów, które pozwolą użytkownikomocenić wygląd proponowanego GUI.Pózniej, gdy kilka z podstawowych opcji już działa, bardzo przydatnym może okazaćsię przekazanie jednemu lub dwa użytkownikom edycji alfa.Dzięki temu będziesz znał ich opinię, co może pozwolić Ciznacznie zmniejszyć ryzyko niepowodzenia.Gdy aplikacja jest już prawie gotowa, dostarczenie użytkownikom do testówwersji beta znacznie podwyższy jakość produktu końcowego.Większość z tych edycji powstaje dla każdej z głównychwersji (duże zmiany) i mniejszych poprawek (małe zmiany).Przed wypuszczeniem ostatecznej wersji warto też oddaćużytkownikom do testów jedną lub kilka edycji-kandydatek (EK1, EK2 i tak dalej).Aby utworzyć edycję, wez prawidłowo działającą kompilację i przygotuj pakiet instalacyjny.Czynność ta może być takprosta jak spakowanie interfejsu bazy danych albo tak skomplikowana jak stworzenie profesjonalnego skryptuinstalacyjnego przy użyciu zawartego w Office 2000 Developer s Edition narzędzia instalacyjnego.W obu przypadkach,edycja powinna być przetestowana na kilku komputerach, aby upewnić się, że działa bez zarzutu (rysunek 2.7).Gdy produkt z pozytywnym wynikiem przejdzie fazę testów, przekaż go do zainstalowania użytkownikom.Do każdej wersjidołącz Informacje o edycji .Wylicz w nich nowe opcje, zmiany i znane problemy.Nawet jeśli użytkownik nigdy ich nieprzeczyta, przydają się one programistom, gdyż czytając je, wiedzą, co w danej edycji zostało zmienione.Nie zapomnij oaktualizacji dokumentacji użytkownika, za każdym razem, gdy dokonujesz zmian w aplikacji.Nieaktualna dokumentacja jestgorsza niż całkowity jej brak.Rysunek 2.7.Tworzenie edycjiW czasie trwania projektu utworzonych zostanie wiele edycji i kompilacji.Na rysunku 2.8 przedstawiono przykład cyklu,w którym tworzone są edycje i kompilacje.Każda kompilacja daje programistom, testerom, a czasami nawetużytkownikom okazję do przetestowania aplikacji i podzielenia się z resztą zespołu swoimi uwagami i spostrzeżeniami.Nazywane są one często usterkami lub problemami.W zależności od ich ważności w stosunku do kontynuacji rozwojuaplikacji poprawienie ich następuje już w następnej kompilacji lub też odkładane jest na pózniej. 38Część I f& Projektowanie bazy danychRysunek 2.8.Przykład cyklukompilacji i edycjiSzczegółowy projektMimo iż w większości opcji i zadań sposób ich implementacji w aplikacji jest oczywisty, zdarza się (w pięciu do dwudziestuprocent przypadków), że wymaga to chwili zastanowienia.Do typowych przykładów należą moduły, formularze nawigacyjne,skomplikowane algorytmy i rzadkie techniki automatyzacyjne.Projekt takich opcji lub zadań powinien być w jakiś sposóbudokumentowany.Pozostaw po swoich decyzjach i sposobie ich uwzględnienia w projekcie jakiś ślad.Może on przydaćsię tobie lub komuś innemu, gdy nadejdzie potrzeba dokonania pewnych zmian.Zachowaj dokumentację dotyczącą pro-jektu do czasu, gdy wyjaśnione zostaną wszelkie wątpliwości.Doskonałym sposobem na opisanie niestandardowych algorytmów jest umie-szczenie w procedurze lub funkcji komentarzy w pseudokodzie.Pseudokodjest to uproszczony kod VBA, dołączony jako komentarz opisującyimplementowany w danym miejscu kodu proces.Dokładna składnia nie jestważna.Opisujesz jedynie algorytm użyty w VBA.Poniższy przykładprzedstawia użycie pseudokodu w nagłówku procedury.Public Sub ProcessAllUpdates()' Comments : Get the updated mail from MAPI Inbox,' unattatch it and update the current database.' Parameters :' Returns :' Created : Tuesday, July 27, 1999 11:44 PM by Joe Developer' Pseudo Code :' --------------------------------------------------------------' Sub ProcessUpdates()' UpdateCount = 0' UnattatchAllUpdates()' Open a recordset from tblDownloadReceivedResults' For each in Recordset' ProcessOneUpdate()' If succesful Then' Delete Update file' Increment(UpdateCount)' Next' -------------------------------------------------------------- 39Rozdział 2.f& Planowanie procesu rozwojuKontrola projektuKontrola projektu polega na skonsultowaniu problemów wynikłych podczas tworzenia projektu oraz sposobów ichrozwiązania z osobami trzecimi.Konsultacja ta może być całkiem nieformalna, ale równie dobrze może przybrać formęoficjalnej prezentacji podczas zebrania członków zespołu.Często zdarza się, że podczas opisywania projektu innymosobom zauważasz nowe problemy lub lepsze rozwiązania.Inny programista często znajduje to, co Ty przeoczyłeś.Todoskonały moment, by wykryć błędy w aplikacji, zanim rozpoczniesz czasochłonne kodowanie i testowanie [ Pobierz całość w formacie PDF ]