Udostępnij za pośrednictwem

Definiowanie wizji

  • Artykuł

 

Mary Kirtland
Microsoft Corporation

10 stycznia 2001 r.

W zeszłotygodniowej kolumnie przedstawiliśmy zespół wskazówek dotyczących usług internetowych i naszą misję: kompilowanie, wdrażanie i obsługę przykładowych usług sieci Web w celu zilustrowania rodzajów problemów, które należy wziąć pod uwagę podczas wykonywania tych samych czynności. Wprowadziłem również nasz pierwszy przykładowy projekt , usługę Ulubione.

Dziękujemy wszystkim za twoje komentarze i opinie. Śledzimy problemy, które zgłaszasz, więc zachowaj 'em najbliższych!

Ktoś zapytał, dlaczego wydanie próbki potrwa trzy miesiące i dlaczego nie zaczęliśmy od niego, zanim ogłosiliśmy pomysł. W rzeczywistości pracujemy nad ulubione prawie w pełnym wymiarze godzin w ciągu ostatnich dwóch miesięcy. Wiele funkcji jest, dobrze, działa... ale jest jeszcze trochę pracy do zrobienia, zanim wszystko jest spakowane ładne i schludne do próbki można zainstalować na własnych maszynach lub wypróbować przez Internet. Pisanie, przegląd techniczny, edytowanie i przetwarzanie wszystkich artykułów, które chcemy dostarczyć z naszymi przykładowymi źródłami, zajmuje trochę czasu. Dlatego dążymy do trzech miesięcy cykli projektów. Trzymamy kciuki, że będziemy mogli uzyskać pierwszą wersję Ulubione kiedyś w lutym. (Jak piszę to, zespół przechodzi przez ćwiczenie planowania, aby uzyskać lepsze oszacowanie daty wydania).

Niektóre komentarze zakładają również, że używamy .NET Framework do opracowania tego przykładu. Niekoniecznie tak jest. Użyjemy dowolnych technologii, które uważamy za najlepsze dla tej pracy. I najlepiej nie zawsze oznacza technicznie lepsze, łatwiejsze do użycia, lub większość w wiadomościach. Cokolwiek wybierzemy, poinformujemy Cię, dlaczego i poinformujemy Cię, jakie problemy wystąpiły, gdy próbowaliśmy go użyć.

W tym tygodniu zaczniemy przyglądać się problemom, które napotkał nasz zespół podczas tworzenia usługi Ulubione. Istnieje dość zaległości, ale zaczniemy od początku: ustalenie celów i celów projektu.

Getting Started

W modelu przetwarzania platformy rozwiązań firmy Microsoft pierwsza faza w każdym projekcie to faza aprowizacji. W fazie planowania zespół projektu i klienci tworzą ogólny widok celów i ograniczeń projektu. Podstawowym elementem dostarczanym z tej fazy jest dokument wizji, który zawiera analizę problemu biznesowego, opis celów produktu, zarys koncepcji rozwiązania, profile użytkowników produktu, cele projektu i definicję zakresu projektu. Faza wyobrażania kończy się punktem kulminacyjnym zatwierdzonego punktu kontrolnego wizji/zakresu .

Nasz zespół zaczął od nietypowego punktu początkowego: wiedzieliśmy, że chcemy napisać usługę internetową, ale nie mamy na uwadze żadnej konkretnej domeny problemu ani nie mieliśmy istniejących aplikacji, których musieliśmy użyć. Więc pierwszą rzeczą, którą musieliśmy zrobić, było wymyślenie rozsądnie realistycznego scenariusza biznesowego, który mógłby uzasadnić utworzenie skalowalnego, niezawodnego itp., itp. Usługa sieci Web.

