Planowanie projektu sprawdzania zgodności aplikacji

Autor: Chris Jackson

Opublikowano: 16 października 2009

Zawartość strony

	Definiowanie wizji i zakresu: Windows
	Definiowanie wizji i zakresu: Zarządzanie aplikacjami
	Budowanie zespołu
	Gromadzenie danych
	Wdrażanie na podstawie ról
	Analiza
	Testowanie
	Korygowanie stanu
	Podsumowanie

Moje zajęcie zmusza mnie podróży po całym świecie, gdy pracuję z klientami, którzy przechodzą przez proces migracji do najnowszych wersji Windows. Często największą trudnością, na którą natrafiają, jest (nie)kompatybilność aplikacji, co zmusza do postawienia następujących pytań: Jak dużo będzie kosztowała poprawa sytuacji? Jak długo to będzie trwało? Co musimy w tym celu wiedzieć? Jak moglibyśmy przyspieszyć ten proces, jeśli będzie trwał zbyt długo?

Projekt sprawdzania zgodności aplikacji (w skrócie – projekt zgodności) jest podobny do projektu tworzenia oprogramowania: oszacowania kosztów i potrzebnego czasu zmieniają się w trakcie pracy w miarę odkrywania, przed czym naprawdę stoimy. Widywałem już osoby proponujące oszacowania czasu i kosztów w oparciu o liczbę aplikacji, ale podejście to najlepszym wypadku daje wartość średnią. Jakkolwiek przybliżenie takie często jest dość dobre, niemal nikt nie jest w stanie „utrafić dokładnie”. Większość organizacji uzyskuje efekty znacznie lepsze od średnich albo wręcz przeciwnie – rozczarowująco gorsze.

Zajmijmy się więc na początek fazami planowania projektu zgodności – wczesnym określeniem oszacowania kosztów, korygowaniem ich z upływem czasu i minimalizowaniem w całym przebiegu projektu. Postaram się przedstawić wskazówki i rozwiązania, których użyli moi najbardziej skuteczni klienci, w nadziei, że oszczędzi to konieczności ponownego odkrywania znanych już rozwiązań. W szczególności chciałbym zmaksymalizować produktywność tych uczestników projektu, którzy nie są bezpośrednio zaangażowani w proces sprawdzania, takich jak końcowi użytkownicy wykonujący testy czy właściciele określający priorytety dla poszczególnych aplikacji, gdyż ich współpraca jest niezbędna do osiągnięcia sukcesu.

Definiowanie wizji i zakresu: Windows

Zagadnienia kompatybilności aplikacji często stwarzają sytuacje nie do przebycia. Jeśli odkryjemy zestaw aplikacji Visual Basic 3.0, które są jednocześnie krytyczne dla przedsiębiorstwa, niesprawne i pozbawione kodu źródłowego, łatwo można popaść w zniechęcenie. Potrzebny jest motywujący doping. Chcielibyśmy mieć dominujące cele, które pomogą w podejmowaniu trudnych, strategicznych decyzji.

Dla przykładu, jeśli poprawiamy aplikację wymagającą praw administracyjnych, zaś głównym celem uaktualnienia Windows jest umożliwienie, że będziemy korzystać z niej jako standardowy użytkownik, zastosowanie podkładki (shim) RunAsAdmin nie jest właściwym rozwiązaniem. Jeśli podstawowym celem jest uproszczenie wyszukiwania, porządkowania i korzystania z informacji i jedyną metodą naprawienia niesprawnej aplikacji jest „kup nową”, konieczne jest uwzględnienie w rozważaniach możliwości wizualizacji i integracji z powłoką produktu, który bierzemy pod uwagę.

Po sformułowaniu wizji należy zdefiniować zakres. Jeśli wizja obejmuje przekazanie jakiejś części komputerów biurkowych standardowym użytkownikom, zdefiniujmy tę wielkość. Wymóg ten może to brzmieć jak oczywistość, ale często jest pomijany, co rzadko łączy się ze skutecznym działaniem.

 Do początku strony

Definiowanie wizji i zakresu: Zarządzanie aplikacjami

Migracja systemu operacyjnego jest doskonałą okazją do określenia celów zarządzania aplikacjami. Musimy sprawdzić każdą aplikację wykorzystywaną w przedsiębiorstwie – doskonała okazja do przemyślenia sposobów zarządzania portfelem aplikacji.

