Wybór zgodności ze standardami zamiast praktyk własnościowych

UWAGA: Tłumaczenie tej strony nie zostało zakończone.
Może być ona niekompletna lub wymagać korekty.
Chcesz pomóc? | Dokończ tłumaczenie | Sprawdź ortografię | Więcej takich stron+.

Wstęp

Istnieje pewna liczba standardów, procedur oraz procesów, którą każda organizacja może wykorzystać. Na wyższym poziomie istnieją dwa podstawowe typy standardów: proceduralny (jak my to robimy) oraz techniczny (czym się kierujemy). Organizacje wdrażają wewnętrzne standardy proceduralne, aby móc wydajnie działać. Mogą także wdrażać zewnętrzne procedury oraz/lub standardy techniczne. Techniczne standardy tradycyjnie były wprowadzane przez konsorcja lub ciała standaryzujące. Standardy techniczne mogą być zarówno publiczne, oparte na standardach lub własnościowe. Celem tego dokumentu jest omówienie i podkreślenie wagi wsparcia otwartych standardów technologicznych, które są zewnętrzne względem organizacji. Jednak zacznijmy dyskusję od spojrzenia w głąb wewnętrznych procedur, procesów i standardów.

Czemu organizacje powinny mieć standardowe procedury na każdym poziomie? Kierowanie się standardami nie jest niczym nowym; organizacje wymagają od swoich pracowników, aby trzymali się pewnych zasad lub zestawu standardów na okrągło. Pagery, karty czasowe, procedury kontroli kont to wszystko są standardy na poziomie grup.

W świecie programowania istnieje potrzeba standardów, ponieważ aplikacje są tworzone między wieloma grupami programistów. Wiele organizacji upublicznia swoje wewnętrzne standardy i procedury programistyczne. Na przykład, organizacja może zdecydować, że C++, Java i JavaScript będą jej podstawowymi językami programistycznymi. Mogą wymagać, aby każdy projekt posiadał Dokumenty Wymagań Marketingowych, Dokumenty Wymagań Produktu, Dokumenty Wymagań Funkcjonalności, Plany Testów Kontroli Jakości i Dokumenty Certyfikujące.

Wraz z rozwojem organizacji, rośnie potrzeba tworzenia procesów zapewniających więcej kontroli, która pozwala łatwiej planować i przewidywać. Z procesami organizacje mogą tworzyć harmonogramy wydań, wdrażać plany marketingowe, analizować rozdział zasobów i wprowadzać poprawki w razie konieczności. Zawierzenie standardom i procesom może wprowadzić dodatkowy poziom elastyczności, ponieważ programowanie staje się przewidywalne. Dodatkowo, standardowe procesy zwiększają zrozumienie przebiegu tworzenia oraz pozwalają ograniczyć koszty.

Popularne procesy rozwojowe

Kiedy organizacja rozrasta się, menedżerowie i inżynierowie spostrzegają jak ważne jest pilnowanie tych procesów. Kiedy zespół przedstawia projekt, następuje jego ocena pod względem kompatybilności projektu z całkowitą strategią budżetową. Pion marketingu musi następnie przeanalizować możliwości promocyjne danej aplikacji/produktu, a następnie przeprowadzić dogłębną techniczną ocenę aplikacji oraz badania rozwojowe. Jeżeli projekt zostaje zaakceptowany, zebrane informacje, analizy i badania są wiązane w tzw. Request For Proposal (RFP).

Taka sytuacja zdarza się dość często: większość organizacji posiada podstawowy proces zarządzania projektem dla każdego produktu lub usługi. Wewnętrzne procesy organizacji są dobrze dopasowane do pracy w środowisku kulturowym danej firmy. Właśnie w takim momencie tworzy się standard rozwojowy - pojawia się konieczność przestrzegania go przez wszystkich.

Bardzo łatwo złapać się w pętlę ślepej realizacji założeń, zapominając po co organizacjom procesy. Przede wszystkim organizacje korzystają z nich, ponieważ to pozwala oszczędzić pieniądze, czas i zasoby. Są też inne powody - podział zadań, punkty kontrolne, harmonogramy itd. Końcowym efektem powinien być proces pozwalający zmaksymalizować wydajność organizacji.

Inne standardy