Zaczęliśmy od zablokowania wielu osób w pokoju i burzy mózgów potencjalnych firm lub branż, usług i problemów technicznych, które byłyby dobrymi tematami w celu uzyskania wskazówek. Po drodze wymyśliliśmy kilka powodów, dla których warto utworzyć usługi sieci Web:

  • Jesteś źródłem danych wrażliwych na czas lub sparametryzowanych, których użytkownicy końcowi lub inne firmy chcą używać. Jeśli dane nie zmieniają się często, a klienci prawie zawsze chcą wszystkich danych, możesz również opublikować dokument XML w witrynie sieci Web. Jeśli jednak klienci chcą wykonywać zapytania względem danych, usługa sieci Web ma wiele sensu. Jeśli chcesz wypychać dane do klientów, operacje subskrypcji i powiadomień są również potencjalnymi usługami sieci Web.
  • Implementujesz algorytmy, których inne firmy nie mogą zaimplementować. W takim przypadku każdy algorytm jest potencjalną usługą sieci Web: klienci przekazują dane, odpowiadasz za pomocą odpowiedzi.
  • Agregujesz kilka innych usług, aby zapewnić usługę wyższego poziomu. W takim przypadku klienci korzystają z usługi, ponieważ udostępnia ona kombinację żądanych informacji, zapisując im pracę łączenia istniejących usług.
  • Chcesz zintegrować procesy firmy z partnerami. Każdy krok procesu biznesowego, który przechodzi przez granicę przedsiębiorstwa, jest potencjalną operacją usługi internetowej lub usługi internetowej.
  • Masz heterogeniczną i/lub geograficznie rozproszoną architekturę przedsiębiorstwa, w której korzystanie z sieci prywatnych lub ściśle powiązanych protokołów na potrzeby integracji aplikacji nie jest praktyczne. Interfejs API każdej aplikacji, którą chcesz zintegrować, jest potencjalną usługą sieci Web.
  • Udostępniasz usługi infrastruktury ("kanalizacji") dla innych deweloperów aplikacji internetowych i usług sieci Web, na przykład usługi tożsamości lub usługi rozliczeniowej. Zamiast tworzyć niestandardowe biblioteki interfejsów API dla każdej platformy klienckiej, możesz uwidocznić interfejs API jako usługę internetową.

Oczywiście z któregokolwiek z tych powodów należy również rozważyć, czy istnieje wystarczająca liczba potencjalnych klientów usługi, aby uzasadnić koszty jej wdrożenia i obsługi.

Szybko zdaliśmy sobie również sprawę, że podczas tworzenia przykładowych usług edukacji odbiorców deweloperów były pewne inne zagadnienia. Po pierwsze, scenariusze biznesowe nie powinny wymagać obszernej wiedzy na temat danej branży. Po drugie, chcemy mieć możliwość zainstalowania i uruchomienia przykładów na własnych maszynach. Po trzecie, wiele interesujących scenariuszy wymaga co najmniej jednego magazynu danych lub źródeł danych. Istnieje wiele problemów, jeśli chodzi o wysyłkę przykładowego kodu źródłowego, który pokazuje, jak uzyskać dostęp do źródeł danych, których nie posiadamy. Nie jesteśmy właścicielami żadnych źródeł danych... przynajmniej nie, że jesteśmy na wolności, aby rozdać próbkę.

Doprowadziło to nas do odejścia od scenariuszy, takich jak bankowość internetowa, kontrola głównego cyfrowego rejestratora wideo, sprawdzanie stanu lotu lub codziennego serwera komiksów do czegoś bardziej wzdłuż linii usługi infrastruktury. Zaczęliśmy myśleć o rodzajach usług sieci Web, które mogą świadczyć MSDN (rzeczywiste usługi, a nie przykłady). Jednym z pomysłów, że ludzie naprawdę lubili, był sposób na śledzenie artykułów MSDN, które chcieli znaleźć ponownie, niezależnie od tego, który komputer był używany do uzyskiwania dostępu do MSDN. To doprowadziło nas do idei ulubionych po stronie serwera.

Wizja, Rev 1