Celom zarządzania aplikacjami warto przyjrzeć się z dwóch punktów widzenia:

• Ruchliwość
  Jak szybko możemy zareagować na zmiany techniczne i użyć ich jako przewagi wobec konkurencji? Jak dobrzy jesteśmy w dziedzinie testów oprogramowania, aby zminimalizować zarówno ryzyko, jak i czas? Jak sprawnie zarządzamy cyklem życia aplikacji? Czy rozumiemy, jaki problem biznesowy rozwiązuje dane oprogramowanie i czy jest to rozwiązanie optymalne? Oprogramowanie powinno być wybierane rozważnie i strategicznie.
• Produktywność
  Czy staramy się zmaksymalizować produktywność użytkowników? Czy zapewniamy im środowisko, które jest znajome, nowoczesne i wysokiej jakości? Czy mamy określone standardy jakościowe dla zarządzania produktywnością i kosztami pomocy technicznej? Czy użytkownicy współpracujący ze sobą używają tych samych platform programowych? Chcielibyśmy posłużyć się oprogramowaniem w celu zwiększenia produktywności biznesowej.

Największym pojedynczym wyzwaniem, z którym musi uporać się zarządzanie aplikacjami, jest rozproszenie oprogramowania. Niektóre organizacje miewają aż do 100 000 fragmentów oprogramowania. Czymś takim zupełnie nie da się zarządzać! Pomyślmy nad tym – możemy zatrudnić 50-osobowy zespół, poświęcić tylko jedną godzinę na testy każdej aplikacji i nadal potrzebny będzie cały rok kalendarzowy, aby ukończyć pracę. Projekt badania zgodności aplikacji jest projektem wielkoskalowym i jednym z największych sukcesów jest zminimalizowanie jego wielkości.

Bez względu na to, jaki jest najpoważniejszy problem, sformułujmy sposób, w jaki chcemy go naprawić. Zapewne nie uda się przejść od 100 000 aplikacji do 500 za jednym razem. Zapewne nie uda się wyeliminować wszystkich starych programów VB6 z przyciskami tak dużymi, że naciśnięcie ich wymaga obu rąk. Tym niemniej powinniśmy określić cele, włączyć je do wizji i określić je ilościowo w zakresie.

 Do początku strony

Budowanie zespołu

Po przygotowaniu wizji i zakresu projektu nadchodzi czas na zebranie zespołu, który ma wykonać pracę. Role krytyczne (osoby, które odgrywać będą więcej niż jedną rolę) obejmują:

• Menedżera projektu – koordynuje pracę zespołu rozciągającą się na wiele dyscyplin i grup organizacji.
• Szefa koordynacji biznesowej – współpracuje z właścicielami aplikacji biznesowych w celu uzyskania informacji o ich priorytecie, lokalizuje i koordynuje testy akceptacji użytkowników oraz koordynuje pracę użytkowników pilotażowych (rola ta często przypada menedżerowi projektu).
• Szefa technicznego – współpracuje z projektantami w celu zidentyfikowania luk szkoleniowych, a także z testerami przy rozwiązywaniu złożonych problemów kompatybilności.
• Menedżera laboratorium – zajmuje się zapewnieniem zespołowi i użytkownikom właściwych warunków i aktualnej wersji systemu, w której mają być wykonane testy.
• Zespół badania aplikacji – określa bieżący stan wsparcia dla oprogramowania innych firm (często przekazywane firmie zewnętrznej).
• Zespół testujący – wykonuje testy instalacji i wygrzewania w celu sprawdzenia podstawowej zgodności przed rozpoczęciem testów użytkowników (często przekazywane firmie zewnętrznej).
• Zespół naprawczy – rozwiązuje problemy kompatybilności ujawniane podczas testów.
• Zespół pakietowy – tworzy pakiety instalacyjne po zakończeniu testów (często przekazywane firmie zewnętrznej).

Wszyscy członkowie zespołu muszą ściśle współpracować ze sobą i ze wszystkimi innymi osobami zaangażowanymi w proces migracji. Na przykład niezbędne będą aktualne obrazy systemu operacyjnego oraz bieżące ustawienia zasad grupy czy konfiguracji.

