[ Pobierz całość w formacie PDF ]
.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 [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl odbijak.htw.pl
.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 [ Pobierz całość w formacie PDF ]