Gdy mieliśmy przybliżony pomysł na utworzenie usługi, utworzyliśmy wokół niej scenariusz biznesowy:

  • Szukamy sposobów rozszerzenia naszej bazy klientów na potrzeby naszej praktyki tworzenia aplikacji internetowych i generowania regularnego strumienia przychodów. Uważamy, że możemy osiągnąć oba cele, zapewniając wysokiej jakości usługi sieci Web, z których będą mogły korzystać witryny sieci Web. Ponieważ usługi sieci Web są nową koncepcją, uważamy, że potencjalni klienci będą musieli być przekonani, że mogą założyć część swojej działalności na nasze usługi. W związku z tym potrzebujemy usługi internetowej teaser, która:
    • Oferuje oczywistą wartość dla potencjalnych witryn sieci Web klientów.
    • Nie zapewnia usługi o znaczeniu krytycznym.
    • Pokazuje jakość naszych praktyk programistycznych i operacyjnych.
    • Można je zaimplementować i wdrożyć przy rozsądnych kosztach.

Oto pierwsze cięcie naszej wizji projektu:

  • The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. W drugiej fazie tego projektu będziemy licencjonować dodatkowe usługi w witrynach sieci Web. Na przykład:
    • Statystyki dotyczące stron z ich witryn są zakładkami.
    • Zalecane linki oparte na analizie koligacji wszystkich ulubionych użytkowników.

Z perspektywy technicznej ten scenariusz wyglądał tak, jakby dotyczył wielu pytań, które słyszeliśmy od klientów. Logika biznesowa nie wyglądała zbyt ciężko, aby zaimplementować — lub zbyt trudno wyjaśnić naszym czytelnikom. Ale gdy oświadczenie o wizji zostało zapisane dla wszystkich, aby spojrzeć, niektóre duże czerwone flagi poszły w górę:

  • Potrzebujemy globalnego schematu identyfikacji użytkowników, schematu na tyle wspólnego, że witryny sieci Web będą mogły przekazać identyfikator użytkownika do naszej usługi.
  • Jak uwierzytelniać użytkownika końcowego, gdy żądania pochodzą z witryny sieci Web, a nie bezpośrednio od użytkownika końcowego? Brzmi to tak, jakbyśmy potrzebowali delegowania lub musielibyśmy ufać witrynom sieci Web, aby wysyłać żądania tylko w imieniu użytkownika, gdy użytkownik końcowy rzeczywiście korzysta z witryny.
  • Czy dowolna witryna sieci Web powinna mieć możliwość pobierania ulubionych użytkowników końcowych, które zostały dodane z innej witryny sieci Web? Jeśli tak, czy chcemy zezwolić dowolnej witrynie sieci Web na korzystanie z naszej usługi, czy powinniśmy ograniczyć dostęp do usługi do licencjonowanych witryn? Zezwolenie dowolnej witrynie na dostęp do wszystkich danych przechowywanych w usłudze Ulubione bez żadnych danych wejściowych od użytkownika końcowego brzmi jak ogromny problem z prywatnością.
  • Podobnie co zrobić, jeśli nasza usługa internetowa dostarczyła metody aktualizacji w celu zachowania ulubionych informacji użytkownika. Czy jedna witryna sieci Web powinna mieć możliwość modyfikowania ulubionych użytkowników końcowych dodanych z innej witryny sieci Web?
  • Czy użytkownicy końcowi nie krzyczą i krzyczą, gdyby dowiedzieli się, że robimy takie rzeczy jak analiza koligacji na ich danych zebranych z wielu witryn sieci Web? Jak oni nawet wiedzieli, że te strony korzystały z naszej usługi? Czy musimy zrobić coś takiego, jak wymaganie od użytkownika końcowego zarejestrowania się w naszej usłudze i ustawienia preferencji prywatności, zanim jakakolwiek witryna będzie mogła uzyskać dostęp do swoich danych? Jak użytkownik końcowy będzie wiedział, aby zarejestrować się u nas?