Mając zdefiniowaną wizję i zakres oraz zidentyfikowany skład zespołu można rozpocząć planowanie pracy, która ma zostać wykonana. Cały proces można podzielić na trzy fazy:

• Gromadzenie danych
  Co mamy? (Stan bieżący)
• Analiza
  Co chcemy mieć? (Stan pożądany)
• Testowanie i korygowanie
  Co działa?

 Do początku strony

Gromadzenie danych

Zanim możliwe będzie zaplanowanie pracy, musimy wiedzieć, jakie oprogramowanie posiadamy – czyli poznać stan bieżący. Im bardziej wyrafinowane są narzędzia zarządzania oprogramowaniem, tym lepszy będzie wgląd w stan bieżący. Jeśli firma już dysponuje inwentarzem oprogramowania utworzonym przez narzędzia zarządzania oprogramowaniem, należy go użyć. Jeśli nie, bezpłatne narzędzie Application Compatibility Toolkit (ACT) z firmy Microsoft może utworzyć doskonały spis oprogramowania. Wybór użytego narzędzia nie ma większego znaczenia; ważne jest, aby wybrana metoda zwróciła wszystkie dane, które będą potrzebne do udzielenia odpowiedzi na pytania, pojawiające się w dalszej części procesu. Aby struktura tworzonego spisu ułatwiła dalszą pracę, powinien on zawierać następujące informacje:

• Oddział lub organizacja
  Gdzie pracują użytkownicy? Informacja ta pomaga określić, które programy służą do rozwiązywania danych problemów biznesowych, aby określić priorytety lub zidentyfikować nadmiarowość. Informację tę można gromadzić na wiele sposobów – używając nazwy komputera, podsieci IP i innych wskazówek identyfikacyjnych.
• Rola
  Co robi dany użytkownik? Ta informacja pomaga określić, do czego dane oprogramowanie jest używane, ponownie w celu ustalania priorytetów lub wykrycia nadmiarowości. Ta informacja jest zazwyczaj trudniejsza do znalezienia, o ile nie jest już gdzieś zapisana, na przykład w Active Directory.
• Wykorzystanie
  Ilu użytkowników ma zainstalowany ten program? Albo jeszcze lepiej, jak wielu rzeczywiście go używa? Znacznie prościej jest wycofać aplikację, jeśli wiemy, że nikt jej nie ma zainstalowanej albo że osoby, które ją mają, nigdy jej nie użyły.

Następnie chcielibyśmy pomóc w testowaniu aplikacji dzięki następującym danym:

• Wersja systemu i poziom poprawek
  Potrzebujemy szczegółów na temat konfiguracji użytkowników, u których oprogramowanie (przypuszczalnie) działa poprawnie, dzięki czemu tester będzie w stanie porównać przypadek działający z niedziałającym, jeśli coś pójdzie źle.
• Eksperci dla danego zagadnienia
  Chcemy, aby nasze testy odzwierciedlały realną pracę, do czego potrzebni będą realni użytkownicy. Jeśli jeszcze nie znamy ekspertów, w identyfikacji kandydatów mogą pomóc dane o wykorzystaniu.
• Inne zainstalowane aplikacje
  Niekiedy problemy z aplikacjami wynikają z konfliktu z innymi programami – coś, co trudno jest zidentyfikować na stanowisku testowym.

Na koniec chcielibyśmy, aby nasz spis oprogramowania zawierał dane pomagające w rzeczywistym wdrożeniu. Jeżeli planowane jest wdrożenie na podstawie ról (patrz ramka), oznakowanie aplikacji rolami ułatwi wybranie ich do testowania w pierwszej kolejności. Analogicznie, jeśli wdrożenie ma się odbywać wydziałami lub na podstawie geograficznej, testy należy rozpocząć od aplikacji używanych przez te osoby, dla których najpierw będą one instalowane.

Czy w pełni orientujemy się w sytuacji bieżącej? Doskonale – możemy przejść do następnego kroku. Jeśli nie, wybierzmy narzędzie, które zapewni nam taką orientację.

Możemy potrzebować na wstępie przybliżonych danych, aby móc zbudować studium biznesowe dla projektu badania zgodności oprogramowania. Microsoft udostępnia narzędzie niewykorzystujące agentów, które pozwala uzyskać przybliżone wartość: Microsoft Assessment and Planning Toolkit. Jakkolwiek zwykle nie jest to wystarczające do prowadzenia całego projektu, narzędzie udostępnia pewne wskazówki dotyczące wielkości pracy, którą będzie trzeba wykonać.

 Do początku strony