Ważne jest również, aby stosować się do innych standardów. Istnieje niezliczona ilość organizacji standaryzujących, które wpływają na to jak i dlaczego robimy to, co robimy. Na przykład w obszarze księgowości istnieje FASB (Financial Accounting Standards Board - Rada do Spraw Standardów Rachunkowości Finansowej) oraz IASB (International Accounting Standards Board - Rada ds. Międzynarodowych Standardów Rachunkowości). Oczekuje się od wszystkich firm i przedsiębiorstw, aby przestrzegały zasad ustalonych przez FASB. Gdy kontrolerzy oceniają sytuację finansową organizacji, robią to w oparciu o zasady FASB.

Wracając do rozwoju oprogramowania, istnieje wiele organów standaryzujących, mających wpływ na decyzje dotyczące tego procesu. Na przykład, jeśli jakaś firma tworzy aplikację internetową, powinna ona trzymać się standardów wyznaczonych przez następujące organizacje:

Podobnie jak procesy i standardy, które księgowi i menedżerzy projektu muszą przestrzegać, wyżej wymienione organizacje wyznaczają drogę, jaką muszą się kierować inżynierzy rozwoju. Przez podążanie tymi wytycznymi firmy takie jak AOL mogą polepszyć doświadczenia użytkownika, interoperacyjność, użycie kodu, dzielone zasoby oraz popularność - wraz z jednoczesną redukcją kosztów. Omówię każdy z tych elementów poniżej.

Interoperacyjność

Kluczem do interoperacyjności jest wybór standardu o możliwościach długotrwałego zastosowania. Organizacje muszą być pewne, że standard, który zdecydują się wdrożyć do procesu rozwoju, będzie odpowiedni również w przyszłości. Innymi słowy musi on posiadać długoterminowy potencjał. Fundamentalnym błędem popełnianym przez większość organizacji jest użycie własnościowych metod, oprogramowania, kodu lub standardów. Dla wielu z nich podążanie drogą własnościową okazało się katastrofalne w skutkach.

Dobry przykład: korporacja Xerox. Gdy we wczesnych latach 80 zaprojektował on i rozpoczął rozwój systemu Star Office, Xerox niewątpliwie wykraczał ponad swoje czasy. Była to elegancka stacja robocza z pulpitem zaprojektowanym przez inżynierów z PARC (Palo Alto Research Center - Ośrodek Badawczy Palo Alto). System Star Office oferował funkcjonalność, z którą nie mógły się równać zarówno oferty Microsoftu jak i firmy Apple.

Inżynierzy zaprojektowali Stara na własnościowym systemie operacyjnym znanym pod nazwą Pilot. Pilot posiadał wysoce zintegrowane narzędzie debugujące zwane Co-pilot, które pozwalało Xeroksowi na szybkie i łatwe debugowanie wielu błędów. Jednak tym, co Xerox pominął, było zrozumienie, że pomimo potęgi oprogramowania Pilot i Co-pilot, stacja robocza Star nie mogła rozwijać się w czasie, ponieważ była ona własnościowa. Xerox był ograniczony do unikatowej platformy sprzętowej oraz do zamkniętego systemu operacyjnego. I Xerox zdecydował się pominąć wiele okazji do przeniesienia kodu na inne platformy oraz do dostarczenia otwartego kodu źródłowego. W konsekwencji Xerox musiał ostatecznie zamknąć produkcję stacji roboczej z powodu zmniejszającego się popytu oraz rosnących kosztów rozwoju.

Największy atut Xeroksa stał się przyczyną jego upadku. Wybrał on środowisko własnościowe i przegapił okazję, aby ze środowiska tego zrobić wzorzec - i ustanowić je jako standard.

Podążanie otwartymi standardami posiada dodatkową zaletę. Gdy konieczne jest, aby organizacje oddziaływały ze sobą poprzez sojusze, fuzje lub przejęcie, integracja i interoperacyjność jest znacznie mniej kosztowna, jeśli każdy z zainteresowanych podmiotów przestrzega standardów od początku. Zgodność standardów znacząco redukuje ilość potrzebnej pracy oraz zapewnia zgodne i przewidywalne zachowanie obu podmiotów.

Doświadczenia użytkownika i popularność