Być może niektóre dodatkowe badania były w porządku.

Wizja, Rev 2

Po zapoznaniu się ze wszystkim, co mogę znaleźć na temat prywatności użytkowników, spędziłem kilka godzin z członkiem firmowej grupy prywatności firmy Microsoft omawiając scenariusze potencjalnie włączone przez naszą usługę i implikacje dotyczące prywatności. Zrobiłem stronę po stronie notatek i nadal było kilka otwartych problemów. Ale scenariusze, w których jedna witryna może uzyskać dostęp do danych dodanych z innej witryny, brzmiała okropnie kostką z perspektywy prywatności. To nie znaczy, że nie powinny być dozwolone, tylko że trudniej jest napisać dokładną, ale zrozumiałą politykę prywatności, aby uwzględnić te scenariusze, a użytkownicy końcowi mogą nie być zadowoleni ze scenariuszy.

Przeprowadziliśmy również wstępne badania dotyczące problemu z uwierzytelnianiem. Obecnie nie ma dobrego sposobu na globalną identyfikację i uwierzytelnianie użytkowników za pośrednictwem Internetu, gdy aplikacja jest w środku. Usługa Microsoft Passport działa świetnie, gdy użytkownik korzysta z witryny sieci Web za pośrednictwem przeglądarki. Nie ma jednak bezpiecznego sposobu przekazywania poświadczeń użytkownika do innej witryny sieci Web. Co z funkcją logowania jednokrotnego usługi Passport, w której użytkownicy nie muszą ponownie wprowadzać swoich nazw użytkowników i haseł po przejściu do innej witryny obsługującej usługę Passport? Korzysta to z przekierowań po stronie klienta. Nasza usługa internetowa nigdy nie komunikuje się bezpośrednio z maszyną użytkownika końcowego.

Na podstawie tych wstępnych badań postanowiliśmy wdrożyć Ulubione w fazach. Dałoby to nam więcej czasu na rozwiązanie skutków prywatności, a może usługa sieci Web tożsamości, która została wymieniona kilka razy na zeszłorocznym kontrolerze PDC, będzie dostępna do czasu, gdy potrzebujemy globalnego schematu tożsamości.

Nasza poprawiona wizja wygląda następująco:

  • Wdrożymy i wdrożymy usługę sieci Web Ulubione podczas CY2001, która umożliwi użytkownikom końcowym dodawanie wybranych stron z witryn sieci Web do późniejszego dostępu. Te ulubione będą przechowywane przez usługę Ulubione, więc są one dostępne z dowolnego komputera lub urządzenia, z którego korzysta użytkownik końcowy.
  • Usługa Ulubione będzie używana do anonsowania potencjalnych klientów, a tym samym musi być wysoce dostępną, skalowalną, bezpieczną usługą, która prezentuje zaangażowanie firmy w jakość i prywatność osobistą.

Puryści mogą twierdzić, że jest to zbyt długie, aby być oświadczeniem wizji. Ważne jest jednak to, że każdy to rozumie, cokolwiek chcesz to nazwać.