Wdrażanie na podstawie ról

Ci nasi klienci, którzy przeszli proces migracji z najlepszym sukcesem, rozpowszechniali system Windows Vista na podstawie ról. Rozwiązanie takie działa doskonale, jeśli przedsiębiorstwo wykorzystuje strukturalne role zadań pracowników. Role mają większe powiązanie z wykorzystaniem oprogramowania niż jakikolwiek inny łatwy do wykonania podział personelu na rozróżnialne grupy. Zacząć można od strukturalnej roli zadaniowej, takiej jak call center. Taka grupa ma zapewne stosunkowo małą liczbę aplikacji – zaledwie kilka. Można przetestować wszystkie te aplikacje i być gotowym do wdrożenia tej roli. Następnie można pochwalić się zarządowi i przejść do następnej roli. Morale zespołu jest wysokie z powodu sukcesu, zarząd jest zadowolony z powodu widocznych postępów, zaś zespół uzyskuje doświadczenie, pracując nad stosunkowo niewielkim problemem, zanim będzie musiał zmierzyć się z rolami wymagającymi wielkiej różnorodności oprogramowania, takimi jak role pracowników wiedzy.

Aby uzyskać dane szczegółowe, konieczne jest użycie agentów. Tworzenie inwentarza oprogramowania jest nietrywialnym zadaniem ze względu na fakt, że istnieje wiele sposobów instalowania aplikacji (MSI, xcopy, setup.exe i tak dalej). Konieczne jest zlokalizowanie wszystkich aplikacji, które są ważne. Większość narzędzi bez trudu wykrywa zaawansowane aplikacje klienckie, ale co z aplikacjami sieci Web, kontrolkami ActiveX czy aplikacjami utworzonymi wewnątrz programów Microsoft Office? Nie udało mi się dotąd znaleźć narzędzia, które odnajdywałoby wszystko.

Jeśli nie dysponujemy jeszcze inwentarzem oprogramowania, narzędzie Application Compatibility Toolkit (ACT) jest najlepsze wśród rozwiązań ujawniających aplikacje biurkowe w sposób, który jest dla nas ważny: zwraca informacje o programie i o wersji, które można dopasować do warunków wsparcia technicznego.

Przy okazji, z całym szacunkiem dla ACT i jego mechanizmu rejestrowania inwentarza, chciałbym wyjaśnić jedno nieporozumienie: idea Compatibility Evaluators (narzędzi oceny zgodności) jest substytutem testowania. Trzeba porównać koszt uzyskania tych danych z ich wartością przy decydowaniu, jak wiele zamierzamy gromadzić. Nie można wyeliminować konieczności przeprowadzenia testów przy użyciu tych narzędzi. Są one starannie dostrojone pod kątem wydajności (tak by można było je uruchamiać w środowisku produkcyjnym), zatem nie są zaprojektowane do wykrycia każdego możliwego problemu (taka próba co najmniej utrudniłaby i spowolniła pracę użytkowników, o ile w ogóle byłaby wykonalna).

Narzędzia oceny zgodności potrafią skutecznie wykryć odrzucenia (funkcje, które zostały usunięte z systemu operacyjnego, takie jak a GINA). Narzędzie oceny zgodności Internet Explorer jest fantastyczne, ale działa tylko pod warunkiem, że jest to Internet Explorer 7 lub późniejszy (a ponieważ raczej nie zamierzamy wykonywać wdrożenia przed zrobieniem testów, jego zastosowanie ogranicza się do laboratorium lub maszyn pilotażowych). Ponieważ narzędzie oceny UAC nie wykrywa wiele poza tym, co mechanizmy wirtualizacji plików i rejestru naprawiają automatycznie, daje tylko zgrubne przewidywania dodatkowych problemów, które pojawią się w pracy standardowego użytkownika. Podsumowując, wszystko, co wykryje narzędzie UAC, to są zdecydowanie problemy kompatybilności, które trzeba rozwiązać, ale ze względu na ograniczenia zasięgu tego narzędzia nie jest ono w stanie przewidzieć, czy i jak bardzo aplikacja jako całość jest uszkodzona.