Zachowanie klientów i ekspansja rynku są najważniejsze. Gdy klienci decydują się na wybór konkretnego produktu, należy im dostarczyć pozytywnych doświadczeń z niezawodnym, logicznym i przewidywalnym postępowaniem. Z czasem, gdy gust użytkowników stanie się bardziej wyrafinowany, a dodatkowe urządzenia lepiej dostępne, będą oni dochodzić do źródła informacji poprzez różne sposoby - i oczekiwać, że będą one wyglądać i działać w ten sam sposób – niezależnie od tego, czy będą oglądać stronę ze swojego komputera, telefonu komórkowego czy innego podręcznego urządzenia. W rezultacie jeśli organizacja oferuje pakiet produktów, musi ona upewnić się, że doświadczenia użytkownika są zgodne i przewidywalne w zakresie wszystkich produktów.

Zgodność

Aby osiągnąć sukces, organizacja musi zrozumieć oczekiwania użytkownika i dostarczyć mu zgodnych doświadczeń w zakresie oferowanych produktów. Gdy użyteczność zmienia zbyt wiele ponad produktami, użytkownik zaczyna narzekać.

Apple i Microsoft bardzo dobrze pojęli tę lekcję. Gdy użytkownicy Macintosha przeszli z MacOS 8.x na MacOS 9.x przemiana interfejsu i pulpitu była właściwie niezauważalna. Użytkownicy mogli szybko przenieść się z jednej wersji na kolejną. Jednak gdy został wydany Mac OS X, Apple całkowicie przerobił wygląd interfejsu i pulpitu. Ta zmiana wywołała całkiem duże zamieszanie w społeczności użytkowników Apple'a. Uczyniło to system kłopotliwym w obsłudze, jednak nie na tyle, by użytkownicy nie mogli się dostosować. Apple otrzymał pozytywne jak i negatywne opinie; stracili oni również paru użytkowników, zyskując ostatecznie również nowych.

Przykład tego jak zgodne doświadczenia użytkownika pozwalają na zyskanie jego przywiązania, dostrzec można w tym jak Microsoft zapewnia uogólnione zachowanie pomiędzy aplikacjami. Przykładowo w Wordzie, Excelu i innych aplikacjach Windows wiemy, że naciśnięcie kombinacji CTRL+C w dowolnym produkcie Microsoftu oznacza kopiowanie, Zachowanie to, zgodne i przewidywalne, w rezultacie stało się de-facto standardem. Przyczyną zgodności i przewidywalności jest to, że Microsoft ustanowił firmowy zbiór standardów użyteczności i obsługuje istotne standardy międzynarodowe.

Dostępność

Żadna organizacja nie może sobie pozwolić na pomijanie lub ignorowanie standardów dostępności. W środowisku sieciowym standardy dostępności są ściśle powiązane z HTML-em, XML-em, XHTML-em i innymi standardami W3C. Poprzez wcielanie i popieranie wytycznych dostępności, organizacja jest w stanie zaoferować swoją linię produktów lub usług większej i bardziej zróżnicowanej grupie użytkowników.

Zamienność

Jeśli użytkownik doświadcza zgodnego zachowania w wielu produktach, może on przewidzieć w jaki sposób konkretna czynność lub funkcja zadziała lub jaki będzie miał efekt. Dla dostawcy produktu celem powinien być jak najmniejszy element zaskoczenia. Poprzez zaszczepianie zbioru globalnych celów i standardów w infrastrukturę organizacyjną, organizacja zapewnia swoim użytkownikom końcowym zdolność do interakcji, funkcjonowania, obserwowania i przetwarzania informacji w sposób zgodny w miarę ich przechodzenia z jednego urządzenia do drugiego.

Znaczącą wadą istnienia rozbieżności między aplikacjami jest to, że informacje muszę być powielane, zmieniane lub manipulowane, aby możliwe było ich przetworzenie w rozbieżnych aplikacjach. Stwarza to również problem, jeśli chodzi o narzędzia autorskie dla tych różnych aplikacji. Przykładowo powiedzmy, że mamy kilka ofert aplikacji, które mogą być użyte do przeglądania sieci. Każde z tych aplikacji podążała własną drogą rozwoju i wspierania standardów. Mogą one obsługiwać część międzynarodowych standardów, ale nie w pełni. Które narzędzia powinniśmy użyć? Czy finansowo nie będzie rozważnym krokiem rozwijanie własnościowych narzędzi autorskich dla każdej z tych aplikacji? Jaki w tym przypadku będzie stopień przyswojenia przez rynek kompletu tych aplikacji? W jaki sposób organizacja może zgodnie zyskać udziały na rynku, jeśli jej oferty produktów nie są zintegrowane? I co ważniejsze, co jeśli w ocenie użytkownika jej produkt nie jest zamienny?