Zdefiniowaliśmy takie fazy:

  • W fazie pierwszej wdrożymy i wdrożymy usługę sieci Web Ulubione, która może być licencjonowana dla deweloperów witryn sieci Web do użycia w tle w celu zarządzania ulubionymi klientami. (Skutecznie każdy licencjobiorca ma prywatny magazyn danych ulubionych użytkowników). Udostępnimy również przykład pokazujący, jak zintegrować usługę Ulubione z witryną sieci Web. Usługa i przykład będą dostępne do licencjonowania do 1 marca 2001 r. Naszym celem jest licencja usługi do 1 marca 2001 r. do pięciu do 10 witryn reprezentujących około 10 000 nowych użytkowników końcowych miesięcznie. (Uważamy, że jest to możliwy do opanowania wskaźnik wzrostu, biorąc pod uwagę nasz obecny personel).
  • W fazie drugiej wdrożymy rozszerzenia przeglądarki dla programów Internet Explorer i Netscape Navigator, które zapewnią użytkownikom końcowym bezpieczny sposób zarządzania swoimi ulubionymi witrynami sieci Web w taki sam sposób, jak obecnie zarządzają ulubionymi po stronie klienta. Zaimplementujemy również i wdrożymy witrynę sieci Web, których użytkownicy końcowi mogą używać do zarządzania swoimi ulubionymi użytkownikami, odczytywania naszych zasad zachowania poufności informacji, ustawiania opcji profilu użytkownika dotyczących używania ich danych osobowych i pobierania rozszerzeń przeglądarki. Rozszerzenia przeglądarki i witryna internetowa zostaną dostarczone do 1 maja 2001 r. Naszym celem jest osiągnięcie 1000 nowych użytkowników końcowych miesięcznie.
  • W fazie trzeciej rozszerzymy usługę sieci Web Ulubione, aby użytkownicy końcowi mogli zobaczyć zarówno ulubione, które zostały zapisane bezpośrednio (za pośrednictwem dodatku przeglądarki lub witryny sieci Web Ulubione), jak i ulubionych, które zostały zapisane za pośrednictwem licencjonerów usługi Ulubione. Licencjobiorcy będą mieli możliwość wyświetlania specjalnego logo, które informuje użytkowników końcowych, że jest używana usługa Ulubione doradztwo (i dlatego te ulubione będą również dostępne za pośrednictwem dodatku przeglądarki lub witryny sieci Web Ulubione). Licencjobiorcy mogą również nadal korzystać z usługi Ulubione w tle, w takim przypadku ulubione przechowywane za pośrednictwem tej witryny nie będą dostępne za pośrednictwem dodatku przeglądarki lub witryny sieci Web Ulubione. Faza trzecia zostanie dostarczona do 1 czerwca 2001 r.
    Faza trzecia stanowi podstawę przyszłych usług sieci Web. Jeśli na przykład użytkownik odwiedzi stronę sieci Web, witryna może wyświetlić listę stron sieci Web, które również polubiły inne osoby, które polubiły tę stronę. Witryna sieci Web pobiera listę stron z usługi sieci Web. Nie zdecydowaliśmy jeszcze, czy zaimplementować tego typu usługę profilowania.

Mając to na celu, moglibyśmy ominąć resztę dokumentu Vision.

Następnym krokiem było zdefiniowanie niektórych profilów użytkowników. Podczas definiowania wizji projektu usługi internetowej należy dokładnie zastanowić się nad tym, kim są wszyscy użytkownicy. Kategorie użytkowników, które zidentyfikowaliśmy podczas fazy aprowizacji, to:

  • Użytkownicy końcowi — każdy, kto używa przeglądarki sieci Web do odwiedzania witryn sieci Web.
  • Licencje — każda firma z witryną sieci Web korzystającą z usługi Ulubione.
  • Deweloperzy licencjonowania — deweloperzy tworzący witrynę sieci Web licencjonera.
  • Operatorzy licencjonatorów — operatorzy witryny sieci Web licencjobiorcy.
  • Operatorzy — osoby odpowiedzialne za obsługę usługi Ulubione.

Pełne profile użytkowników można przeczytać w dokumencie obrazów Ulubione, który towarzyszy tej kolumnie. Okazuje się, że brakowało nam kilku kategorii: menedżerów i menedżerów licencjonowanych. Zostały one przycięte, gdy zaczęliśmy myśleć o wymaganiach dotyczących raportowania. Prawdopodobnie powinniśmy podzielić testerów jako oddzielną kategorię. Ta lista powinna stanowić dobry punkt wyjścia dla większości projektów usługi sieci Web.