Musimy też rozważyć problem kosztów. Przy używaniu zaawansowanych systemów wdrażania oprogramowania prostsze i tańsze jest rozpowszechnienie agentów. Trzeba też uwzględnić cenę serwera obsługującego gromadzone dane, a także czas niezbędny na zbieranie danych. Przy średnim czasie 17 sekund na przetworzenie każdego dziennika możemy zebrać dane z 1000 maszyn dla trzech dni, przesyłając je co osiem godzin i przetworzyć ten cały zbiór w niecałe dwa dni. Jednak gdybyśmy spróbowali zbierać dane z każdego komputera w przedsiębiorstwie zawierającym 200 000 miejsc pracy przez 30 dni, przesyłając je co osiem godzin, musielibyśmy czekać blisko 10 lat (!!!) na przetworzenie tych danych.

Jeżeli tak czy owak przystępujemy do tworzenia inwentarza, sensowne wydaje się zbieranie danych zgodności z wybranego podzbioru komputerów, ale nie należy angażować się bezwzględnie. Widziałem już zbyt wiele oszacowań kosztów związanych z gromadzeniem takich danych.

 Do początku strony

Analiza

Gdy wiemy już, co mamy, musimy ustalić, co chcemy mieć – pożądany stan inwentarza. Wymaga to współpracy pomiędzy pracownikami biznesowymi i działem IT, a także liczne trudne wybory. W rezultacie zbyt wiele razy widywałem proces odbywający się tak, jak na Rysunku 1, gdzie można ustalić, co właściwie chcemy, po wydaniu masy pieniędzy na rzeczy, których nie chcemy.

Rysunek 1: Nierozsądna analiza aplikacji – to co działa, niekoniecznie jest tym, co chcemy mieć.

Problem ze zdecydowaniem, czego właściwie chcemy, na podstawie tego, co działa, prowadzi do sytuacji, w której utrzymujemy (i obsługujemy) nadmiarowe, pokrywające się aplikacje jedynie dlatego, że przypadkiem działają, albo też decydujemy się na wyeliminowanie aplikacji dopiero po zainwestowaniu w ich badanie.

Znacznie bardziej sensowne wydaje się najpierw ustalić, co chcemy osiągnąć, a dopiero potem inwestować czas i pieniądze w badania i testować jedynie te aplikacje, co do których zdecydowaliśmy, że będą przydatne w naszym biznesie.

Aby zwiększyć produktywność procesu analizy aplikacji proponujemy zdefiniowanie kilku jednoznacznych celów i sprawdzanie postępów względem nich. Do zalecanych celów można zaliczyć:

• Maksymalna liczba aplikacji
  Określić jako cel dopuszczalną liczbę aplikacji, które zamierzamy wspierać.
• Poziom tolerancji zarządzanych aplikacji
  Określić poziom tolerancji, przy którym aplikacja staje się aplikacją „zarządzaną”, opierając się zarówno na priorytetach biznesowych, jak i na liczbie użytkowników.
• Poziom zarządzania
  W organizacjach zdecentralizowanych określić ogólne dla przedsiębiorstwa cele zarządzania aplikacjami, pozostawiając jednostkom biznesowym autonomię w implementacji tych wskazówek stosownie do ich stosowalności w konkretnym przypadku.
• Standardy wersjonowania oprogramowania komercyjnego
  Kupowanie zawsze najnowszych wersji całego oprogramowania może być nadmiernie kosztowne, ale trzeba też unikać ryzyka używania zbyt starego oprogramowania. Warto rozważyć ustanowienia standardu, że stosowana jest na przykład wersja n (bieżąca) lub n-1 (poprzednia) dla krytycznych aplikacji.
• Obsługiwane platformy
  Ograniczenie liczby obsługiwanych platform pomaga zmniejszyć złożoność zarządzania. Jednak, jako że nie chcemy ciągle biec w miejscu (tworząc nowe wersje, których jedyną cechą jest kompatybilność z najnowszą platformą), uaktualnianie wszystkiego jest zadaniem ogromnym i bardzo kosztownym.
• Cele priorytetyzowania aplikacji
  Ludzie mają bardzo różne poglądy na temat tego, co oznacza „aplikacja krytyczna dla biznesu”. Konieczne jest utworzenie celu procentowego albo określenie obiektywnych kryteriów wyjaśniających ten problem.