Zasoby dzielone

Gdy organizacja zaszczepia ogólnofirmową politykę standardów dzielonych, może ona przenosić zasoby inżynierii między różnymi projektami. Inżynierowie rozwoju mogą przemieszczać się między projektami w sposób łatwiejszy i z niewielkim lub nawet żadnym przestojem w pracy. Praktyki kodowania są zgodne. Oczekiwania są znane. Istnieje równoważna funkcjonalność pomiędzy aplikacjami oferowanymi przez organizację. I inżynierowie mają większą podstawę doświadczenia, co czyni ich bardziej wartościowymi wewnątrz organizacji.

Na przykład jeśli oczekuje się, że aplikacja internetowa będzie zgodna ze standardami W3C, oczekuje się również, aby każdy inżynier znał i rozumiał te standardy. Wysiłki mające na celu rozwój będą w konsekwencji wspierać podobne poziomy wspierania standardów, co prawdopodobnie doprowadzi kodowania wieloaplikacyjnego lub ponownego użycia danego kodu.

Przykładowo jeśli inżynier rozwoju pisze aplikację spełniającą standard ANSI języka C i C++ oraz pisze kod działający na konkretnej platformie, kod ten może być skompilowany na dowolnej platformie i systemie operacyjnym wspierającym standardy ANSI. Produkty Microsoft są trudne do wyeksportowania, ponieważ wprowadzają one bibliotekę MFC (Microsoft Foundation Classes), która jest standardem działającym tylko na systemie Windows i nie przestrzega ona zasad ANSI.

Kontrola jakości

Z doświadczenia wiemy, że bez rygorystycznych testów nasze produkty mogą fatalnie zawieść po ich wprowadzeniu na rynek. Wsparcie techniczne jest kosztowne, nie tylko w związku z kosztami zatrudnienia odpowiedniej kadry, ale również z powodu potencjalnego niezadowolenia klienta.

Dlatego właśnie organizacja musi również stosować standardy podczas kontroli jakości. Poprzez przyswojenie zbioru standardów, organizacja kontroli jakości może stworzyć zbiór zestawów testowych, które mogą zostać potem użyte między różnymi projektami. Poprzez ustandaryzowanie zestawów testowych, organizacja kontroli jakości może w łatwy sposób zarządzać, weryfikować i certyfikować testy oraz eliminować zbyteczne testowe bazy danych, w celu zapewnienia zgodności i niezawodności. Jak w przypadku inżynierów, standaryzacja pomaga inżynierom kontroli jakości w szybszym zyskiwaniu doświadczenia, a także w łatwości przenoszenia się pomiędzy projektami.

Podsumowanie

W czasach, gdy organizacje rozszerzają pole działania na coraz więcej urządzeń i platform, integracja i kompatybilność muszą być kluczowymi wymaganiami. Dążenie do stworzenia w przyszłości międzynarodowych standardów umożliwi codzienną realizację między-platformowych produktów. Akceptacja standardów pomoże nie tylko organizacjom, lecz także ułatwi odbiór końcowym użytkownikom aplikacji. Organizacje będą tworzyły produkty o lepszej jakości i przenośności, wyposażając wszystkich w elastyczne orpogramowanie. Ostatecznie, dzięki postępującej standaryzacji, organizacje będą łatwiej i trafniej oceniać postęp i wyniki wewnętrzne.

The most compelling dilemma is how an organization chooses to follow open external standards verses a proprietary de facto standard. Following proprietary de facto standards leaves an organization vulnerable and open to obsolescence when the owner of the de facto changes focus or direction, or abandons the de facto altogether and renders the standard stagnate. On the other hand, by adopting open technology standards and participating in the development and direction of those standards, an organization is providing a path for future development, growth and revenue.

Informacje o oryginalnym dokumencie

  • Autor(zy): Beth Epperson
  • Data ostatniej aktualizacji: 20 Feb 2003

Autorzy i etykiety dokumentu

 Autorzy tej strony: teoli, zarat, Mgjbot, Diablownik, Witia, Ptak82, Dria
 Ostatnia aktualizacja: teoli,