Poświęciliśmy również trochę czasu na zastanowianie się nad celami biznesowymi i celami projektowania. Jedną z głównych pytań jest: Dlaczego tworzysz usługę internetową? Czy próbujesz zarabiać pieniądze? Próbujesz usprawnić procesy biznesowe? Czy coś innego w ogóle? Niezależnie od tego, co zdecydujesz, może to mieć wpływ na twoje wymagania. Na przykład główne cele usługi Ulubione to:

  • Zaprezentuj nasze zaangażowanie w produkty wysokiej jakości.
  • Unikaj złej prasy ze względu na zawodną usługę, problemy z zabezpieczeniami lub problemy z prywatnością osobistą.

Ta kombinacja celów dodała znaczną liczbę wymagań dotyczących naszej usługi, zwłaszcza w obszarach licencjonowania i wymagań dotyczących możliwości (skalowalność, dostępność itd.). Ale zarabianie pieniędzy jest kompletnym celem dla tego projektu. Gdyby był to cel, wiele z naszych wymagań licencyjnych wyszłoby nieco inaczej.

Z perspektywy projektu należy zastanowić się nad ogólną filozofią dotyczącą prywatności, zabezpieczeń i innych wymagań niefunkcjonalnych. Należy również rozważyć, czy klienci na całym świecie będą korzystać z usługi internetowej i co oznacza to globalizację i lokalizację. Na przykład kilka naszych celów projektowych to:

  • Dostarczanie rozwiązania na całym świecie. Usługa i wszystkie aplikacje pomocnicze muszą zostać zglobalizowane.
  • Dostarczanie niezawodnej, bezpiecznej usługi. Usługa musi być wysoce dostępna, nie może utracić danych i musi zezwalać tylko na dostęp autoryzowanych użytkowników.

Pozostałe cele biznesowe i cele projektowe można znaleźć w dokumencie Ulubione przetwarzanie obrazów.

Podsumowanie

Zawsze łatwiej jest wiedzieć, kiedy skończysz z projektem, jeśli zespół projektu i twoi klienci zgodzili się z ogólnymi celami, celami i zakresem z góry. Nawet jeśli uważasz, że po prostu dodajesz fronton usługi internetowej do istniejącej witryny sieci Web, warto z czasem napisać dokument wizyjny. Dlaczego dodajesz fronton? Kogo oczekujesz, że go użyjesz? Ile dodatkowego obciążenia będzie można umieścić w witrynie, których ludzie nie oczekują?

Pisanie dokumentu wizji dla ulubionych było dla nas cennym ćwiczeniem. Bez tego przegapilibyśmy co najmniej połowę wymagań, które zostały spełnione w naszej specyfikacji funkcjonalnej. Na przykład prawdopodobnie nie rozpoznalibyśmy problemów z prywatnością i bezpieczeństwem dopiero w dalszej części gry. Dokument Vision robi też inne rzeczy dla nas. Daje nam to metrykę do oceny żądań funkcji i określania priorytetów wymagań. Dokument przypomina nam, co chcemy zrobić w przyszłych fazach — możemy to uwzględnić w przykładowym projekcie, abyśmy nie musieli całkowicie ponownie pisać rzeczy w dół drogi.

W przyszłym tygodniu przyjrzymy się problemom z prywatnością wymienionymi tutaj bardziej szczegółowo. Poinformuję Cię, czego nauczyłem się od naszej korporacyjnej grupy prywatności, porozmawiam o trudnych problemach, które odroczyłyśmy, i omówię kwestie prywatności, które pozostają w fazie pierwszej i jak mają one wpływ na nasz projekt i implementację.

Zobacz to!

Mary Kirtland jest architektem zespołu wskazówek dotyczących usług sieci Web MSDN, gdzie robi wszystko, ale koduje, testuje lub wykonuje operacje, w tym próbuje zachować aktualność specyfikacji, zapisując wszystko, czego zespół nauczył się w artykułach dla MSDN, zadając irytujące pytania podczas przeglądów i zamawiania lunchu.