Mając na uwadze te cele, przyszedł czas, aby włączyć do pracy osoby po biznesowej stronie – tych, którzy wiedzą, jak i po co używane są konkretne programy. W małych organizacjach można rozmawiać z nimi kolejno. W większych przedsiębiorstwach można użyć np. portalu SharePoint do zebrania danych w celu wykorzystania ich w procesie analizy. I jak bardzo nie pragnęlibyśmy prostoty, musimy być pewni, że nie przeoczymy także takich informacji, jak „musimy utrzymać poprzednich siedem wersji tego oprogramowania do obliczania podatków, działającego gdziekolwiek, ze względu na wymogi prawa”.

Ważna wskazówka praktyczna: należy dostosowywać się do możliwości czasowych osób, które nie są oficjalnie członkami zespołu.

Jak uzyskać informacje, które są już znane na temat aplikacji? Informacje dotyczące oprogramowania komercyjnego są udostępniane w Windows Compatibility Center, ale trzeba dopasować naszą listę do danych z tej witryny. Narzędzie Application Compatibility Toolkit 5.5 pozwala wykonać to automatycznie.

Zasada „wczesnego i częstego przycinania” ma szerokie zastosowanie. Użycie drogiego zasobu do wyeliminowania aplikacji w ciągu 30 sekund jest mniej kosztowne, niż badanie jej przez godzinę za pomocą tanich narzędzi. Należy usunąć oczywisty szum przed uzyskiwaniem informacji od właścicieli biznesu i analizować tylko te aplikacje, które pomogli wybrać jako warte zachowania. Preferowane podejście do badania aplikacji przedstawia Rysunek 2 .

Rysunek 2: Wczesne filtrowanie listy aplikacji jest mniej kosztowne.

Jak dobrze działa takie podejście? U jednego z klientów zgromadziliśmy spis około 1200 aplikacji z 54 różnych komputerów. Podczas lunchu usunęliśmy oczywiste nadmiarowości (szum), zgodnie ze stosowanymi regułami biznesowymi. W ten sposób ograniczyliśmy listę do około 450 aplikacji i zapewne moglibyśmy wyeliminować więcej, gdybyśmy mieli więcej czasu. Dało to 700 nieistotnych aplikacji usuniętych z rozważań w ciągu godziny – co stanowiło znaczącą oszczędność kosztów.

Można teraz uściślić oszacowanie kosztów, opierając się na stanie pożądanym (docelowym). Można dodatkowo uściślić to oszacowanie dzięki znanemu stanowi kompatybilności dla ogólnie dostępnego oprogramowania komercyjnego, a być może wykorzystać narzędzia analizy statycznej, aby lepiej ocenić, co powinno działać czy też sprawiać problemy.

 Do początku strony

Testowanie

Kolejną rzeczą jest ustalenie, kto powinien być zaangażowany w proces testów. Możliwości do rozważenia obejmują:

• Wewnętrzne działanie zespołu
  Wymaga silnego menedżera projektu i eksperta technicznego, którzy będą kierować zespołem, gwarantując, że uda się skoordynować wiele ról (testerów, zespołów programistów, użytkowników, właścicieli i tak dalej).
• Zaangażowanie partnerów
  Wiele organizacji zachęca partnerów do udziału w procesie. Warto przemyśleć, gdzie będą pasowali (rozszerzenie ukierunkowanych umiejętności, rozszerzenie personelu, podejście produkcyjne itp.) i jak będą się integrować z naszymi użytkownikami podczas testowania funkcjonalności biznesowej.

Należy też zaplanować techniki, których zamierzamy użyć. Rozważyć można następujące technologie:

• Maszyny wirtualne
  Cofanie zmian na dysku i możliwości migawek pozwalają oszczędzić bardzo wiele czasu (na przykład w wypadku awarii „pierwszego uruchomienia” – błędów, które trwale niszczą stabilność maszyny).
• Terminal Services/Remote Assistance
  Rozwiązania te są bardzo przydatne podczas testów wykonywanych przez użytkowników, zapewniając łatwą i szybką metodę umożliwienia im dostępu do komputera Windows Vista. Ponadto Remote Assistance pomaga przy odtwarzaniu błędów i dalszych badaniach.
• Maszyny pilotowe
  Udostępnienie użytkownikom nowych, „wypasionych” laptopów w zamian za testowanie aplikacji może być bardzo motywujące.

Następnie sporządzimy mapę procesu testowania. Rysunek 3 ukazuje szkielet przebiegu pracy:

Rysunek 3: Proces testowania aplikacji.

Należy zrobić wszystko, aby zagwarantować, że nic oczywistego nie zepsuje się, zanim włączy się użytkowników do testów. Nie ma nic bardziej frustrującego, niż poproszenie błyskotliwego użytkownika o wizytę w laboratorium tylko po to, by zobaczył, jak instalator wywraca się na jego oczach.

Analogicznie należy upewnić się, że testerzy nie będą tracili czasu na sprawdzanie czegoś, czego nie mamy zamiaru naprawiać. Jeśli wsparcie techniczne jest wymagane, testujemy tylko wspiera wersje.

 Do początku strony

Korygowanie stanu

Aby testy były efektywne, musimy je wykonywać, pamiętając o konieczności naprawy. Awaryjną aplikację należy debugować do momentu ustalenia, do jakiego koszyka (typu naprawy) pasuje; po ustaleniu koszyka należy przestać.

Oczywiście, aby to osiągnąć, testerzy muszą wiedzieć, jakie koszyki są brane pod uwagę i w jakich okolicznościach. Należy więc skrótowo zdefiniować strategię naprawczą. Opcje rozważane w większości organizacji obejmują:

• Kupić nową.
  Rozwiązanie to niemal na pewno będzie działać i zapewnia wsparcie producenta (co może być istotne w przypadku niektórych aplikacji). Jest to zarazem jedno z najdroższych rozwiązań ze względu na koszty projektowania lub zakupu. Zazwyczaj rozwiązanie to jest wykorzystywane wówczas, gdy możemy sobie na nie pozwolić!
• Zastosować podkładkę.
  To jest droga oszczędnościowa – pomóżmy aplikacji poprzez modyfikację wywołań do systemu operacyjnego zanim one tam dotrą. Metodą tą można naprawić aplikację bez dostępu do kodu źródłowego, a nawet bez dokonywania w niej żadnych zmian. Wymaga to minimalnego nakładu dodatkowej pracy ze strony systemu (dla bazy danych podkładek) i można tą metodą poprawić znaczną liczbę aplikacji. Po stronie negatywów jest pomoc techniczna, jako że większość producentów nie zapewnia wsparcia w takiej sytuacji. Trzeba też zauważyć, że nie każdą aplikację można naprawić za pomocą podkładek. Większość ludzi zazwyczaj bierze pod uwagę tworzenie podkładek dla aplikacji, gdy jej producent już nie istnieje na rynku, program nie jest wystarczająco strategiczny, aby wymuszał dostępność pomocy technicznej, albo gdy po prostu chcą zyskać na czasie.
• Zmienić zasady.
  Jeśli określona funkcja ulega awarii w wielu aplikacjach, można próbować wyłączyć tę funkcję. Korzyści są podobne do korzystania z podkładek – nie musimy zmieniać ani nawet mieć dostępu do kodu źródłowego. Wady również są analogiczne – brak pomocy technicznej i niezdolność do naprawienia wszystkiego. Wiele osób uwzględnia to podejście dla aplikacji sieci Web, gdzie podkładki nie wchodzą w grę. Niektóre funkcje zabezpieczeń mogą być sterowane indywidualnie i wyłączone jako rozwiązanie łatające dziury. Typowym rozwiązaniem jest wyłączenie trybu chronionego dla strefy Local Intranet (co Internet Explorer 8 robi domyślnie). Trzeba jednak zauważyć, że za każdym razem, gdy modyfikujemy domyślne zabezpieczenia systemu, należy tę decyzję traktować bardzo poważnie. Na przykład wyłączenie UAC może przetrzebić korzyści biznesowe wynikające z migracji do nowego systemu operacyjnego.
• Wirtualizacja aplikacji.
  Istnieje wiele nieporozumień na temat wirtualizacji aplikacji jako rozwiązania problemów kompatybilności. Słyszałem już opisywanie tego rozwiązania jako kompletnego odseparowania aplikacji od systemu, a tym samym jako rozwiązania całkowicie odpornego na błędy. Mówiąc dobitnie – nie jest to prawda. Z wyjątkiem odwołań do systemu plików i rejestru, aplikacja nadal wywołuje system operacyjny i każdy problem kompatybilności poza obszarem systemu plików lub rejestru pozostaje nietknięty. Jest to doskonałe rozwiązanie w przypadku konfliktów pomiędzy aplikacjami, ale nie ogólne rozwiązanie dla konfliktów pomiędzy aplikacją a systemem. Stan pomocy technicznej jest nieznany, ale prawdopodobnie nie wzbudza zachwytu, jako że nie każda firma zapewnia wsparcie dla oprogramowania pracującego w trybie wirtualnym, nawet jeśli wspiera je przy działaniu natywnym. Typowe sytuacje, w których firmy decydują się na użycie tego rozwiązania, to: gdy problemy dotyczą komunikacji z systemem plików lub rejestrem, gdy problem jest powodowany konfliktem z inną aplikacją, a także wtedy, gdy po prostu podoba im się wirtualizowanie aplikacji i czystym przypadkiem pozwoliło to również naprawić problem kompatybilności.
• Wirtualizacja maszyny oraz usługi terminalowe.
  Wirtualizacja komputera to rozwiązanie siłowe. Wiemy, że aplikacja będzie działać, gdyż faktycznie używamy jej we wcześniejszej wersji systemu operacyjnego – na komputerze lokalnym czy gdzieś na serwerze. Niemal zawsze też zapewnia to wsparcie techniczne, gdyż w istocie program ten będzie uruchamiany we wcześniejszym – wspieranym – systemie. Jednak, choć niektórzy mówią „zwirtualizujmy wszystko, wykonajmy migrację dziś, a naprawimy to później”, wolę być ostrożniejszy. Podejście to łączy się z dodatkowym obciążeniem dla administratorów, gdyż potencjalnie trzeba będzie zarządzać podwójną liczbą systemów operacyjnych na każdego użytkownika. Aby użyć wirtualizacji lokalnej, konieczne będą maszyny o zasobach (szczególnie pamięci) wystarczających dla obsługi dwóch równocześnie działających systemów operacyjnych. Wrażenia użytkowników również nie zawsze są zadowalające, bo większość ludzi popada w zakłopotanie, widząc dwa przyciski Start (jakkolwiek istnieją rozwiązania poprawiające to – zarówno od firmy Microsoft, jak i z innych źródeł). Większość moich klientów traktuje to rozwiązanie jako ostatnią deskę ratunku w razie problemów z aplikacjami. W istocie wielu z nich określiło progi testowania; jeśli zespół naprawczy nie był w stanie rozwiązać problemu w czasie przewidzianym na każdą aplikację, zamiast ciągnięcia badań (być może w nieskończoność), po prostu przerywał i umieszczał aplikację w środowisku poprzedniego systemu operacyjnego.
• Wyrzucić to.
  Nie zapominajmy o tej opcji! Czasami nie warto naprawiać aplikacji o niewielkiej wartości dla biznesu albo nadmiarowego oprogramowania. Lepiej się go pozbyć.

 Do początku strony

Podsumowanie

Był to krótki spacer po najważniejszych uwarunkowaniach dotyczących planowania projektu badania zgodności aplikacji. Plany tworzyłem zarówno w jednym podejściu (generując kompletny plan projektu przed jego rzeczywistym rozpoczęciem), jak również pracowałem z klientami, którzy planowali każdą fazę dopiero po ukończeniu poprzedniej. Punktem krytycznym jest zrozumienie, co można zrobić na każdym etapie, aby oszczędzić czas i pieniądze w późniejszych fazach.

Jakkolwiek proces ten zawiera również aspekty inżynierskie, prawdziwym wyzwaniem pojawiającym się w takim projekcie jest zarządzanie ogromem danych i motywowanie ludzi, którzy wcale nie chcą pomóc. Te wskazówki i sugestie powinny odnieść skutek.

O autorze

Chris Jackson jest liderem technicznym zespołu Windows Application Experience SWAT w firmie Microsoft. Pracował z klientami korporacyjnymi na całym świecie, pomagając im wykryć przyczyny i zneutralizować skutki problemów zgodności, jak również zapewniając szkolenia i instrukcje na temat zagadnień kompatybilności aplikacji Windows. Prowadzi własny blog, dostępny pod adresem blogs.msdn.com/cjacks.

Do początku strony