SDJ - Listopad 2012 ebook

Transkrypt

Spis treści
Praca z „Legacy Code” część 2 Przekleństwo
czy intelektualne wyzwanie? ....................................................................... 3
Grzegorz Gubiński
Wielu programistów nie chce pracować w projektach, w których głównym zajęciem jest utrzymanie produktu a nie jego rozwój. W przypadku takich projektów metafora produkcji oprogramowania wymyślona przez Alistaira Cockburna – gra bagienna – ma zdwojoną siłę przekazu. Programiści pracujący w takim środowisku starają się…
przetrwać. Ponieważ nie znają moczar, boją się w nie wchodzić. Jednak
ich zadaniem jest opieka nad cennymi roślinami-funkcjonalnościami
– za to są przecież wynagradzani. Aby wybrnąć z sytuacji większość
z nich decyduje się na najbezpieczniejszą z pozoru strategię – minimalne
ingerencje. Jednak takie podejście powoduje dalszą degenerację środowiska ich pracy – bagno zarasta coraz bardziej.
czesnym zachowaniu dostępności. W odpowiedzi na to zapotrzebowanie departamenty IT wdrażają technologię wirtualizacji, środowiska cloud computingu i ujednoliconego przetwarzania dla systemów logicznych. Takie działania są efektywne dla IT, ale jednocześnie tworzą nowe
zależności w systemach fizycznych zarządzanych przez departamenty
obiektów i skutkują zmianami w zarządzaniu zasilaniem, chłodzeniem
i przestrzenią fizyczną. Czynniki te w połączeniu z rosnącymi kosztami energii elektrycznej, wymaganiami dotyczącymi zgodności z przepisami i umowami SLA powodują, że menedżerowie centrum danych
są zmuszeni zajmować się nie tylko działaniem sprzętu IT, ale także kompleksową obsługą całości infrastruktury centrum danych jako elementów ekosystemu.
Grywalizacja życie to nie bajka ................................................................ 16
Adrian „Adio” Zając
Rozwój technologii to wyzwanie dla programistów ................................ 10
Dariusz Dudek
Producenci sprzętu komputerowego prześcigają się w tworzeniu
urządzeń o coraz lepszych parametrach – mniejszych, lżejszych,
z coraz większą mocą obliczeniową. Podobnie dzieje się w obszarze
technologii IT. Z jednej strony oznacza to zwiększenie możliwości
twórców oprogramowania, jednak z drugiej, stawia przed informatykami sporo wyzwań.
Obecnie głównym wyzwaniem dla programistów jest bycie na bieżąco
ze zmianami na rynku technologii, który jest bardzo dynamiczny. Nowości, które początkowo wydają się jedynie ciekawostkami, często stają
się poważnymi konkurentami wobec sprawdzonych i znanych produktów. Okazuje się, że nowe rozwiązanie mogą być lepsze i znacznie tańsze.
Dzięki dobrej znajomości rynku zespoły projektowe wraz z programistami mogą zaprojektować i stworzyć systemy najlepiej dopasowane do potrzeb biznesu, ale też najbardziej korzystne finansowo.
Centrum danych - budowa czy kolokacja? .............................................. 11
Edyta Marchaluk
Rosnące potrzeby IT, digitalizacja kolejnych dziedzin życia, wymagające sprzętowo aplikacje, czy wreszcie ekspansja i nowe obszary działalności firm, stawiają managerom IT wyzwanie zapewnienia przestrzeni dla rozrastających się środowisk IT. Decyzje w tym obszarze poparte są najczęściej szeregiem analiz biznesowych, ale mogą mieć także podłoże w przyzwyczajeniach. Jedno z nich podpowiada nam, że wykonanie czegoś samodzielnie będzie tańsze. Drugie,
że jeśli coś jest naszą własnością, to mamy nad tym większą kontrolę,
a więc mamy większe poczucie bezpieczeństwa. Czy rzeczywiście tak
jest? Co powinniśmy rozważyć podejmując decyzję dotyczącą budowy
własnego centrum danych?
Zarządzanie infrastrukturą centrum danych
wypełnia lukę pomiędzy IT a obiektami . ................................................ 13
Piotr Kowalski
W dobie oszczędności i kryzysu gospodarczego menedżerowie centrów danych znajdują się pod ogromną presją podnoszenia efektywności działalności i zwiększenia wykorzystania dostępnych zasobów. Są
zmuszeni do podwyższania wydajności i redukcji kosztów przy jednoMiesięcznik Software Developer’s Journal
(13 numerów w roku) jest wydawany
przez SoftPress Sp. z o.o.
2
Prezes: Natalia Sieniutowicz
Redaktor Naczelny: Natalia Sieniutowicz
Redaktor Prowadzący: Patrycja Popławska
Skład i łamanie: Marcin Ziółkowski,
Graphics & Design Studio, www.gdstudio.pl
Kierownik Produkcji: Andrzej Kuca
[email protected]
Wirtualna zabawa w farmera stała się ogólnoświatowym fenomenem,
bijąc rekordy popularności. Zasiadając przed swoją ukochaną konsolą po ciężkim i wyczerpującym dniu nauki, czy pracy liczymy na chwilę relaksu po trudach dnia codziennego. Efekt takiego „odstresowywania się” jest o tyle lepszy, o ile dany tytuł spełnia swój główny cel,
którym jest dostarczenie szeroko pojętej rozrywki, czy to za sprawą hipnotyzującej zmysły grafiki, urzekającej ścieżki dźwiękowej, zapierającej
dech w piersiach fabuły, czy pompującej do krwi adrenalinę akcji.
Metodyka Agile i projekty SharePoint
– mezalians, ślub czy pogrzeb? ................................................................ 21
Janusz Falkiewicz – Analityk i Konsultant Biznesowy, JADE.
Metodyk zwinnych jako takich sądzę, iż nie ma potrzeby przedstawiać
- oficjalnie zostały ogłoszone jako manifest już w 2001 roku. Po szczegóły, bądź dla odświeżenia pamięci, polecam sięgnąć do tego źródła:
www.agilemanifesto.org/iso/pl/.
Idea jest prosta i chwytliwa: w realizacji wdrożeń informatycznych ważni są ludzie, współpraca z Klientem, interakcja wewnętrzna, reagowanie
na zmiany, cykliczne iteracje (trwają od 2 do 4 tygodni, są to tzw. sprinty) no i oczywiście działające oprogramowanie. A działające oznacza
wspomagające pracę i realizację celów biznesowych Klienta, takie, które on
„wykorzystuje”, a nie „obsługuje”. No software – just tools.
Programowanie w świecie nowych technologii ...................................... 24
Bogdan Bereza
Trzy podstawowe pytania
• Programiści – czy tworzą działające, zgodne z potrzebami klienta
aplikacje, czy tylko produkują i kompilują kod źródłowy?
• Rozwój technologii – czy to tylko bardziej wypasiona elektronika
oraz systemy operacyjne i języki programowania o coraz dziwaczniejszych
nazwach, czy również zmiany metod, procesów, organizacji?
• Nowość – dla jednej osoby, dla danej firmy, czy autentyczna nowość?
Co to właściwie jest „programowanie”?
Czy oznacza to tworzenie oprogramowania, a więc złożony proces,
obejmujący całą drogę od analizy wymagań, poprzez projektowanie, pisanie kodu, integrację, testowanie, wdrożenie i utrzymanie?
Czy też programowanie, to samo kodowanie: pisanie kodu źródłowego,
kompilowanie, ewentualnie anali za statyczna i testy jednostkowe
Adres korespondencyjny:
SoftPress Sp. z o.o.
ul. Bokserska 1, 02-682 Warszawa,
Polska
tel. +48 22 427 36 91,
fax +48 22 224 24 59
www.sdjournal.org
[email protected]
Dział reklamy:
[email protected]
Redakcja dokłada wszelkich starań, by publikowane w piśmie i na towarzyszących mu nośnikach
informacje i programy były poprawne, jednakże nie bierze odpowiedzialności za efekty wykorzystania ich; nie gwarantuje także poprawnego
działania programów shareware, freeware i public domain. Wszystkie znaki firmowe zawarte
w piśmie są własności odpowiednich firm. Zostały
użyte wyłącznie w celach informacyjnych. Osoby
zainteresowane wspópracą prosimy o kontakt:
[email protected]
Praca
z „Legacy Code” część 2
Przekleństwo czy intelektualne wyzwanie?
Wielu programistów nie chce pracować w projektach, w których
głównym zajęciem jest utrzymanie produktu a nie jego rozwój.
W przypadku takich projektów metafora produkcji oprogramowania
wymyślona przez Alistaira Cockburna – gra bagienna – ma
zdwojoną siłę przekazu. Programiści pracujący w takim środowisku
starają się… przetrwać. Ponieważ nie znają moczar, boją się w nie
wchodzić. Jednak ich zadaniem jest opieka nad cennymi roślinamifunkcjonalnościami – za to są przecież wynagradzani. Aby wybrnąć
z sytuacji większość z nich decyduje się na najbezpieczniejszą
z pozoru strategię – minimalne ingerencje. Jednak takie podejście
powoduje dalszą degenerację środowiska ich pracy – bagno zarasta
coraz bardziej. Widząc pogarszającą się powoli, lecz niezmiennie
sytuację stają się coraz bardziej sfrustrowani i zniechęceni. Niniejszy
artykuł ma za zadanie przedstawić strategię osuszania mokradeł
wraz z kilkoma użytecznymi technikami.
Dowiesz się:
Powinieneś znać:
• w jaki sposób radzić sobie z niepożądanymi
zależnościami w kodzie.
• podstawy języka C++
• podstawy Test Driven Development
• podstawowe pojęcia programowania obiektowego
D
osłowne znaczenie terminu kod spadkowy, to „kod, który otrzymaliśmy od
innej osoby”. Jednak w środowisku
zwinnych metodyk wytwarzania oprogramowania powszechnie przyjęła się definicja „kod
bez lub z małą ilością testów automatycznych”. Bez względu na definicję kod spadkowy
(czy też odziedziczony) wzbudza w programistach niemiłe skojarzenia. Wśród najczęściej
wymienianych są trudność ze zrozumieniem
kodu, oraz związany z nim strach przed wprowadzeniem niepożądanych efektów podczas
4
pielęgnacji. Z takim problemem mierzy sie codziennie wielu programistów.
Aby móc skutecznie radzić sobie innym
z takimi zadaniami M. Featchers zaproponował heurystykę wprowadzania zmian w
kodzie spadkowym. Algorytm ten składa się
z pięciu etapów:
• Znalezienie punktów, w których dokonywać będziemy zmiany,
• Znalezienie miejsc, w których będziemy
testować,
• Usunięcie niepożądanych zależności pomiędzy elementami, które będziemy testować a ich otoczeniem,
• Napisanie testów,
• Wprowadzenie pożądanych zmian.
W poprzednim artykule zajmowaliśmy się
dwoma pierwszymi krokami powyższej heurystyki i w związku z tym, możemy założyć,
że mamy już wiedzę na temat tego:
• gdzie i w jaki sposób będziemy dokonywać zmiany, oraz
Praca z „Legacy Code” część 2
• w jaki sposób i w jakich miejscach najwygodniej będzie nam testować.
Aby tego dokonać posługiwaliśmy się dwoma
pomocnymi na tych etapach technikami. Były to tak zwanym scratch-refaktoring i szkice
efektów. W niniejszym artykule zajmiemy się
krokiem 3 – usuwaniem niepożądanych zależności.
Co sprawia, że zmiana
kodu odziedziczonego
jest taka trudna?
Oczywiście zmiana, jako taka jakiegokolwiek
kodu nie jest trudna. Trudność polega na tym,
że jako profesjonaliści chcemy naszą zmianę
zweryfikować za pomocą testów automatycznych. W przypadku pisania nowego kodu
z zastosowaniem TDD podjęcie decyzji jak
testować jest wystarczającym warunkiem do
tego, aby zacząć pisać test. Niestety, mając do
czynienia z kodem spadkowym programiści
często wpadają w błędne koło problemu „jajka
i kury”. Z definicji kod taki nie ma testów,
lub ma ich mało. To powoduje, że trudno poprawić jego strukturę (refaktoryzować) bez obawy o skutki takich zmian. Taka obawa często prowadzi do wybierania
takich rozwiązań, które wprowadzą minimum zmiany w kodzie. Takie dodawanie
kolejnego przysłowiowego „jednego if-a”
skutkuje nieuchronnie wzrostem skomplikowania kodu. Natomiast skomplikowana
struktura wewnętrzna utrudnia lub nawet
uniemożliwia napisanie testów. Sposobów,
w jaki obniżamy testowalność aplikacji jest
wiele. Jednym z najczęstszych problemów
przy próbie pisanie testów jednostkowych
w kodzie spadkowym są skomplikowane zależności. Zależności mogą uniemożliwić nam
stworzenie w środowisku testowym obiektu
klasy, w której wprowadzamy zmiany. Przykładem może tu być parametr konstruktora,
którego do poprawnej inicjalizacji wymaga
podania wielu kolejnych równie skomplikowanych obiektów. Te z kolei wymagają kolejnych itd. Wywołana w ten sposób lawina
może oznaczać skompilowanie i ręczne skonstruowanie znacznej części systemu. Tak
skonstruowany test będzie zazwyczaj nadmiarowy, bardzo pracochłonny, podatny na
błędy i trudny w pielęgnacji. Inną kłodą rzucaną przez zależności pod nasze nogi może
być fakt, że czasem nie będziemy chcieli w teście współpracować z obiektami oryginalnych
(produkcyjnych) klas. Najczęstszym przypadkiem są tutaj obiekty współpracujące z bazami danych. Współpraca naszego testowego
obiektu z obiektem wykonującym połączenie do bazy danych lub komunikującym sie
poprzez sieć na pewno wielokrotnie spowolni
wykonanie przypadku testowego ,a dodatkowo może wprowadzić utrudniającą testowanie losowość zachowania. Dla uproszczenia
rozważań przyjąć możemy, że miejsce zmiany
i miejsce testowania są takie same, (choć nie
zawsze jest to prawdą – patrz pierwsza część
artykułu – szkice efektów) oraz że będę tych
pojęć używał zamiennie.
Zależności publiczne i prywatne
Wszystkie wymienione zależności pomiędzy
elementami (klasami, modułami itd.) można
podzielić na dwie kategorie: publiczne i prywatne. Pierwszą z nich są powiązania wynikające z interfejsu klasy lub modułu, drugą stanowią powiązania zdefiniowane w funkcjach
i metodach. Ta pierwsza grupa - jawne powiązania jest z punktu widzenia testowalności
przypadkiem łatwiejszym. Większość publicznych powiązań obiektu, który zamierzamy
testować z obiektami klas, które są „trudne”
w tworzeniu lub współpracy można, po niewielkich zmianach zastąpić zależnościami do
interfejsów lub klas abstrakcyjnych. Po takiej
zmianie umożliwiamy sobie oddzielenie testowalnego obiektu od reszty środowiska przez
zastosowanie dublerów testowych. Wystąpienie kłopotliwych zależności prywatnych jest
większym wyzwaniem: wymaga dodatkowych
kroków umożliwiających ich wyeliminowanie.
Powyższe uwagi w przypadku programowania
zorientowanego obiektowo oznaczają powiązania pomiędzy obiektami.
Zależności od wartości losowych
return 0;
Występowanie w kodzie losowych lub związanych z czasem wartości także może poważnie utrudniać testowanie. Do tych pierwszych
należą wszelkie wywołania generatorów liczb
pseudolosowych, do drugich wszystkie odmiany znaczników czasowych (ang. time-stamp)
i dat. Problem najłatwiej zobrazować wyobrażając sobie przykładową komputerową wersję
dowolnej gry planszowej z kostkami do gry.
W grach tego typu ruch gracza uzależniony
jest od ilości wyrzuconych oczek na kostce do
gry. W wersji komputerowej rzut kostką symulowany jest poprzez wywołanie jakiejś odmiany funkcji „random”. Gdy przystępujemy do
testowania elementów związanych z ruchem
graczy po planszy, bez odseparowania zależności od generatora - za każdym razem algorytm
przesuwający pionek będzie przesuwał go
w inne miejsce.
private:
Krok 3 – Usuwanie
niepożądanych zależności
Listing 1. Klasa z metodą odwołującą się do czasu (przed zmianami)
class ClassUnderTest {
public:
// metoda wywołująca funkcję systemową
int functionUnderTest() {
std::time_t t = std::time(NULL);
std::tm tm = std::localtime(&t);
if (tm.tm_wday == 0 /*Sunday*/
|| tm.tm_wday == 6 /* Saturday*/) {
performFullProcedure();
performSimplifiedProcedure();
} else {
}
}
int performSimplifiedProcedure() {
// some complicated code here
return 0;
}
int performFullProcedure() {
// some even more complicated stuff ...
return 0;
}
};
Na szczęście istnieją skuteczne sposoby pozbywania się niepożądanych zależności. Techniki
refaktoryzacji, o których mowa są wystarczająco bezpieczne, aby stosować je również do
kodu bez testów.
Przypadek 1: Testowana funkcja zależna jest
od funkcji systemowej (daty systemowej, czasu systemowego, generatora liczb pseudolosowych itd.).
5
Listing 2. Klasa po zmianach
class ClassUnderTest {
public:
// metoda wywołująca funkcję systemową
// po wydzieleniu fragmentu do osobnej metody
int functionUnderTest() {
std::tm tm = getLocalTime();
if (tm.tm_wday == 0 || tm.tm_wday == 6) {
performFullProcedure();
} else {
performSimplifiedProcedure();
}
return 0;
}
private:
// wydzielona część odwołująca się do systemu
virtual std::tm getLocalTime() {
std::time_t t = std::time(NULL);
std::tm tm = std::localtime(&t);
return tm;
}
int performSimplifiedProcedure() { return 0; }
int performFullProcedure() { return 0; }
};
Listing 3. Podklasa testowa
class TestingVersionUnderTest: ClassUnderTest {
private:
// wersja testowa metody – zwraca dogodny dla testu wynik
virtual std::tm getLocalTime() {
std::tm tm;
tm.tm_wday = 0;
return tm;
}
};
Listing 4.
class ClassWithLongMathods {
public:
int someLongMathod(int id, std::string name, Person &dsc);
// metoda wywołująca metodę „someLongMathod”
void clientMathod();
// metoda wywoływana przez „someLongMathod”
void anotherMethod();
private:
// pole do którego odwołuje się „someLongMathod”
std::string someData;
};
void ClassWithLongMathods::clientMathod() {
. . . . . . .
int ret = someLongMathod( id, “na”, person );
. . . . . . .
}
int ClassWithLongMathods::someLongMathod(int id,
std::string name, Person &dsc){
. . . . . . .
if( someData == name ){
anotherMethod();
}
. . . . . . .
}
6
Wyobraźmy sobie metodę, która inaczej zachowuje się w dni robocze, inaczej w dni wolne
(listing 1). W dni robocze uruchamiany jest
szybki, ale mało dokładny algorytm obliczania pewnej wartości. W dni wolne natomiast
wykonywana jest pełna wersja. Rozwiązaniem
jest refaktoryzacja „nadpisanie metod(y)
w podklasie”
Algorytm zmiany:
• Zidentyfikuj elementy, które stanowią
problem
• Jeśli elementem tym jest bezpośrednie
wywołanie funkcji systemowej – użyj refaktoryzacji „Wyodrębnienie metody”, (jeśli używasz języka Java i środowiska Eclipse możesz zaznaczyć to wywołanie
i użyć skrótu alt+shif+m). Jeśli kłopotliwe
zachowania stanowią metodę – upewnij
się, że można tę metodę nadpisać. Przykładowo w języku Java może to między
innymi oznaczać zmianę zakresu metody
jeśli dotychczas była prywatna (listing 2).
• Stwórz w testach podklasę i nadpisz kłopotliwe metody w taki sposób, aby zachowywały się w pożądany sposób (listing 3).
Powyższą technikę stosować można także
w wielu innych wypadkach. Wśród innych częstych przykładów można wymienić:
• tworzenie obiektu dowolnej klasy. Wydzieleniu metody dla instrukcji tworzącej
obiekt jest de-facto zastosowaniem wzorca „metoda tworząca”.
• Unieważnienie dowolnego niepożądanego zachowania. Jeśli mamy dowolny fragment kodu, o którym wiemy, że nie wpływa na modyfikowaną funkcjonalność, ale
spowalnia testy (przykład: weryfikacja
uprawnień użytkownika)
Przypadek 2: Testowanie zmiany w długiej
metodzie.
Jednymi z najczęściej występujących problemów w kodzie są zapachy „długa metoda”
i „wielka klasa”. Problematyczne w nich jest
między innymi to, że długa metoda z definicji
robi wiele różnych rzeczy i czasem weryfikacja zmian poza tą metodą jest niemożliwa.
W takich sytuacjach warto rozważyć przeniesienie metody do nowej klasy. Przykładowy
pseudo-kod z oczywistych względów zawiera
długą metodę tylko z nazwy (listing 4), lecz
powinno to wystarczyć do zobrazowania problemu i jego rozwiązania.
Poniższy algorytm zaczerpnięty został
z książki „Working Effectively with Legacy
Code”. Podobny algorytm zaproponowany
został przez M. Fowlera w książce „Refactoring: Improving the Design of Existing Code”.
Listing 5. Po krokach 1-4
class SomeLongMathod {
int _id;
std::string _name;
Person &_dsc;
public:
SomeLongMathod(int newId, std::string newName,
Person &newDsc)
: dsc(newDsc) {
Id = newId;
name = newName;
}
int run();
};
Listing 6. Po kroku 5
int SomeLongMathod::run() {
. . . . . . .
if( someData == name ){
foo3();
anotherMethod();
}
. . . . . . .
}
Listing 7. Po kroku 6 i 7 z dodaną referencją do klasy
macierzystej
class SomeLongMathod {
private:
int id;
std::string name;
Person dsc;
ClassWithLongMathods source;
public:
SomeLongMathod(ClassWithLongMathods &newSource,
int newId, std::string newName, Person &newDsc)
: source(newSource), dsc(newDsc) {
Id = newId;
name = newName;
};
int run();
};
// przeniesiona metoda z referencją do obiektu klasy
macierzystej
int SomeLongMathod::run() {
foo1();
if( source.someData == name ){
foo3();
source.anotherMethod();
}
foo4();
return id + 100;
}
void ClassWithLongMathods::clientMathod() {
. . . . . . .
SomeLongMathod methodObject(id, “na”, person );
methodObject.run();
. . . . . . .
}
• Stwórz klasę, która zostanie gospodarzem dla przenoszonego kodu (proponuję nadać jej nazwę nawiązującą do nazwy
metody, którą przenosimy)
• Stwórz konstruktor, skopiuj do niego sygnaturę przenoszonej metody
• W nowej klasie dodaj pola, które przechowają wartości przekazane przez parametry wywołania konstruktora.
• Stwórz w nowej klasie bezparametrową
metodę, która będzie wykonywała przenoszony kod (proponuję nazwy „run”
lub „execute”), Jeśli oryginalna metoda
zwraca wartość – nowa metoda powinna
zwracać taki sam typ. Dodatkowo, w niektórych językach np. w języku Java - jeśli
metoda wyrzuca wyjątek – nowa metoda
powinna zadeklarować taki sam typ wyjątku (listing 5).
• Przenieś ciało metody do stworzonej metody wykonawczej (listing 6). Skompiluj.
• Jeśli nowa metoda używa metod lub pól
ze starej klasy – podaj, jako pierwszy parametr do konstruktora referencję do
obiektu klasy macierzystej. Odwołania do
pól i metod starej zastąp wywołaniami do
pól i metod dodanej referencji. Czasem
wymagać to będzie zmiany poziomu dostępu.
• Jeśli nowa klasa kompiluje się wróć do
oryginalnej klasy i usuń metodę. Wywołanie metody zastąp stworzeniem egzemplarza nowej klasy i wywołaniem na nim
metody uruchamiającej przeniesiony kod
(listing 7).
• Jeśli trzeba, zastąp wywołania metod ze
starej klasy, odwołaniami do interfejsu
(zobacz refaktoryzację „wyodrębnienie
interfejsu”)
Wielką zaletą opisanego powyżej algorytmu
jest jego skuteczność. Można go zastosować
dosłownie do każdej długiej metody. Bezpośrednią potencjalną wadą użycia jest obniżenie hermetyzacji klasy. Oczywiście dzięki
temu podnosimy (czy raczej tworzymy) testowalność. Obie te cechy – testowalność i hermetyzacja są narzędziami służącymi temu samemu celowi: podniesieniu niezawodności kodu.
Dlatego mając do wyboru rezygnację z jednej
na korzyść drugiej zawsze wybiorę wyższą testowalność.
W tym miejscu warto przypomnieć, że
sprzymierzeńcem w pracy z kodem jest
dobra znajomość języka programowania.
Kilka lat temu, gdy pracowałem w projekcie, w którym używany był język Delphi odkryłem w aplikacji wycieki pamięci.
Problem związany był z tym, że:
• w kodzie wywoływanym przez wydzialaną metodę następowała leniwa
7
inicjalizacja jednego z parametrów
przekazanych, oraz dodatkowo, że
• zainicjalizowany obiekt zwracany był
poprzez parametr wywołania.
Po zastosowaniu tego algorytmu leniwa inicjalizacja zachodziła oczywiście dalej, ale aktualizowana była jedynie składowa nowo powstałego obiektu. Parametr przekazywany do nowopowstałego
obiektu pozostawał niezainicjowany poza wywoływaną funkcją, co z kolei skutkowało ponowną próbą stworzenia obiektu
w innym fragmencie kodu. Ponieważ, dodatkowo, wszystko to działo się w języku
programowania, który wymagał jawnego zwalniania pamięci (Delphi) to oprócz
utraty danych wprowadzonych do kłopotliwego obiektu następował wyciek pamięci. Był to jedyny problem spowodowany zastosowaniem powyższego algorytmu, jaki kiedykolwiek odkryłem.
Listing 8.
class Person {
string _firstName, _familyName;
PersonDAO *_personDao;
public:
• Skopiuj konstruktor, który sprawia kłopoty
• Określ, które obiekty tworzone w konstruktorze stanowią problem
• Po kolei usuwaj te parametry przenosząc
je do listy parametrów konstruktora (listing 9)
• Ze starego konstruktora usuń cały kod
(poza inicjacją kłopotliwych zmiennych)
i zastąp go wywołaniem nowego konstruktora (listing 10)
Po takiej refaktoryzacji mamy do dyspozycji
dwa konstruktory. Pierwszy – z mniejszą ilościa parametrów nadal tworzy potrzebne sobie
8
Person(string firstName, string familyName, time_t
birthDate);
};
Person::Person(string firstName, string familyName,
time_t birthDate) {
_personDao = new PersonDAO(); // problematyczny
_familyName = firstName;
_birthDate = birthDate;
Przypadek 3: Testowanie zmiany w obiekcie
z kłopotliwymi powiązaniami z innymi obiektami.
Inna często występującą sytuacją są zależności
do obiektów-składowych tworzonych w konstruktorze. Niejednokroć zdarza się, że klasa
mając jedynie bezparametrowy konstruktor
w swoim ciele powołuje do życia kilkanaście
innych obiektów. Często jeden lub wiele z nich
wpływa na zachowanie obiektu w sposób uniemożliwiający skuteczne napisanie testów.
Przykładem może być sytuacja, w której
klasa reprezentująca osobę powołuje w konstruktorze obiekt służący zapisywaniu/odczytywaniu obiektów z bazy danych – DAO
(wzorzec Obiektu Dostępu do Danych – ang.
Data Access Object - listing 8). Testując taki
obiekt interesować nas będzie czy spełnia
swoje zadania w systemie (np. czy zwraca metoda „string getFullAddress()” zwróci poprawnie sformatowany adres wraz z imieniem
i nazwiskiem) i czy ewentualnie podejmie
próbę zapisania się w bazie danych a nie to
czy rekord w bazie danych powstanie – to jest
już rola wspomnianego wcześniej obiektu
DAO.
Algorytm: Parametryzacja Konstruktora
time_t _birthDate;
}
obiekt
_familyName = familyName;
_personDao->save( *this );
Listing 9. Po kroku 3
// oryginalny
konstruktor
Person::Person(string firstName, string familyName, time_t birthDate) {
_personDao = new PersonDAO(); // problematyczny obiekt
}
// dodany, testowy konstruktor
Person::Person(string firstName, string familyName, time_t birthDate, PersonDAO *personDao) {
_personDao = personDao;
}
personDao->save( *this );
Listing 10. Wersja finalna
// oryginalny
konstruktor po usunięcu duplikacji
}
this(familyName, familyName, birthDate, new PersonDAO());
Person::Person(string firstName, string familyName,
time_t birthDate, PersonDAO *personDao) {
_personDao = personDao;
}
Listing 11. Klasy reprezentujące osobę oraz singleton
umożliwiający jej zapis do bazy danych (wersja wyjściowa)
// klasa – singleton, który sprawia kłopoty
class PersonDAO {
private:
PersonDAO( string url, string usr, string pass);
string connectingStr, usr, pass;
static PersonDAO* PersonDAO::instance(){
static PersonDAO *_instance;
public:
if( _instance == NULL ) {
}
}
string url = getUrl();
_instance = new PersonDAO(url, “admin”, “*”);
return _instance;
void save(Person &person) const;
void update(Person &person) const;
};
void remove(Person &person) const;
Person* find(int Id);
// klasa, którą chcemy testować
obiekty samodzielnie i używany jest w kodzie
produkcyjnym. Drugi konstruktor, do którego poza oryginalnymi parametrami dodaliśmy
nowe służyć nam będzie do dostarczenia w kodzie testowym dublerów testowych zamiast
egzemplarzy, które sprawiały nam problem.
Przypadek 4: Zależność od Singletonu
Występowanie w kodzie wzorca singleton
jest szczególnym przypadkiem zależności od
elementów statycznych. W większości popularnych implementacji wzorca klasa singletonu jest odpowiedzialna za stworzenie
egzemplarza. Klasa tworzonego obiektu jest
podana wprost. To powoduje, że w takich implementacjach nie ma możliwości zwrócenia
obiektu klasy pochodnej bez istotnych zmian
w implementacji wzorca. Jedną z możliwości
jest zmiany jest użycie rejestrów singletonów,
kolejną stworzenie osobnych konfiguracji dla
kodu produkcyjnego i testowego oraz korzystających z nich fabryk abstrakcyjnych.
Jeśli taka zmiana jest niemożliwa lub nieopłacalna można posłużyć się innymi, mniej
pracochłonnymi sposobami.
class Person {
Sposób 1 - Wprowadzenie wzorca Monostate.
• Zmień wszystkie pola klasy singletona na
statyczne
• Zmień zakres metody zwracającej egzemplarz na prywatny
• Sprawdź kod inicjalizujący egzemplarz
obiektu singletonu (zazwyczaj w metodzie instance) Jeśli stworzenie polega jedynie na wywołaniu prywatnego konstruktora: zmień jego zakres konstruktora na
publiczny
• Jeśli nie ma bezparametrowego konstruktora, stwórz go i przenieś kod inicjalizujący (listing 12).
• Skompiluj; Wszędzie tam gdzie kompilator zgłosi błędy związane z niedostępnością metody zwracającej egzemplarz (instancje()): zmień wywołanie na stworzenie egzemplarza.
• Usuń metodę zapewniającą dostęp do egzemplarza (instancje()) i zmienną przechowującą egzemplarz (listing 13).
• Jeśli w kodzie testowym trzeba będzie
nadpisać którąkolwiek upewnij się czy
to będzie możliwe (np. przez uczynienie
metody wirtualną w C++, czy też usunięcie modyfikatora final w Java)
string _firstName, _familyName;
PersonDAO *_personDao;
Person(string firstName, string familyName, time_t birthDate);
time_t _birthDate;
public:
};
}
_personDao = PersonDAO::instance();
Listing 12. Zmiana po stronie singletonu (kroki 1-3)
class PersonDAO {
private:
static string _connectingStr, _usr, _pass;
static PersonDAO* instance();
public:
PersonDAO();
};
Teraz możemy zastosować „wydzielenie metody” i „nadpisanie metod w podklasie”. Po
tych krokach w miejscu gdzie używaliśmy
single tonu mamy metodę kreującą egzemplarz pochodny od mona state, w którym to
przedefiniowaliśmy kłopotliwe dla nas zachowania.
9
Listing 13. Ostateczny wygląd kodu
// klasa – która sprawiałą kłopoty – obecnie monostate
class PersonDAO {
private:
};
// zmiana w kodzie klienta
Person::Person(string firstName, string familyName, time_t
birthDate) {
public:
this (getUrl(), „admin”, „****”);
PersonDAO() { // przeniesiony kod inicjalizujący
}
}
_personDao = new PersonDAO();
Listing 14. Po dodaniu metody umożliwiającej ustawienie innego egzemplarza.
class PersonDAO {
private:
_instance = newInstance;
static PersonDAO* instance();
public:
// dodana metoda umożliwiająca ustawienie
void setInstance(PersonDAO *newInstance){
// zwracanego egzemplarza
Sposób 2 – Dodanie statycznego settera.
Metoda ta polega na dodaniu do singletonu
metody pozwalającej ustawić zwracaną instancję – w ten sposób możemy wpływać na to co
zostanie zwrócone przez metodę instancje (Listing 14). Oczywiście ma to (poza zmniejszeniem hermetyzacji) wadę: trzeba pamiętać,
aby po teście przywrócić oryginalną instancję.
Usunięcie zależności nie jest oczywiście
celem samym w sobie. Uniemożliwia nam jedynie napisanie testów, które upewnią nas w
przekonaniu, że modyfikując kod wprowadziliśmy tylko takie efekty, o których myśleliśmy i że
żadna z pozostałych funkcjonalności systemu
nie została zepsuta. Mając to za sobą będziemy
mogli przystąpić do napisania testów i wprowadzenia nowych funkcjonalności lub zmodyfikowania (poprawienia) starych. To jednak będzie
tematem ostatniej, trzeciej odsłony tematu.
Refaktoryzacja
Seria małych przekształceń kodu nie
zmieniających jego funkcjonalności mających na celu poprawę STRUKTURY kodu.
10
};
};
Kod Spadkowy (ang. Legacy Code)
1. Kod napisany przez kogoś innego.
2. Kod z małą ilością lub pozbawiony zupełnie testów automatycznych..
W Sieci
Wzorzec Monostate
Wzorzec zapewniający, że wszystkie dane przechowywane przez egzemplarz są
współdzielone przez wszystkie egzemplarze danej klasy.
•
Wzorzec Singleton
Wzorzec zapewniający, że istnieje tylko jeden egzemplarz obiektu oraz dostarczający globalny punkt dostępu do tego egzemplarza.
Zapachy Kodu (ang. Code Smells)
Ogólne pojęcie zaproponowane przez
Kenta Becka wyjaśniające kiedy kod powinien zostać poddany refaktoryzacji.
Dublerzy Testowi (ang. Test Doubles)
Zaproponowana przez Gerard Meszaros
ogólna nazwa na wszystkie obiekty, na
które podmieniamy oryginały w celu ułatwienia testowania
•
•
•
•
http://www.objectmentor.com/resources/
articles/WorkingEffectivelyWithLegacy
Code.pdf
http://my.safaribooksonline.com/
book/software-engineering-anddevelopment/0131177052
http://my.safaribooksonline.com/book/
software-engineering-and-development/
refactoring/0201485672
http://twogrumpycoders.wordpress.com/
http://astyle.sourceforge.net/
Grzegorz Gubiński
Trener Agile z Nokia Siemens Networks, z pond
trzynastoletnim doświadczeniem w programowaniu w takich językach jak C++, Java, Pascal/Delphi czy też Flex. Obecnie zajmuje się między innymi wdrażaniem metodyki Scrum oraz praktyk inżynierskich programowania ekstremalnego.
Rozwój technologii to wyzwanie dla programistów
Rozwój technologii
to wyzwanie dla programistów
Producenci sprzętu komputerowego prześcigają się w tworzeniu
urządzeń o coraz lepszych parametrach – mniejszych, lżejszych, z coraz
większą mocą obliczeniową. Podobnie dzieje się w obszarze technologii
IT. Z jednej strony oznacza to zwiększenie możliwości twórców oprogramowania, jednak z drugiej, stawia przed informatykami sporo wyzwań.
O
becnie głównym wyzwaniem dla programistów jest bycie na bieżąco ze zmianami na rynku technologii, który jest
bardzo dynamiczny. Nowości, które początkowo
wydają się jedynie ciekawostkami, często stają się
poważnymi konkurentami wobec sprawdzonych i
znanych produktów. Okazuje się, że nowe rozwiązanie mogą być lepsze i znacznie tańsze. Dzięki
dobrej znajomości rynku zespoły projektowe wraz
z programistami mogą zaprojektować i stworzyć systemy najlepiej dopasowane do potrzeb biznesu, ale
też najbardziej korzystne finansowo.
Nowinki technologiczne wiążą się z koniecznością stałego dokształcania i podnoszenia kwalifikacji, zdobywania nowych umiejętności i certyfikatów.
Praca programisty wymaga znajomości gotowych
produktów, takich jak serwery baz danych, serwery
aplikacyjne, portale, silniki procesów, system obiegu
dokumentów. W tym obszarze programiści certyfikują się w zakresie produktów oferowanych przez
największych na świecie dostawców technologii
(np. Microsoft, Oracle, IBM czy JBoss).
Rozwój technologiczny bezpośrednio dotyczy
takich czynników jak bezpieczeństwo informacji,
ergonomia systemów czy ich skalowalność. W tym
kontekście każda implementacja nowych rozwiązań zwiększa ryzyko wystąpienia problemów. Stąd
wiele firm i dostawców decyduje się na technologie,
które gwarantują jak największe bezpieczeństwo
danych. Nie zmienia to jednak faktu, że dostawca powinien pomóc dokonać wyboru prezentując
także korzyści w obszarach ergonomii, wydajności
i skalowalności przy użyciu najnowszych rozwiązań.
Klienci chcą mieć pewność, że otrzymają od
dostawcy stabilne rozwiązanie, stworzone w technologii, która nie zostanie wycofana czy wyparta
z rynku w ciągu najbliższych kilku lat. W wielu
przypadkach w ten aspekt bezpieczeństwa wpisuje się możliwość rozwoju systemu, dostępność
nowych wersji, otwartość czy łatwość dokonania
migracji. Jeżeli programiści nie są na bieżąco z najnowszymi technologiami, to po pierwsze ich klienci
będą potencjalnie tracić korzyści wynikającej
z wdrażania tańszych i lepszych rozwiązań, po dru-
gie zaś, w dłuższej perspektywie dla programistów
może to oznaczać utratę klientów i zleceń.
Języki programowania
Jednym z zagadnień, które muszą śledzić programiści, są języki programowania. Języki podstawowe
wykorzystywane w tworzeniu rozwiązań stale się
rozwijają. Opanowanie ich wszystkich jest praktycznie niemożliwe, dlatego programiści specjalizują się
w jednym bądź kilku językach. Stąd w przypadku
tworzenia produktu lepiej bazować na jednym języku.
Dla klientów ważne są możliwości, jakie dają nowe technologie. Z punktu widzenia zespołu projektowego przed przystąpieniem do pracy najważniejszy będzie wybór odpowiedniej technologii. Twórcy
rozwiązania muszą mieć stuprocentową pewność,
że wybrany język, technologia czy platforma pozwolą stworzyć i wdrożyć wymagane przez klienta funkcjonalności. Jednocześnie wybór ten należy
wpisać w trendy rozwoju rynku i branży, w jakiej
działa klient. W praktyce producenci wykorzystują
nowe – i tym samym nie dość dobrze sprawdzone
– języki i platformy tylko w prototypach i małych
rozwiązaniach.
Zmiany technologiczne
Dla programistów bardzo istotne są zmiany związane z wzorcami architektonicznymi i projektowymi,
co może rzucać nowe światło na sposoby tworzenia
oprogramowania. Tego rodzaju zmiany pozwalają
lub wręcz zmuszają do przemodelowania myślenia
o tym, w jaki sposób można spełnić oczekiwania
klienta. Do takich zmian technologicznych należały m.in. MOM (Message-oriented middleware),
SOA (Service-oriented architecture), rozwój narzędzi workflow/BPM, dBPM (dynamic BPM), REST
(Representational state transfer), a w ostatnim czasie
rozwój modelu chmury (Cloud computing) wraz
z coraz powszechniejszym udostępnianiem w sieci usług w modelu SaaS (a także IaaS i PaaS). Warto
zwrócić uwagę, że tego rodzaju zmiany są trudne do
przyjęcia, ponieważ wymagają znacznego zaangażowania po stronie klienta i jego współpracy z dostawcą
oprogramowania.
Chmura
Jednym z obecnie największych wyzwań jest cloud
computing. To typowa innowacja, która zmienia dotychczasową filozofię dostarczania oprogramowania
klientom. Jej konsekwencją jest przekierowanie na
inne tory myślenia o rozwiązaniach IT zarówno
po stronie dostawców, jaki i użytkowników.
Wsparcie społeczności
W przypadku wielu wdrożeń i projektów tworzenia rozwiązań dedykowanych ważnym czynnikiem
sukcesu jest możliwość współpracy twórców oprogramowania z jego użytkownikami. Rola klienta nie
powinna sprowadza
się wyłącznie do złożenia zamówienia. Ważne jest
środowisko tworzenia i budowania aplikacji, dobre
IDE, wsparcie do debugowania, wsparcie do wykonywania testów jednostkowych, narzędzia SCM
(Software configuration management). Ważna jest
też społeczność – otoczenie – zgromadzona wokół
danej technologii. Na nie składają się firmy i ludzie,
którzy dostarczają bibliotek, dzielą się doświadczeniami, a nawet aplikacjami wykorzystującymi technologię. Umiejętność korzystania z tego rodzaju społeczności ułatwia tworzenie nowych rozwiązań.
Nieświadomi sobie szkodzą
Postęp technologii jest wyzwaniem także dla samych
firm. Nieświadomość postępu doprowadza czasem
do sytuacji, w których organizacja zostaje ze starą
technologią, co w konsekwencji powoduje problemy przy dalszym rozwoju systemu czy aktualizacji.
(np. poprzez uniemożliwienie migracji do nowej wersji systemu operacyjnego). Tacy „maruderzy technologiczni” narażają się na duże trudności w funkcjonowaniu przedsiębiorstwa, co niemal zawsze skutkuje
wysokimi i nieprzewidzianymi kosztami.
Dariusz Dudek
Główny Specjalista IT, Pentacomp
Systemy Informatyczne S.A.,
www.pentacomp.pl
11
Centrum danych
– budowa czy kolokacja?
Rosnące potrzeby IT, digitalizacja kolejnych dziedzin życia, wymagające sprzętowo aplikacje, czy wreszcie ekspansja i nowe obszary działalności firm, stawiają managerom IT wyzwanie zapewnienia
przestrzeni dla rozrastających się środowisk IT. Decyzje w tym obszarze poparte są najczęściej szeregiem analiz biznesowych, ale mogą
mieć także podłoże w przyzwyczajeniach. Jedno z nich podpowiada
nam, że wykonanie czegoś samodzielnie będzie tańsze. Drugie, że
jeśli coś jest naszą własnością, to mamy nad tym większą kontrolę,
a więc mamy większe poczucie bezpieczeństwa. Czy rzeczywiście
tak jest? Co powinniśmy rozważyć podejmując decyzję dotyczącą
budowy własnego centrum danych?
Kwestia skali, czyli jakiego
centrum danych potrzebuję?
Budowa własnego centrum danych to jedna z
najważniejszych, podejmowanych na lata decyzji dotyczących infrastruktury przedsiębiorstwa. Aby inwestycja nie odpowiadała tylko na
bieżące potrzeby konieczne jest oszacowanie
niezbędnej powierzchni w określonym czasie.
Nie może to być jednak inwentaryzacja obecnego stanu serwerów i prosta ekstrapolacja, ale
bardziej złożone prognozowanie przyrostu zasobów serwerowych. To także okazja do przeprowadzenia konsolidacji istniejących, często
rozproszonych zasobów, określenia poziomu
wirtualizacji czy migracji do nowych rozwiązań np. w modelu „as a Service”„.
Dopiero taka prognoza, a wręcz strategia
rozwoju, pozwoli określić potrzeby firmy
w dłuższej perspektywie oraz konieczną –
nadmiarowość powierzchni centrum danych,
która będzie zajmowana w miarę pojawiających się w przyszłości potrzeb (warto pamiętać, że utrzymanie niewykorzystanej po-
12
wierzchni centrum danych to także bardzo
istotny koszt).
Własne centrum danych to inwestycja na
lata, ale obecnie nie mówimy już o perspektywie kilkunastoletniej. Wystarczy odwiedzić
serwerownię wybudowaną np. w 2000 roku
by zobaczyć jak szybko następuje funkcjonalne
starzenie się takich obiektów. Nowe, efektywniejsze technologie, zużywanie się istniejącej
infrastruktury, niesatysfakcjonująca efektywność energetyczna czy niezależny od inwestora
brak możliwości zwiększania mocy centrum
danych dla coraz bardziej energochłonnych
urządzeń, znacznie skraca cykl życia centrum
danych. Dlatego już na tym etapie warto rozważyć istniejące alternatywy dla budowy własnej infrastruktury.
Gdzie mogę umieścić sprzęt?
Budowa własnego centrum danych angażuje zwykle kilka działów przedsiębiorstwa oprócz IT, także administrację czy finanse.
Najczęściej wymaga stworzenia interdyscypli-
narnego zespołu projektowego, nawet jeżeli inwestycja realizowana jest przez wyspecjalizowanego dostawcę tego typu rozwiązań.
Decydując się na budowę własnego centrum danych należy pozytywnie odpowiedzieć na następujące pytania:
• Czy obecna siedziba pozwala na budowę data center? Czy dysponujemy powierzchnią nadającą się do zaadoptowania na potrzeby tego typu obiektu? Czy
kwestie własnościowe i prawne pozwalają na adaptację części budynku na ten cel?
Czy jest to docelowa (nietymczasowa) siedziba firmy?
• Konstrukcja i lokalizacja budynku – ważna
jest nośność stropów, możliwość przeprowadzenia prac budowlanych, a także czy
budynek znajduje się w miejscu nienarażonym na zdarzenia losowe (np. powodzie).
• Czy można zapewnić wystarczające i redundantne zasilanie z 2 niezależnych źródeł? Czy można umieścić w siedzibie generator prądotwórczy?
Centrum danych - budowa czy kolokacja?
• Czy można zapewnić odpowiednie chłodzenie? Czy budynek pozwala na instalację systemu chłodzenia (np. montaż chillerów, przewodów itp.)
• Jaki jest system wykrywania, sygnalizacji i gaszenia pożaru w budynku? Czy jest
możliwość montażu systemu gaszenia gazem obojętnym?
• Jakie jest bezpieczeństwo fizyczne budynku? Czy budynek chroniony jest
w trybie 24/7/365, ma system monitoringu, powiadomienia o nieuprawnionym
dostępie?
• Czy jest możliwy dostęp do budynku
przez 24 godziny na dobę i w dni wolne
od pracy w razie planowanych i nieplanowanych prac?
Decydując się na usługę kolokacji na tego typu pytania nie musimy odpowiadać, bowiem
spełnienie wszystkich powyższych wymagań
spada na dostawcę. Dynamiczny rozwój outsourcingu tego obszaru i rosnąca konkurencja
na rynku powoduje, że coraz łatwiej o usługi
kolokacji optymalnie dopasowane do specyfiki
danego środowiska IT, oferowane w dogodnym
miejscu, o poziomie bezpieczeństwa i dostępności zwykle trudno osiągalnych we własnej
lokalizacji.
Komercyjne centra danych oferują wszelkie
możliwe warianty powierzchni kolokacyjnej
- od pojedynczych U, szaf rack, poprzez odse-
parowane, specjalnie chronione boxy, po indywidualne pomieszczenia z dedykowana infrastrukturą, siecią, systemem bezpieczeństwa
w modelu DCaaS (Data Center as a Service)
czy też powierzchnię o wysokiej gęstości mocy.
Jak szybko można uruchomić
centrum danych?
Czas uruchomienia nowej serwerowni szacowany jest na 8-24 miesiące, z czego znaczną
część pochłaniają kwestie formalne, w tym
pozwolenia, ekspertyzy, projekty architektoniczne, wybór i umowy z dostawcami. Również w tym przypadku wariant kolokacyjny
ma zdecydowaną przewagę – powierzchnia
kolokacyjna jest bowiem dostępna niemalże
z dnia na dzień, po podpisaniu umowy. Wraz
z rozwojem firmy można też dowolnie zwiększyć zajmowaną powierzchnię, przepływności
ł ączy czy utylizowaną moc elektryczną.
Ile to kosztuje?
Na kluczowe koszty w wariancie budowy własnego centrum danych składają się: dostosowanie pomieszczeń, infrastruktura, przyłącza sieciowe, energetyczne, czy też nieprzewidziane
we wstępnych analizach wydatki, jak np. budowa przyłącza światłowodowego czy rozbudowa stacji transformatorowej, która odbywa
się na koszt odbiorcy.
Koszt budowy 1m2 centrum danych o standardzie Tier3 i powierzchni kilkuset metrów
kwadratowych w istniejącym już pomieszczeniu oscyluje w granicach kilkunastu tysięcy
złotych. Im mniejsza powierzchnia, tym średni koszt metra staje się wyższy.
Koszty Capex to oczywiście nie wszystko.
Niebagatelne znaczenie mają koszty związane
z zarządzaniem i utrzymaniem centrum danych. Najistotniejsze są opłaty za utylizowaną
moc, łącza (connectivity), koszty związane
z personelem technicznym dedykowanym do
utrzymania DC, umowy serwisowe, czy wymiana baterii UPS co kilka lat.
W przypadku korzystania z komercyjnego
data center koszty ograniczają się do stałych
i przewidywalnych pozycji: jednorazowa opłata aktywacyjna oraz miesięczne opłaty za powierzchnię kolokacyjną, łącza, zużycie energii
i ewentualne usługi dodatkowe np. zdalnej
pomocy.
Obecnie dostawcy oferują elastyczne formy
opłat, np. ryczałtowe bądź licznikowe rozliczanie energii, za rzeczywistą utylizację pasma,
czy szereg usług dodatkowych zawartych w cenie powierzchni. Innym argumentem przemawiającym na korzyść wariantu kolokacyjnego
jest także obserwowany na rynku spadek cen.
Edyta Marchaluk
Product Manager, GTS Poland
Decyzja „budować czy kolokować” wymaga przeanalizowania wielu czynników, w tym rozważenia, czy budowa i utrzymywanie własnego centrum danych
przyniesie strategiczne korzyści firmie, jakie są najważniejsze cele biznesowe i najlepsze sposoby wykorzystania wewnętrznych zasobów firmy.
Zatem czy warto podejmować wysiłek budowania własnego centrum danych?
Korzyści kolokacji vs budowa własnego centrum danych
Własne centrum danych
Całkowita kontrola nad data center: dostępem, warunkami
środowiskowymi, sposobem wykorzystania
Kolokacja w komercyjnym data center
Redundancja i niezawodność trudno osiągalna
w serwerowniach budowanych „in house”
Przewidywalne, stałe opłaty za rzeczywiste wykorzystanie
zasobów
Bliska odległość od data center, stały, nieograniczony dostęp
Przesunięcie kosztów z CapEx do OpEx
Brak kosztów utrzymania, serwisu, personelu Łatwy i szybki dostęp do powierzchni o wysokich parametrach
środowiskowych i zasilania
Skalowalność - elastyczne powiększenie zajmowanej
powierzchni wraz z rozwojem środowiska IT
Wiedza doświadczonych, wyspecjalizowanych
w data center specjalistów
Wsparcie techniczne
Odpowiedzialność za utrzymanie infrastruktury
i optymalnych warunków spoczywa na dostawcy
13
Zarządzanie
infrastrukturą
centrum danych wypełnia lukę
pomiędzy IT a obiektami
W dobie oszczędności i kryzysu gospodarczego menedżerowie
centrów danych znajdują się pod ogromną presją podnoszenia
efektywności działalności i zwiększenia wykorzystania dostępnych
zasobów. Są zmuszeni do podwyższania wydajności i redukcji
kosztów przy jednoczesnym zachowaniu dostępności.
W
odpowiedzi na to zapotrzebowanie
departamenty IT wdrażają technologię wirtualizacji, środowiska cloud
computingu i ujednoliconego przetwarzania dla
systemów logicznych. Takie działania są efektywne dla IT, ale jednocześnie tworzą nowe zależności w systemach fizycznych zarządzanych przez
departamenty obiektów i skutkują zmianami
w zarządzaniu zasilaniem, chłodzeniem i przestrzenią fizyczną. Czynniki te w połączeniu
z rosnącymi kosztami energii elektrycznej, wymaganiami dotyczącymi zgodności z przepisami
i umowami SLA powodują, że menedżerowie
centrum danych są zmuszeni zajmować się nie
tylko działaniem sprzętu IT, ale także kompleksową obsługą całości infrastruktury centrum danych jako elementów ekosystemu.
Infrastruktura centrum danych to coś więcej
niż tradycyjny sprzęt i sieci IT: obejmuje również
systemy zasilania, klimatyzacji, zasilacze UPS
i generatory oraz powiązane urządzenia przełączające. Komponenty te składają się na precyzyjnie dostrojony ekosystem, a jakakolwiek zmiana
jednego składnika może mieć szkodliwy lub nieprzewidywalny wpływ na pozostałe elementy.
Infrastruktura centrum danych (zasilanie,
chłodzenie i przestrzeń fizyczna) oraz infrastruktura teleinformatyczna są zazwyczaj zarządzane niezależnie przez oddzielne zespoły.
Każda warstwa jest zarządzana w sposób konserwatywny. Systemy zasilania i chłodzenia są
zwymiarowane w sposób umożliwiający zapewnienie odpowiedniej wydajności sprzętu
IT, a systemy IT wdrażane w sposób gwarantujący ich działanie w ramach limitów zasilania
i chłodzenia, co w rzeczywistości powoduje
14
konieczność zwiększenia bufora operacyjnego
zaprojektowanego wcześniej dla systemu. Takie
podejście sprawia, że zespoły obiektów zarządzają dostępnością centrum danych w sposób
skuteczny, ale mało efektywny. W dobie technologii wirtualizacji, cloud computingu i ujednoliconego przetwarzania takie podejście staje
się mało praktyczne. Menedżerowie centrum
danych muszą przyjąć bardziej kompleksową
zintegrowaną koncepcję nie tylko dla sprawnego
zarządzania efektywnością i kosztami, ale także
dla zagwarantowania wysokiej elastyczności,
realizacji umów o poziomie usług i możliwości
świadczenia usług IT.
Operatorzy centrum danych potrzebują rozwiązania zarządzania infrastrukturą spójnego
dla systemów IT i obiektów. Powinno ono być
skalowalne, bezpieczne, działające w czasie rzeczywistym, modułowe, łatwe we wdrożeniu
oraz kompatybilne z funkcjonującymi systemami zarządzania IT i obiektami, a także oferować
możliwość zdalnego zarządzania. Poszukując
rozwiązań automatyzacji operacji muszą oni
wybrać wszechstronną platformę, która umożliwi zbudowanie podstaw i sprawne rozwiązanie
pilnych problemów przy jednoczesnym zapewnieniu skalowalności pozwalającej reagować na
przyszłe potrzeby. A dla zapewnienia sprawnego
wdrożenia muszą także dokumentować procesy
i dostosować strukturę organizacyjną.
Podstawą trafnych, świadomych decyzji jest
kompleksowy wgląd w procesy przebiegające
w centrum danych z perspektywy infrastruktury centrum danych i infrastruktury IT. Konieczne jest uwzględnienie statycznego charakteru
dotychczasowego zarządzania centrum danych
całkowicie odmiennego od dynamiki nowych
technologii. Brak danych w czasie rzeczywistym,
to jest informacji o IT i obiektach, gromadzonych
niemal natychmiastowo za pośrednictwem natywnego systemu komunikacji pomiędzy urządzeniami, nie jest możliwe przyjęcie wiarygodnych założeń i podejmowanie trafnych decyzji
dotyczących kondycji centrum danych. Brak
funkcji w czasie rzeczywistym wpływa negatywnie na możliwości zarządzania problemem stwarzając ryzyko przeoczenia krytycznych zdarzeń
i pojawienia się istotnych zagrożeń dla infrastruktury. Ponadto obsługa w czasie rzeczywistym
staje się niezbędna dla bardziej precyzyjnego dostosowania zasobów fizycznych do obciążeń IT
i uzyskania wyższej wydajności.
IT a obiekty: luka
uniemożliwiająca optymalizację
Na przestrzeni ostatnich kilkunastu lat działy
IT i administracji obiektów zostały zmuszone
do przedefiniowania dotychczasowego statycznego podejścia do zasobów, by sprostać środowisku szybko zmieniających się potrzeb biznesowych. Podobnie jak departamenty IT podjęły
wyzwanie wdrożenia dostosowanych usług biznesowych: standaryzowanych, mierzalnych, elastycznych i adaptowalnych - tak samo zespoły
zarządzania obiektem muszą zapewnić działom
IT zasoby na żądanie (przestrzeń fizyczną, zasilanie, ogrzewanie, wentylację i klimatyzację),
które umożliwią świadczenie takich dynamicznych usług biznesowych.
Przy rosnącej zależności pomiędzy sferą IT
i obiektem, kwestią najważniejszą staje się wymiana informacji o zdarzeniach historycznych
Zarządzanie infrastrukturą
i w czasie rzeczywistym, która umożliwi dynamiczne dostosowywanie sposobu wykorzystywania zasobów. Zarządca obiektu polegając na
podstawowej prognozie mocy może w pewnej
mierze przewidzieć zapotrzebowanie IT na zasoby. Jednak wyłącznie w czasie rzeczywistym
można dostrzec dynamiczny charakter reakcji
centrum danych na potrzeby.
Trudność polega na tym, że menedżerowie IT
nie są informowani na bieżąco przez menedżerów budynków o wzajemnie powiązanych obciążeniach, czyli o codziennych zmianach kosztów
zasobów i mediów, a menedżerowie obiektu
o umowach o poziomie świadczenia usług
(SLA), do których przestrzegania podczas zaspokajania potrzeb firmy są zobowiązani menedżerowie IT. Nawiązanie ściślejszej współpracy
pozwala zarządcom obiektu zrozumieć drobne
niuanse planowania wydajności oraz uczestniczyć w identyfikacji zalet i wad wykorzystywania zasobów w obrębie centrum danych.
Ponadto, lepsze relacje zapewnią menedżerom
centrum danych informacje o kosztach zasobów
centrum danych i ułatwią podejmowanie decyzji dotyczących doboru aktywów, planowania
priorytetów i czynności off-line. W następstwie
lepszego zrozumienia tych wzajemnych oddziaływań oraz misji biznesowej oczywista staje się
kwestia potrzeby wdrożenia rozwiązania do
Zarządzania Infrastrukturą Centrum Danych
(Data Center Infrastructure Management
– DCIM).
Personel działu IT i obiektu musi przyjąć
bardziej dynamiczne podejście do zarządzania
wydajnością, które wymaga dostępu przez obie
strony do bieżących danych operacyjnych dotyczących mocy obliczeniowej, zasilania, chłodzenia i przestrzeni fizycznej.
Obecnie brakuje zintegrowanych danych niezbędnych do zarządzania wydajnością. Z tego
powodu większość departamentów IT wybiera
konserwatywny, minimalizujący ryzyko sposób
zarządzania. Jest to konieczna strategia i chociaż
zarządzanie efektywnością ma dziś wyższy priorytet niż w przeszłości to jednak zajmuje ono
drugie miejsce po dostępności. Koszt pojedynczego przestoju może przewyższać oszczędności
uzyskane dzięki wyższej efektywności. Sytuacja,
w której efektywność jest realizowana kosztem
niezawodności stwarza zagrożenie dla zdolności
centrum danych do obsługi firmy i może zmusić osoby zarządzające nim do szukania pracy
gdzie indziej.
Połączenie: Zarządzanie
Infrastrukturą Centrum Danych
Jeżeli rozwój centrum danych ma zmierzać
w kierunku zapewniania wyższej efektywności, wydajności i dostępności, to konieczne jest
zmniejszenie przepaści pomiędzy warstwą IT i
warstwą infrastruktury fizycznej centrum danych i stworzenie możliwości zarządzania nimi
jako jednym systemem.
Najlepszym sposobem osiągnięcia owocnej
integracji infrastruktury IT i obiektu jest wdrożenie efektywnego Zarządzania Infrastrukturą
Centrum Danych (DCIM). Krytycznym elementem staje się szczegółowy monitoring i pomiar w czasie rzeczywistym osiągów centrum
danych, wykorzystania i zużycia energii elektrycznej. Pozwala on menedżerom centrum danych podejmować trafne decyzje, odpowiednio
planować, a przez to optymalizować operacje.
DCIM oznacza możliwość wszechstronnego
zarządzania infrastrukturą centrum danych
poprzez optymalizację zasobów, efektywności
i dostępności. DCIM obejmuje zarządzanie warstwą fizyczną infrastruktury centrum danych,
warstwą infrastruktury IT oraz luką pomiędzy
nimi. Infrastruktura IT w pewnym sensie obejmuje platformę wirtualizacji, ponieważ dynamicznie przełączające się serwery wirtualne oddziałują na serwery fizyczne, na których są one
zainstalowane.
Dopiero niedawno pojawiły się na rynku
w pełni zintegrowane kompleksowe rozwiązania DCIM. Uniwersalna koncepcja DCIM daje
nowe spojrzenie na relacje pomiędzy obiektami
a komponentami infrastruktury IT i umożliwia
menedżerom centrum danych wyższą optymalizację wykorzystania zasobów centrum danych.
Prawidłowe wdrożenie strategii DCIM wymaga
doboru optymalnego pakietu sprzętu, oprogramowania i usług, który umożliwi menedżerom
centrum danych zapełnić lukę w krytycznej infrastrukturze.
Przed wdrożeniem rozwiązania DCIM menedżerowie centrum danych muszą odpowiedzieć sobie na wiele pytań:
• Które aktywa mają krytyczne znaczenie
dla infrastruktury mojego centrum danych
i jakie są zależności pomiędzy nimi? Repozytorium zasobów umożliwia menedżerom centrum danych realny wgląd w naj-
15
cenniejsze zasoby, a także kontekstowe spojrzenie na nie w perspektywie przyszłego
rozwoju centrum danych. Taka wybiegająca
w przyszłość analiza daje biznesowy wgląd
w krytyczne aktywa i gwarantuje osiągnięcie wyższego współczynnika zwrotu inwestycji (ROI) na aktywach. Pozwala także
uwolnić i przeznaczyć środki na inne istotne priorytety kluczowe dla menedżerów
centrum danych.
• Czy poproszony przez przełożonych będę
w stanie szybko sporządzić obszerny raport
monitorowania i analizy wszystkich aktywów centrum danych? Czy raport ten zidentyfikuje wąskie gardła centrum danych?
Efektywne rozwiązanie DCIM to produkt,
który w czasie rzeczywistym będzie monitorować wszystkie parametry przestrzeni fizycznej, zasilania i chłodzenia środowiska centrum danych. Korzystanie z modelowych i chwilowych danych realnych zbieranych w dużych odstępach czasu może prowadzić do przeoczeń i uniemożliwiać szybkie rozwiązywanie problemów oraz przewidywanie nieuchronnych zdarzeń. Rozwiązanie DCIM powinno oferować pulpity nawigacyjne oraz raportowanie w czasie rzeczywistym umożliwiające menedżerom centrum danych podejmowanie proaktywnych działań w celu zapobiegania awarii operacyjnej mającej swoje źródło w infrastrukturze. Raporty na temat infrastruktury centrum danych powinny być dostępne
na żądanie i sporządzane w czasie rzeczywistym, co pozwoli utrzymać dostępność i obniżać koszty.
• Czy moje centrum danych jest w stanie elastycznie obsługiwać codzienne obciążenia
i jednocześnie reagować na bieżące wymagania stawiane mojej firmie? Rozwiązanie
DCIM powinno obejmować przepływ prac
w procesie i zapewniać:
– Scenariusze rozwoju - możliwość modelowania zmian przed ich wdrożeniem;
– Wbudowane procesy zawierające kroki, których ukończenie jest konieczne
przed zatwierdzeniem działania;
– Wskaźniki dla umów o poziom świadczenia usług (SLA), będące standardowymi lub indywidualnymi miarami
sukcesu;
– Raportowanie informacji o niedostatecznie wykorzystywanej przestrzeni
fizycznej, mocy zasilania i chłodzenia.
Funkcja ta powinna rekomendować
optymalne rozmieszczenie urządzeń
na podstawie ich unikatowych wymagań oraz informować o bieżącym obciążeniu i wydajności infrastruktury.
• Czy oprogramowanie DCIM oferuje analizę tendencji i wiedzę niezbędną mojemu
zespołowi do opracowania całościowego
planu zarządzania wydajnością? Rozwiązania DCIM, dla zapewnienia kontroli bieżącego i przyszłego wykorzystania zasobów
centrum danych, powinny zapewniać menedżerom wgląd w:
– Potoki rzutowania - statusy projektów
na różnym etapie zatwierdzania oraz informacje o ich wpływie na infrastrukturę;
– Tendencje bieżącego i planowanego wykorzystania zasobów (na podstawie
danych historycznych). Menedżerowie
centrum danych powinni na przykład
być w stanie, na podstawie tendencji
wykorzystania, określić moment, kiedy moc i chłodzenie staną się niewystarczające.
• Jakie narzędzia internetowe raportowania dla kierownictwa i planistyczne zawiera rozwiązanie? Oprogramowanie DCIM
powinno standardowo zawierać konfigurowalne internetowe pulpity nawigacyjne i
narzędzia analityczne. Automatyzacja gromadzenia informacji o operacjach i raportowania za pomocą uniwersalnego internetowego pulpitu nawigacyjnego umożliwia
opracowywanie informacji zarządczych,
które stają się następnie jedynym źródłem
wiedzy dla DCIM i planowania. • Czy rozwiązanie DCIM dostosowuje się
do usług IT i biznesowych? Dostosowanie
usług IT w sposób gwarantujący realizację
celów i potrzeb biznesowych ma nadrzędne znaczenie. Każde rozwiązanie DCIM
musi umożliwiać kierownictwu centrum
danych dostosowanie wykorzystania zasobów do strategii Systemów Zarządzania IT
(ITSM), metodyki ITIL oraz strategii Zarządzania Usługą Biznesową (BSM).
Przyszłość DCIM
Obecnie menedżerowie centrum danych znajdują się pod presją redukcji kosztów i podnoszenia
poziomu usług. Na rynku dostępnych jest wiele
technologii wspomagających osiągnięcie tego celu: wirtualizacja, wysokoefektywne źródła zasilania serwerów oraz nowe technologie zasilania
i chłodzenia. Technologie te, wraz z opracowanymi w ostatnich latach dobrymi praktykami,
mogą przyczynić się do redukcji poboru energii,
ale nie umożliwiają wdrożenia prawdziwej optymalizacji. Optymalizacja centrum danych w kategoriach efektywności, wydajności i dostępności
wymaga znalezienia punktu pełnego wykorzystania zasobów bez zwiększania ryzyka awarii.
W ostatnich kilku latach wiele czynników
złożyło się na zwrot rynku w kierunku rozwiązań DCIM. Kluczowymi elementami prawidłowego funkcjonowania IT stało się zużycie energii
i wykorzystanie przestrzeni. Narzędzia DCIM
rozwijają się szybko i w najbliższych latach staną
się kluczowym elementem arsenału operatorów centrum danych. Dostarczać będą cennych
danych niezbędnych dla raportowania i uzyskiwania wyższych oszczędności energetycznych,
identyfikowania problematycznych punktów
infrastruktury i podnoszenia efektywności planowania wydajności. Według instytutu Gartner
„ponad 50% operatorów centrum danych wdroży narzędzia DCIM w 2013 roku”1.
Obecnie nadszedł czas, aby firmy przyjęły całościową koncepcję zarządzania infrastrukturą
centrum danych w czasie rzeczywistym i połączyły w sposób kompleksowy zarządzanie IT
i obiektami.
1
Raport Gartner, Net IT Out: DCIM New Tools to Monitor, Manage and Control Your Data Center, IT Jay Pultz, Infrastructure,
Operations & Management Summit, 5-7 czerwca, 2012 Orlando, Floryda
Piotr Kowalski,
Dyrektor Działu Inżynierskiego
w Emerson Network Power
16
Gdy gra przekracza
granice ekranu
Zasiadając przed swoją ukochaną konsolą po ciężkim i wyczerpującym dniu nauki, czy pracy liczymy na chwilę relaksu po trudach dnia
codziennego.Efekt takiego „odstresowywania się” jest o tyle lepszy,
o ile dany tytuł spełnia swój główny cel, którym jest dostarczenie
szeroko pojętej rozrywki, czy to za sprawą hipnotyzującej zmysły
grafiki, urzekającej ścieżki dźwiękowej, zapierającej dech w piersiach fabuły, czy pompującej do krwi adrenalinę akcji.
N
ie możemy jednak zapominać o równie istotnej, co wręcz podstawowej
roli elektronicznej rozrywki, a więc
udostępnieniu nam sposobu, do chociaż chwilowej ucieczki od rzeczywistości i zapomnieniu
o jej problemach. To główny powód, dla którego
(oprócz aspektów technicznych) w pierwszych
grach królowały wszelakiej maści światy science-fiction i fantasy. Wraz z upływem lat można
zauważyć diametralną zmianę tej tendencji, do
tego stopnia, iż ogromna część gier osadza gracza w faktycznie istniejących lokalizacjach, czy
miastach, a samo ich przedstawianie w coraz
większym stopniu nabiera cechy fotorealizmu.
Podobnie sprawa ma się z wydarzeniami przedstawianymi na ekranach naszych monitorów,
dzięki czemu każdy z nas może stać się członkiem oddziału desantowego na Normandię,
zatańczyć na scenie „Thriller’a” z samym Michaelem, przytrzeć lakier Hamiltonowi na torze w Monaco, czy nawet rzucić mokasynem w
prezydenta USA. Jak dotąd, pomimo ciągłych
prób samych deweloperów, aby wpłynąć na
nasz realny byt za pośrednictwem gier, jak chociażby standardowy już proceder umieszczania
reklam firm w świecie gry, granica pomiędzy
prawdziwym życiem, a jego wirtualnym odpowiednikiem zawsze zawierała się w brzegach
ekranu i przycisku włączania konsoli. Na samą
przyjemność „szarpania” w ulubione tytuły
składa się pewien wachlarz przyzwyczajeń i zachowań, który poniekąd wynika z umowności
wykreowanego świata. Każdy gracz doskonale
zna i wręcz ubóstwia zbieranie punktów doświadczeń, „żyłowanie” i poprawienie wyników
swoich oraz znajomych, nabijanie kolejnych le-
17
veli, wypełnianie questów, czy zdobywanie
osiągnięć i trofeów. To właśnie te czynniki tak
bardzo nas nakręcają i nie pozwalają odejść od
konsoli, niejednokrotnie sprawiając, że dzięki
syndromowi „jeszcze jednej godziny” doświadczymy tak zapierającego dech w piersiach widoku, jakim jest wschód słońca za oknem naszego
pokoju… i totalny zgon dwie godziny później
w szkole, lub pracy. Skoro te, tak doskonale nam
znane i wyuczone „growe czynności” potrafią
dawać nam tyle frajdy, jednocześnie zmuszając
nas do takich poświęceń, to dlaczego nie moż-
na wykorzystać tego zjawiska w normalnym,
zupełnie niewirtualnym życiu? Tak się składa,
że można.
Gamifikacyjny biznes
Nie od dziś wiadomo, że pieniądz rządzi światem. Jeżeli ktoś się z tym nie zgadza, to znaczy,
że nigdy nie wziął pożyczki z banku, lub jeszcze
nie zaczął jej spłacać. Menadżerowie oraz spece
od marketingu wielkich, zamożnych i niestety,
generalnie chciwych korporacji tego świata, prężą się jak pawian na stronie, aby znaleźć nowe
Gdy gra przekracza granice ekranu
alnym to jedno, ale każdy gracz doskonale wie,
że nic tak nie potrafi zwiększyć zaangażowania
w wykonywaniu danej czynności, jak gwarancja
otrzymania za nią nagrody, a głównym atutem
opisywanego fenomenu jest właśnie możliwość
uzyskania gratyfikacji w czysto realnej formie.
O potencjale, jaki kryje w sobie grywalizacja
świadczyć może fakt, iż w tym roku odbyła się
pierwsza, w całości poświęcona jej konferencja
– Gamification Summit 2011.
Jak nawozić,
żeby się nie nawozić
Kolejnym krokiem na drodze do ingerencji
w nasze życie, zaraz po wyżej wspomnianych
tytułach jest… pielenie grządek – tych wirtualnych, jak na razie. Niepodważalny hit ostatnich
miesięcy, czerpiący garściami z konsolowego
Harvest Moon’a, przeglądarkowy Farmville bije
rekordy popularności, przynosząc jej producentowi, firmie Zynga ogromne dochody. Można
mieć swoje zdanie na temat ambitności podobnych produkcji, w których rdzeń rozgrywki
sposoby wypchania swoich i tak już rozdętych
do granic możliwości portfeli. Tak więc, ktoś zauważył wyżej wspomniany fenomen, dokonał
skrupulatnych kalkulacji i wywnioskował, że na
„grze w życie” można naprawdę nieźle zarobić.
Czym więc jest grywalizacja, lub gramifikacja,
jeżeli ktoś lubi synonimy? Tak naprawdę jest to
stosunkowo nowe słowo i „odkrycie”, które trafiło do biznesowego słownika dopiero w 2010
roku. Generalnie oznacza ono przenoszenie do
realnego świata wszystkich tych mechanizmów
i zachowań, którymi rządzą się gry wideo, a które my, gracze tak dobrze znamy i kochamy. To
zupełna odwrotność tego, co do tej pory znaliśmy – to nie gra naśladuje życie, to życie naśladuje grę. Samo zjawisko dość szczodrze czerpie
ze znanych już programów lojalnościowych, jednakże to tylko preludium do rozwiązań i pomysłów, jakie stworzy ludzka kreatywność, napędzana chęcią zysku. Samo nabijanie punktów
za korzystanie z usług konkretnego producenta
i idące za tym różnorakie wynagrodzenie, to relatywnie stare i tak naprawdę tylko podświadomie wykorzystujące schemat grywalizacji rozwiązanie. Zjawisko zacierania granicy między
życiem a grą ma miejsce już od jakiegoś czasu,
subtelnie, acz konsekwentnie rozwijając swoją
ideę. Przypomnijmy sobie popularną matę do
ćwiczeń Wii Fit od Nintendo, za sprawą, której „tylko gra” stawała się profesjonalnym programem treningowym, analogicznym do jego
prawdziwego odpowiednika. Nie sposób nie
wspomnieć o święcącej swego czasu tryumfy
serii Guitar Hero od giganta gier muzycznych
Harmonix. Dzięki kontrolerom imitującym
wyglądem i funkcjonalnością prawdziwe instrumenty, mogliśmy, chociaż przez chwilę poczuć
się jak prawdziwe gwiazdy rocka. Immersja
i zlewanie się codzienności ze światem wirtu-
Dzięki Chromaroma , nawet zwykła podróż londyńskim metrem może zamienić się
w questa rodem z prawdziwqego RPG’a.
Jeżdżąc ekonomicznie sprawisz, że twoje wirtualne drzewko po prawej zacznie
powoli rosnąć.
18
Możemy snuć własne teorie spiskowe na temat wołowiny w BigMac’ach,
wale chyba każdy chciałby spróbować zagrać na takim ekranie.
ogranicza się do dojenia „łaciatych” i nawożenia plantacji kopru, co nie zmienia faktu, że gra
stała się światowym fenomenem. Szacuje się, że
około 100 milionów osób dziennie (sic!) zasiada
przed komputerem, by sprawdzić ilość zniesionych przez jego kury jajek. Gra do tego stopnia
ingeruje w nasz plan dnia, że za coś zupełnie normalnego uważa się wstawanie wcześniej rano do
pracy, aby tylko zdążyć zasiać kolejne plansze
zakupionymi nasionami. Wszędzie tam gdzie
jest kosmiczna popularność „produktu”, pojawiają się coraz to nowsze sposoby zarobienia na
nich przez osoby trzecie. Nie inaczej jest w tym
przypadku, gdyż już teraz każdy z nas może zakupić specjalny, dedykowany poradnik, jak zostać najlepszym we wsi wirtualnym farmerem.
Kolejnym przykładem, który jeszcze lepiej zobrazuje istotę grywalizacji, jest aplikacja Chromaroma, w którą od jakiegoś czasu „zagrywają”
się mieszkańcy Londynu. Korzystając „często
i gęsto” z londyńskiej komunikacji miejskiej
i posiadając kartę z nabitym biletem, za każdym
razem, gdy zbliżymy ją do kasownika, program
rejestruje nasze położenie. W ten sposób możemy wykonywać zlecone nam zadania, poprzez
dotarcie w wyznaczone miejsce, za co dostajemy
punkty, „zdobywając” ze znajomymi wyznaczone tereny. Program zachęca do przejścia niektórych odcinków pieszo, oferując powiększenie
naszego wyniku o odpowiednią wartość. Podobną, lecz znacznie bardziej rozwiniętą strukturę działania posiada Foursquare, do którego
potrzebujemy wyłącznie telefonu komórkowego. Za pomocą wbudowanego w aparat modułu GPS możemy informować znajomych gdzie
jesteśmy, sprawdzając jednocześnie najczęściej
odwiedzane przez nich lokale. Jeżeli dana miejscówka nie znajduje się na liście aplikacji, można
ją tam bardzo łatwo dodać. Często odwiedzając dane kina, knajpy czy bary dostajemy specjalne punkty, możemy też zostać nagrodzeni
medalami za wykonywanie zleconych zadań,
19
a nawet uzyskać z tego tytułu profity i zniżki
w danych lokalach, co w tym miejscu odsłania
marketingowy charakter aplikacji. Jeżeli lubicie pstrykanie fotek, to powinien was zainteresować Appysnap. Zabawa polega na robieniu
zdjęć na swoim telefonie, wypełniając podane
w zadaniu warunki. Tak, więc na początku
musimy uwiecznić naszą prywatną i osobistą
facjatę, na co mamy godzinę czasu. Później poziom trudności rośnie, wymagając od nas na
przykład odpowiedniej liczby osób w kadrze,
czy konkretnej imprezy w tle (znów marketing
gdyby ktoś nie zauważył). Najlepsi „domorośli
paparazzi” mają szansę na nagrody rzeczowe.
Lubicie porządki domowe? Też pytanie – każdy je wręcz kocha i aż płacze z radości, gdy łapie
w dłoń ścierę. Jeżeli jednak należycie do tego
minimalnego odsetka populacji, która nie może poradzić sobie z psychiczną barierą, blokująca gwałtowny wzrost endorfiny w organizmie
w czasie mopowania posadzki, to Chore Wars
jest stworzone wprost dla was. Zabawa polega
na wykonywaniu tak prozaicznych czynności
jak mycie zlewu, szorowanie wanny, czy zaprzyjaźnienie się z „WC kaczką”, za co rzecz jasna
dostajemy punkty, ścigamy się ze znajomymi
w rankingach i pretendujemy do tytułu „najzacniejszego technika higieny domowej”. Punkty
wystawiają oczywiście bezstronni sędziowie,
w postaci zadowolonych z pracowitości swoich
pociech rodziców. Grywalizacyjny trend nie
omija także i tych ostatnich, nabierając delikatnego, ekologicznego posmaku. W trosce o nasze
środowisko, hybrydowe modele Forda, załączyły do swoich bajeranckich komputerów pokładowych specjalny segment, imitujący rosnące,
wirtualne drzewko. Jeżeli będziemy jeździć
w sposób oszczędny, walcząc z przemożną chęcią wciskania pedału gazu do samej podłogi, to
nasza roślinka zacznie rozkwitać, wizualnie dając nam do zrozumienia, że przyczyniamy się do
ochrony środowiska. Wyniki możemy porównywać dla przykładu na 100 km odcinku, co
słusznie może przywodzić na myśl słynne „masterowanie wyników”. W tej pięknej idei jest też
i ciemna strona mocy, żerująca na ludzkiej zachłanności, która niweczy pierwotne założenia
twórców tego rozwiązania. Zanotowano przypadki, gdy kierowcy przejeżdżali na czerwonym
świetle, nie chcąc się zatrzymywać, gdyż ponowne ruszenie z miejsca sprawia, że licznik spalania
szybuje pod sufit, psując rekordowy wynik. Na
takich „fanatycznych ekologów” znaleźli sposób
Szwedzi. Gdy widzimy znajdujący się w pobliżu
fotoradar (załóżmy, że wyjątkowo nie jest to atrapa), to mimowolnie odczuwamy chęć schowania twarzy za kierownicą, a jeszcze lepiej zasłonięcia nią tablicy rejestracyjnej. Projekt Speed
Camera Lottery działa na zupełnie odmiennej
zasadzie niż znany nam system mandatowy. Radary robią zdjęcia losowym samochodom, które
przestrzegały przepisów ruchu drogowego, automatycznie włączając ich do loterii, w której
wygrana czerpana jest z puli mandatów zapłaconych przez piratów drogowych. Eksperyment
przyniósł efekt, zmniejszając średnią prędkość
o ok. 10 kilometrów. Jak już o przemierzaniu
odległości mowa, to warto wspomnieć o kolejnym pomyśle promującym tym razem zdrowie,
którego autorem jest firma Nike. Jej aplikacja
Nike + Tag zachęca nas do biegania, a wszystko,
czego potrzebujemy to telefon z GPS i specjalny sensor, który zlicza dokładną odległość, jaką
przebiegliśmy, spalone przez nas kalorie, czas,
czy średnią prędkość. Swoje wyniki możemy
wrzucić do sieci, porównując je z osiągnięciami
znajomych. Najsłabszy wynik w grupie zostaje
„otagowany”, co poniekąd zmuszą delikwenta
do poprawienia swojego rezultatu. Kolejny gi-
Wystarczy smartfon, specjalny sensor i (opcjonalnie, dla chętnych) buty, aby zwykłe,
poranne bieganie przerodziło się w rywalizacje z przyjaciółmi o jak najlepsze wyniki.
Gdy gra przekracza granice ekranu
gant naszego świata, tym razem ten mniej dbający o nasze zdrowie, czyli McDonald’s wymyślił
genialną akcję promocyjną, w której zwycięzca może odebrać nagrodę dosłownie od razu.
Zawiesił on w centrum Sztokholmu (Szwedzi
prekursorem gamifikacji?) ogromny billboard,
na którym każdy może zagrać w partyjkę sędziwego Ponga. Wystarczy, że na swoim smartfonie wejdziesz na odpowiednią stronę internetową, wybierzesz proponowaną nagrodę z menu,
a następnie sterując za pomocą telefonu nie
zaliczysz zbicia w ciągu pół minuty. Wtedy na
naszej komórce ląduje wirtualny kupon, który
możemy zrealizować tuż za rogiem.
Super 5 Beer Combo, please!
Jak doskonale widać na załączonych przykładach potencjał tkwiący w zjawisku grywalizacji
jest ogromny, a jego wykorzystanie nieraz wykracza poza granice bezlitosnego marketingu.
Wszystko opiera się na sposobie przeszczepienia naszych growych przyzwyczajeń na grunt
codziennej egzystencji i wdrożenia ich w zwyczajne obowiązki. Sprzątanie domu, jako sposób do nabijania kolejnych poziomów, już był,
a więc osiągnięcie levelu 30, odblokowujące
możliwość zmierzenia się z klozetowym bossem za pomocą „buławy przepychu” nikogo nie
powinien już dziwić. A co gdybyśmy dostawali
dodatkowe punkty doświadczenia z punktualne pojawianie się w pracy? A może warto powalczyć o specjalny mnożnik punktów, poprzez
szybsze wykonanie zadania, lub zrobienie tego
w grupie? Bardzo ciekawym pomysłem byłoby
wykorzystanie znanego nam z gier określenia
„combo”, oznaczające wykonywanie po sobie
pod rząd określonych czynności. Zamiast zaserwować oponentowi Super Combo Finish, moglibyśmy wypić kilka puszek napoju, czy piwa
za jednym zamachem. Taki „atak” umożliwiłby nam dostanie specjalnego bonusu, w postaci +1 do obrażeń. Bonusu z pianką rzecz jasna.
Rentowność inwestowania w strategie grywalizacyjne została potwierdzona w badaniach
naukowych. Jak donosi Nielsen Online, granie
to druga, zaraz po buszowaniu po portalach
społecznościowych czynność, jakiej oddają się
w Internecie Amerykanie, poświęcając jej miesięcznie kolosalną liczbę 407 mln godzin. Według innych badań obecna, szacunkowa wartość
rynku grywalizacji wynosi 100 mln dolarów,
a w przeciągu najbliższych 4 lat, wartość ta ma
wzrosnąć do 1,6 mld „zielonych”, zaś sama liczba tego typu aplikacji, oferowana przez koncerny ma podskoczyć o ok. 70%. Ponadto według
firmy M2 Research, ponad 45% firm przyglądających się metodom gamifikacyjnym za cel stawia sobie zwiększenie zaangażowania użytkowników produktu, 1/3 pragnie umocnić lojalność
klienta wobec marki, a co piąta chce podnieść jej
świadomość na rynku. Wbrew pozorom zalety
opisywanego trendu niekoniecznie muszą się
ograniczać wyłącznie do celów komercyjnych,
Przyszłość, w której życie stanie się jedną wielką grą, jest na szczęście naprawdę odległa,
chociaż jesteśmy na najlepszej ku temu drodze.
mając ogromne pole do popisu chociażby w samym systemie edukacji. Niejaki Lee Sheldon,
wykładowca na Uniwersytecie Indiana wpadł
na pomysł podzielenia swoich studentów na
gildie, podobne do tych z World of Warcraft.
Uczniowie zamiast standardowych ocen otrzymywali punkty XP, których odpowiednia ilość
wymagana była do zaliczenia semestru. No
cóż, nasze punkty ECTS od dawna wykorzystują ten patent, ale jakoś mniej przyjemnie
się kojarzą. Swoje 3 grosze do tematu dorzuciła również Annath Pai, kolejna nauczycielka
w amerykańskiej szkole. Eksperyment polegał
na stosowaniu list najlepszych wyników oraz
przydzielaniu uczniom odpowiednich wyzwań,
co przyczyniło się do podniesienia średniej ocen
w klasie. Mało tego, system oceniania tak zaangażował małych podopiecznych, że zaczęli się
oni uczyć nawet zagadnień z kolejnych lat. Jeżeli dodalibyśmy do tego perki zwalniające z pisania kartkówek, czy dające „niezniszczalność”
w czasie odpowiedzi przy tablicy, to mamy
sposób na zwiększenie wyników maturalnych
o jakieś 50%.
Gracz w klatce Skinnera
Rozwodząc się nad zaletami grywalizacji, nie
możemy zapomnieć o niebezpieczeństwie, jakie niesie ona ze sobą, co niestety najczęściej
wynika z ludzkiej chciwości i niepohamowanej chęci zysku. Jak dla mnie, już teraz lekkim „przegięciem” jest brazylijska aplikacja na
Facebooka o wdzięcznej nazwie Get Closer,
nagradzająca nas punktami za jak najdłuższe
przebywanie w związku z daną osobą. Pomimo wyraźnej kontrowersyjności tegoż programu, już teraz „bawi się” nim ok. 22 tys. osób,
a liczba ta raczej będzie się powiększać. Pomimo wyraźnych, pozytywnych możliwości, jakie
ma szansę przynieść ze sobą grywalizacja, czy to
w postaci pomocy ochrony środowiska, zwiększenia efektywności pracy, czy chociażby na
gruncie edukacji, zjawisko to posiada także grupę zagorzałych przeciwników, wywodzących się
głównie ze świata nauki. Najlepszym przykładem skrajnie odmiennej opinii jest profesor
Ian Bogost, zajmujący się mediami interaktywnymi na uniwersytecie technicznym w stanie
Georgia. Uważa on, że grywalizacja jest świetnym sposobem łatwego zwiększenia zysków
kosztem samych gier, co już nie podoba się ich
twórcom. Nadmierne wykorzystywanie pozytywnie kojarzących się mechanizmów z tychże
produkcji, może doprowadzić do „zmęczenia
materiału”, pewnego przesycenia danych czynników, co przyczyni się w końcu do negatywnego postrzegania samej elektronicznej rozrywki.
Bogost zaznacza, że tak naprawdę głównym celem grywalizacji, jest eksploatacja popularnych
haseł do momentu, aż nasze kieszenie zostaną
opróżnione, a ona sama zostanie zepchana na
boczny tor przez nowy, popularny trend. Z tego powodu proponuje, aby zjawisko to nazwać
raczej „eksploatyzacją”, co uwydatni jego prawdziwe zamiary. W międzyczasie samo, zbyt
intensywne wykorzystanie gamifikacji może
stworzyć wokół nas tzw. klatkę Skinnera. Jest
to urządzenie w formie skrzynki, w którym
B. Skinner badał procesy warunkowania.
Umieszczone w niej zwierzę, wciskając przycisk
otrzymywało nagrodę, najczęściej w formie pożywienia. Obawy, że podobne skłonności mogą
przejawiać się w zachowaniu ludzi są jak najbardziej słuszne. Już teraz posiadając kartę lojalnościową danej myjni, jesteśmy w stanie jechać na
drugi koniec miasta, omijając te bliższe i tańsze,
tylko po to by zyskać kolejne punkty. Mechanizm ten faktycznie może uczynić z nas jeszcze
„wydajniejsze maszynki do wydawania pieniędzy” i zmusić do bezmyślnego wciskania przycisku, tylko po to by z otworu wyskoczył nam
kolejny do kolekcji reklamowy długopis. Oczywiście ta czarna i pesymistyczna wizja świata,
wydaje się być mało prawdopodobna, a jeżeli
już to dość odległa. Sam temat grywalizacji to
istna góra lodowa, której czubek został jedynie
nieznacznie ukazany w powyższym artykule.
Można by snuć nieskończoną ilość pomysłów
i planów, nad jego wykorzystaniem w niedalekiej przyszłości, jednakże już nie mam na to
czasu. Muszę lecieć piąty raz tego dnia wyszorować zęby, gdyż brakuje mi jedynie 200 pkt. do
rangi „nieustraszonego obrońcy szkliwa”.
Adrian „Adio” Zając
Jest studentem Informatyki na Wydziale Fizyki,
Astronomii i Informatyki Stosowanej Uniwersytetu
Jagiellońskiego. Oprócz gier komputerowych, pasjonuje się również podróżami i dziennikarstwem.
Jest redaktorem SAGE, organizacji Gamedev Students Association.
Kontakt z autorem: [email protected]
20
21
Metodyka Agile
i projekty SharePoint
– mezalians, ślub czy pogrzeb?
Metodyk zwinnych jako takich sądzę, iż nie ma potrzeby przedstawiać – oficjalnie zostały ogłoszone jako manifest już w 2001 roku. Po szczegóły, bądź dla
odświeżenia pamięci, polecam sięgnąć do tego źródła: www.agilemanifesto.
org/iso/pl/.
I
dea jest prosta i chwytliwa: w realizacji wdrożeń informatycznych ważni są ludzie, współpraca z Klientem, interakcja wewnętrzna, reagowanie na zmiany, cykliczne iteracje (trwają
od 2 do 4 tygodni, są to tzw. sprinty) no i oczywiście działające oprogramowanie. A działające
oznacza wspomagające pracę i realizację celów
biznesowych Klienta, takie, które on „wykorzystuje”, a nie „obsługuje”. No software – just tools.
Zwinność, elastyczność, interakcja vs proceduralność, formalizacja, stosy dokumentów przesłaniające ludzi po stronie dostawcy
jak i odbiorcy. Pomyśl, po której stronie widzisz
siebie? (tu nie ma złej odpowiedzi!) A jeśli zapytać, po której Klient chciałby być? Odpowiedź
brzmi: to zależy J
Stosowanie metodyk zwinnych obserwowane jest często w młodych organizacjach, co przekłada się na poczucie „luzu” w firmie (tak jego
przyczyna jak i skutek). W młodej firmie panuje
mniejsza formalizacja, spotkania odbywają się
częściej i obejmują wszystkich pracowników,
zaś dyskusje krążą wokół szybkich, ambitnych
celów. W organizacjach dojrzalszych i ustrukturyzowanych takie relacje siłą rzeczy ograniczają
się do wyspecjalizowanych zespołów, mających
własne cele cząstkowe, składające się na cele strategiczne, gdzie niekoniecznie dobrym pomysłem jest zaburzanie porządku i harmonogramu prac. Niemniej, wiele projektów wewnętrznych w takich właśnie dojrzałych organizacjach
z powodzeniem prowadzonych jest zwinnie.
By wejść w temat metodyk zwinnych głębiej
należy przyjrzeć się którejś z jej konkretnych
odmian. Jedną z popularniejszych jest Scrum.
Mniej zorientowanych zachęcam do przejrzenia
Przewodnika po Scrum: http://www.scrum.org/
storage/scrumguides/Scrum%20Guide%20-%20
PL.pdf. Godną uwagi pomocą, tym razem już
dla osób pracujących zwinnie, jest Lista Kontrolna Scrum, przygotowana i udostępniona
przez tzw. społeczność scrumowców: http://
www.scrum.org.pl/wp-content/uploads/2010/02/
Scrum_checklist_PL.pdf.
22
Lista Kontrolna Scrum – nieoficjalne, ale
uznane „musthave” dla Scrum Mastera, „mustknow” dla Scrum Membera (źródło: http://www.
scrum.org.pl)
Choć metodyk zwinnych jest wiele: Programowanie ekstremalne, Feautre Driven Developement, Test Driven Developement, etx. to
poniżej w tekście najczęściej w domyśle będę
mówił o Scrum-ie.
SharePoint
Z technologią SharePoint pracuję intensywnie już
5 lat i jestem pewien, że nadal nie poznałem jej
wszystkich możliwości.
SharePoint jest platformą wspierającą zarządzanie zawartością, obsługę dokumentów, współpracę grupową i wiele (naprawdę wiele) innych
obszarów. Jego konstrukcja u podstaw zakłada
możliwość szybkiej i łatwej rozbudowy, celem pokrywania szerokiej gamy specyficznych potrzeb
przedsiębiorstw większości branż. Architektura
SharePoint jest również gotowa by działać w wielooddziałowych organizacjach – mamy tu aplikacje webowe, kolekcje stron, aplikacje usług,
scentralizowaną administrację. (zobacz : http://
technet.microsoft.com/en-us/library/cc263121.aspx)
– jest to mocny argument, dla którego produkt
wzbudza szerokie zainteresowanie dużych podmiotów.
Rozbudowa platformy może odbywać się
za pomocą zmian przez UI, z doświadczenia
wiem, że około 70% potrzeb udaje się pokryć
w ten sposób. Jednak pozostałe 30% należy zazwyczaj doprogramować. W tym specjalizują się
i certyfikują zespoły JADE. Stawiającym pierwsze kroki w tej technologii z pomocą przychodzi
SDK (http://www.microsoft.com/download/en/details.aspx?id=12323).
W postrzeganiu i „pożądaniu” produktów
Microsoftu niemałe znaczenie ma – co oczywiste – otoczka marketingowa. SharePoint na-
Metodyka Agile i projekty SharePoint
leży do rodziny Office. Daje to na start wysoki
poziom integracji z tym popularnym pakietem
biurowym. Dodatkowo wersja podstawowa SharePoint, tzw. Foundation, jest darmowa (pobierz
i spróbuj swoich sił: http://www.microsoft.com/
download/en/details.aspx?id=5970).
Osobiście nie należę do grona zaślepionych fanów technologii Microsoft. W toku swojej pracy
zawodowej miałem okazję spotkać się z różnymi
środowiskami, natomiast ze względu na ukierunkowanie technologiczne w miejscu, gdzie
pracuję, skupiam się na produktach „MSa”.
Przełożyło się to na rzetelną wiedzę tak o możliwościach jak i ograniczeniach poszczególnych
produktów.
Zawsze należy pamiętać, jakie jest główne
przeznaczenie SharePoint – niekoniecznie będzie się nadawał jako oprogramowanie do szpitalnych urządzeń USG, jednak doskonale się
sprawdzi jako Portal Firmowy, na którym treści
będzie można publikować tak, by były widoczne zarówno w Intra jaki i Internecie. Ponadto jest
bardzo dobrym narzędziem usprawniającym
współpracę między poszczególnymi działami,
także rozproszonymi geograficznie.
Co ważne w odniesieniu do platformy SharePoint - od strony bardziej technicznej – przy jej
rozwijaniu o kolejne moduły trzeba sprawdzać
zalecane podejście, zgodne z architekturą. Jeśli
nie przemyślimy sprawy pojawić się mogą łzy
(a wiadomo, że łzy programisty deprymują najmocniej J). Jeśli jednak kod, moduł przygotowany jest zgodnie ze sztuką, wtedy szybko możemy
cieszyć się nową funkcjonalnością w aplikacji
skali enterprise.
Zatem…
Jak będzie wyglądała metodyka zwinna w projektach SharePointowych? Czy połączy ich uczucie,
pasja, dopasowanie? Gdzie siła tej potencjalnej pary? Gdzie problemy? Poniżej spróbuję podzielić
się swoimi doświadczeniami i przemyśleniami.
Miejmy najgorsze za sobą, czyli kiedy nie
warto brnąć w ten związek. Pogrzeb.
Bardzo dojrzałe organizacje, by zapanować
na wszystkimi procesami tak wewnątrz jak
i na zewnątrz, wdrażają u siebie szereg zasad
i procedur. Postrzegają siebie jako byty dobrze
zorganizowane i takich właśnie działań oczekują od dostawców oprogramowania. Metodyka
zwinna może wzbudzić u nich obawy i krytykę, dlatego osobiście odradzałbym lobbowanie
podejścia Agile u takich Klientów. Poślą wdrożeniowca na szafot, bez procesu.
Po drugie, im większy projekt, tym większy
budżet i tym mniej (a wręcz wcale nie ma) miejsca na niewiadome. Dla bardzo dużych projektów Agile w swojej spontaniczności po prostu się
nie sprawdzi. Trudno mi podać przykład firmy,
która zgodzi się by zrobić zwinnie projekt za
1mln złotych.
W metodyce zwinnej z założenia nie skupiamy się na tym co będzie za n-iteracji, myślimy
o tym co będzie w obecnej. Zatem jeżeli zakres
wymagań, które stawia przed nami Klient, jest
dość potężny, a poszczególne wymagania przeważnie mają między sobą różne zależności, to
rozsądek podpowiada, by jednak dobrze przemyśleć na starcie, cały zakres projektu. Porządna
analiza uchroni nas w późniejszym czasie przed
przepisywaniem zakończonych modułów. Ciągłe zmiany tych samych obszarów prowadzą,
oprócz większych kosztów, do irytacji członków
zespołu projektowego. Inny przypadek straszący tragedią to ten,
w którym SharePoint miałby integrować się
z innymi systemami, lub wykonywać skomplikowane obliczenia, np. finansowe. Niezwykle
istotnym produktem projektu jest wtedy specyfikacja i dokumentacja techniczna integracji, czy
obliczeń.
A przecież pamiętamy, że metodyka zwinna redukuje do minimum ilość „formalności”
i „papierów” - nie wyobrażam sobie systemu
wykonującego obliczenia finansowe, który nie
posiadałby sensowej specyfikacji opisującej reguły przeliczeń, procesy, kartoteki. Waga biznesowa takiego systemu jest tak duża, że będzie on
prędzej czy później rozwijany/zmieniany/poprawiany. Bez odpowiedniej dokumentacji wszelkie ingerencje będą szalenie niebezpieczne. Zaś
dla samych programistów praca na podstawie
miękkich ustaleń, w obszarze skomplikowanych
algorytmów, mapowań i transformacji, byłaby
bardzo… nieprzyjemna. Tak nie robimy J
Bywa, że metodyka zwinna, dla przykładu
Scrum, wymaga stosunkowo nietypowego podziału ról w zespole. Dla niektórych organizacji
(dostawców oprogramowania), dostosowanie
się do takich zasad, jest bolesne (zmiana organizacyjna dotknie wszystkich jednostek, jej wprowadzenie wymaga czasu i wysiłku, przy czym zawsze jakaś część pracowników obawia się zmian
jako takich). Metodyki zwinnej nie da się zacząć
stosować „z dnia na dzień”.
I żyli długo i szczęśliwie, czyli warto. Ślub.
Projekty realizowane kaskadowo (bardziej tradycyjnie) od tych realizowanych zwinnie różnią
się zasadniczo okresem zaręczyn.
W tym pierwszym ujęciu najważniejszy produkt pojawia się pod koniec, w trakcie testów
po stronie Klienta. Zatem odbiorca żyje niejako
w nieświadomości, jak będzie wyglądał system,
którego oczekuje – jego ukochana szykuje się na
wieży i zejdzie z niej dopiero przed sam ołtarz.
Natomiast w przypadku metody zwinnej odbiorca już po pierwszej iteracji wie, za co płaci
– narzeczeństwo jest aktywne i silnie kontaktowe - Klient co i rusz dostaje mały, ale funkcjonalny kawałek systemu.
Brzmi pięknie i zachęcająco, ale żeby dostarczyć pierwszy kawałek, musi powstać jakiś szkielet, silnik, baza – coś co będzie trwałym fundamentem wszystkich funkcjonalności. W tej relacji faktycznie świetnie sprawdza się SharePoint,
którego startowy kształt daje solidne podstawy
pod konkretne wymagania Klienta. Pozwala
nam to szybko wystartować z pierwszą iteracją,
gdyż dostosowanie platformy przed pierwszym
spotkaniem, to kilka dni pracy, czyli niewiele.
Kluczowym elementem na początku projektu będzie prezentacja filozofii platformy (poznajmy się). Korzystając z tego, że już na starcie
mamy „n” modułów z dużą wartością funkcjonalną, możemy zaznajomić Klienta z interfejsem oraz wyczuć jego poziom akceptacji architektury SharePoint jako takiej. Jest to tzw. spotkanie gap/fit.
Ważne, aby ukierunkować pracę i dalsze iteracje z Klientem na tor odnajdywania w platformie optymalnych sposobów na realizację potrzeb, zamiast na tor przebudowywania tego, co
jest już gotowe, np. wstążki (w SharePoint, jako
że jest częścią rodziny Office, mamy wstążkę),
nawigacji, formularzy, czy ułożenia przycisków.
Akceptacja platformy na starcie, przyzwyczajenie do typowego dla SharePoint UI, pozwoli
oszczędzić dużo budżetu i zapobiegnie nerwom
w późniejszych etapach projektu.
Dzięki temu programista w zespole zyskuje
komfort pracy - nie będzie musiał się zastanawiać czy i gdzie dodać przycisk, co się ma wydarzyć po jego naciśnięciu. Może i ma skupić się na
tym jakie kartoteki, i procesy należy dostarczyć,
by pokryć oczekiwaną funkcjonalność i właściwie oprogramować elementy wykraczające poza
startowe możliwości.
Metodykę zwinną dobrze stosuje się u Klientów, dla których prowadziliśmy już doradztwo
i wdrożenie, którzy ufają nam (na bazie dotychczasowej współpracy). Klient jest spokojny,
wie, że metodyka, w której budżet całkowity
jest nieprecyzyjnie określony, jest bezpieczna,
a nawet korzystniejsza, gdyż dzięki niej dostarczamy Mu dokładnie tego, czego potrzebuje,
a nie tego, co wydawało mu się potrzebne na
starcie projektu. Przekłada się to często na sytuację, w której zamiast planowanych (np.) dziewięciu iteracji, wystarczyło zrealizować sześć,
by po nich Klient stwierdził, że ma wszystko
23
czego potrzebuje. Dodatkowo zostaje mu trochę budżetu w kieszeni na kolejne inwestycje
(np. w system mobilny).
Pierwsze spotkanie z Klientem, to również
zebranie listy wszystkich istotnych wymagań,
które powinny zostać zrealizowane. Wymagania
zostają spriorytetyzowane, tak by mieć świadomość, na czym powinniśmy się skupić w najbliższej iteracji.
W przypadku SharePoint cała funkcjonalność
bazowa (logowanie, role, strony, formularze) są
gotowe. Zatem wybór istotnych tematów, będzie obejmował – bardzo zwinnie - konkretne
wymagania biznesowe.
Wybrane tematy, do pierwszej iteracji, możemy od razu „przeklikać” z Klientem. W trakcie spotkania bardzo małym nakładem pracy,
jesteśmy w stanie pokazać szkielet docelowej
funkcjonalności. Dla Klienta zobaczenie czegoś i rozmawianie na namacalnym kształcie o
dalszych szczegółach jest dużo łatwiejsze, niż
opowiadanie „co by było, jeśli…” bądź przesyłanie maili o abstrakcyjnych obiektach (pamiętajmy, że Klient nie musi mieć pojęcia o świecie systemów).
Przygotowana lista tematów na najbliższy
cykl trafia na do zespołu. Jest omawiana, wyceniana i z miejsca implementowana.
Tu również pomaga nam SharePoint, gdyż
tak jak w przypadku spotkania z Klientem.,
tak i dla zespołu można przekazywać wiedzę
w oparciu o „żywy organizm”. Np.:
Product Owner:
W witrynie dla Działu Marketingu [klik,
klik], musimy dodać następujące elementy:
• Lista pracowników działu
• Katalog filmów flash
• Formularz kontaktowy – z powiadomieniami email
• Wszyscy pracownicy działu mogą zarządzać zawartością, pozostali użytkownicy tylko przeglądają. Jak to widzicie?
Scrum Member:
Patrz, punkty 1, 3, 4 [klik, klik, klik] – mamy
z pudełka. Punkt 2gi [klik, klik] będzie oparty o bibliotekę dokumentów, ale będzie bardziej złożony. Widziałem na www.CodePlex.
com fajny i oczywiście darmowy webpart do
wyświetlania filmów flash w SharePoint. To co
trzeba zrobić, to dodać event reciver do biblioteki filmów, tak by przy każdym filmie pojawiło się ładne, klikalne łącze odtwórz. W ciągu
jednego dnia przygotuję instalkę tych funkcjonalności, czyli WSPka i wrzucę ją do Systemu.
Product Owner:
Super! Uwaga Klienta jest taka, że ten moduł
musi być widoczny po prawej stronie [klik, klik],
a ten …”
Oprócz tego, że mamy szybką wizualizację,
rozwiązania zarówno własne, jak i zewnętrzne
można przenosić z jednego SharePoint na drugi, da nam oszczędność pracy, co pozwoli nam
w ciągu jednej iteracji wziąć na warsztat więcej
potrzeb Klienta do obsłużenia. Przypomnę, że
24
w metodyce zwinnej nie mamy wielu dokumentów, zatem nasze ustalenia muszą mieć od razu
odzwierciedlenie w pracach na rzecz bieżącej
iteracji. Spotkania zespołu odbywają się codziennie, więc nie sposób zapomnieć czy pogubić się
w zadaniach.
Bardzo ważnymi momentami pracy nad rozwiązaniem w oparciu o SharePoint (w zasadzie
bez względu na metodykę), są
• faza definiowania architektury systemowej
pod wymagania. Platforma narzuca pewne
podejścia, które jeśli zostaną pominięte, najprawdopodobniej w przyszłości spowodują
szereg problemów z systemem
• faza decyzji odnośnie punktu, do którego
wystarczą dostosowania w UI (pamiętamy, że SharePoint pozwala w UI dostosować środowisko w bardzo szerokim zakresie), a od którego musi pojawić się deweloper by dostarczyć niestandardową funkcjonalność
W ramach iteracji oczywiście nie powinniśmy
zmieniać zakresu, czy ustaleń. Nie powinniśmy
– bo tak głosi metodyka. Gdy jednak nie uda nam
się uniknąć takiej sytuacji, ważne jest by na bieżąco informować Klienta o wpływie zmiany na
sprint.
Po skończonej iteracji prezentujemy funkcjonalny kawałek Systemu. Minęło niewiele
czasu, a już można coś zobaczyć – ma to bardzo pozytywny wydźwięk. Generalnie w metodykach zwinnych czas pędzi – my pędzimy
z nim – stąd nazwa sprint; dzisiaj coś ustalamy, jutro już możemy to z dumą pokazać
współpracownikom.
Jest „juice” jest „fun”. J
Oprócz projektów z zaprzyjaźnionymi
Klientami, czy projektów odkrywających
przed Klientem „Świat SharePoint” - dobrym
mariażem dla metodyki zwinnej, w zasadzie
bez względu na wielkość organizacji odbiorcy, czy dostawcy, będzie ten z projektami wewnętrznymi. Praktyka pokazuje, że tematy
wewnętrzne z reguły nie są profitowe, więc ich
priorytet automatycznie nie jest z byt wysoki.
To wymusza przyrostowy model liczby dostarczanych rozwiązań, czyli Agile.
A propos finansów: skoro iteracje trwają
od dwóch tygodni do miesiąca, pozwala to na
„zgrabne” ciągłe finansowanie prac w ramach
projektu. W sytuacji idealnej cały zakres projektu zostaje podzielony na zamówienia, czyli niezależne od siebie paczki wymagań – tak właśnie
pracujemy z jednym z naszych Klientów. Mamy
uzgodnioną częściową płatność gdy podejmujemy paczkę/zamówienie. Średnio jedno zamówienie wymaga dwóch iteracji i czas realizacji
przekłada się na miesiąc (maksymalnie dwa).
Oczywiście po Zamówieniu nr 1, następuje Zamówienie nr 2. Jaki mamy efekt? Klient jest zadowolony, bo szybko otrzymuje i wykorzystuje
narzędzie (agile), Zarząd dostawcy jest zadowolony, bo jest stały przychód gotówki, a Zespół?
Zadowolony i zmotywowany, bo widzi efekty
swojej ciężkiej pracy i uśmiech na twarzach Wyżej Wymienionych.
Właśnie. Dobrze wykonany SharePointowy
projekt zwinny powoduje, że „morale załogi”
skacze do góry. Takie nastroje zawsze należy brać
pod uwagę, jako argument za agile, podczas wyboru metodyki dla kolejnego projektu.
Podsumowanie,
czyli… mezalians???
Jestem przekonany, że bazując na doświadczeniu organizacji w której pracuję, dla każdego
projektu potrafiłbym dobrać właściwą metodykę, bez obawy że wyjdzie … mezalians J
Obecnie w firmie JADE, która jest większą
i uporządkowaną organizacją, akcent leży na
efektywności i jakości oraz porządku i spokoju pracy. Udaje nam się pozyskiwać coraz
większe projekty, co przekłada się na nasze
ukierunkowanie w stronę metodyk formalnych. Jednak nadal część wdrożeń, zwłaszcza
SharePointowych prowadzimy zwinnie, gdyż
jesteśmy świadomi nieprzeciętnych korzyści
z Agile zarówno dla Klienta, jak i dla nas, w
tym (jak już to wcześniej wspominałem) dla
naszych Zespołów.
Skąd wiemy czy działać zwinnie czy formalnie? Nie ma tutaj jednoznacznej odpowiedzi,
gdyż tak naprawdę powinniśmy stronić od
skrajnych wartościowań metodyk oraz poszukiwań ich jednoznacznych powiązań z technologią. Nic na siłę.
Nie zapominajmy też, że metodyki zawsze definiują sytuację idealną. Gdy Klient nie jest przekonany co do słuszności Agile, pójście w stronę
formalną nie musi być czymś gorszym.
A kiedy każda opcja jest równie dobra, zbadajmy nastroje ludzi.
Na koniec chciałbym polecić krótki, aczkolwiek bardzo ciekawy artykuł dotyczący wyboru
metodyk w ogóle: http://sveinminde.wordpress.
com/2012/02/23/agile-methods-do-not-fit-everysoftware-development-project/
… i zaprosić do wspólnych projektowych doświadczeń z JADE J
Janusz Falkiewicz
Analityk i Konsultant Biznesowy, JADE.
Od 5 lat związany jest z JADE, Złotym Partnerem Microsoft i laureatem Microsoft Special Award Partner
of the Year 2011.
Zarządzał projektami implementacyjnymi oraz pełni rolę analityka we wdrożeniach takich produktów, jak Microsoft Office SharePoint Server oraz
MS Dynamics CRM; odpowiada za definiowanie wymagań klienta, planowanie oraz organizację prac
projektowych, a także za komunikację pomiędzy
wszystkimi interesariuszami.
Jest doświadczonym analitykiem biznesowym, aktywnym członkiem w IIBA; posiada certyfikaty Microsoft Certified Proffesional m.in. w obszarze Portals & Collaboration: Microsoft SharePoint 2010.
Z wykształcenia informatyk, Absolwent Wydziału
Matematyki i Informatyki UMK w Toruniu.
Prywatnie pasjonat wielkich budowli, antropologii,
kosmologii.
Programowanie
w świecie nowych
technologii
Trzy podstawowe pytania
• Programiści – czy tworzą działające, zgodne z potrzebami klienta aplikacje, czy tylko produkują i kompilują kod źródłowy?
• Rozwój technologii – czy to tylko bardziej wypasiona elektronika oraz systemy operacyjne i języki programowania o coraz dziwaczniejszych nazwach, czy również zmiany metod, procesów, organizacji?
• Nowość – dla jednej osoby, dla danej firmy, czy autentyczna nowość?
Co to właściwie
jest „programowanie”?
Czy oznacza to tworzenie oprogramowania, a więc
złożony proces, obejmujący całą drogę od analizy
wymagań, poprzez projektowanie, pisanie kodu,
integrację, testowanie, wdrożenie i utrzymanie?
Czy też programowanie, to samo kodowanie:
pisanie kodu źródłowego, kompilowanie, ewentualnie analiza statyczna i testy jednostkowe
– czyli to, co zwykle wykonują osoby zwane
programistami?
Jeśli programowanie, to pisanie kodu źródłowego na podstawie względnie dokładnej specyfikacji, wtedy zależność programisty od zmian
technologii bywa mniejsza.
Wiemy jednak, że w praktyce, na dobre i złe,
programiści – chcąc nie chcąc – pełnią wiele
funkcji: zbierają wymagania, testują, wdrażają,
odpowiadają za utrzymanie. Tak dzieje się czasem z powodu niefrasobliwości kierownictwa,
które nie rozumie potrzeby istnienia innych
uczestników projektu poza skrzętnymi programistami. Czasem firma i projekt są po prostu
bardzo małe. Niekiedy taki stan rzeczy bywa
wynikiem świadomego wyboru metod zwinnych, „agile”. Wówczas programiści muszą dobrze rozumieć technologię, dla której tworzą
kod – jest to niewątpliwe wyzwanie!
Co to właściwie
jest „technologia”?
Słysząc słowo „technologia”, zwykle wyobrażamy sobie coś twardego: nową elektronikę, nowe procesory, nowe światłowody, nowe sposoby
produkcji tychże, i tak dalej. Jeśli nie elektronika, mechanika ani nie chemia, to ostatecznie nowe aplikacje: systemy operacyjne (np. zaroiło się
nam w ostatnich latach od pseudo-nowości w
formie plejady androidów, iOS-ów, blackberries’ów, symbianów!), nowe algorytmy, nowe języki
programowania. Słowa „technologia” i „technika”
są po polsku powszechnie stosowane zamiennie.
Tymczasem angielskie słowo „technology”
oznacza coś więcej: także procesy, procedury,
25
sposoby organizacji. Przy takim rozumieniu
technologii, wyzwaniem dla programisty byłyby
również zmiany procesu tworzenia oprogramowania, takie jak, na przykład, przejście od modelu kaskadowego do przyrostowego, wdrożenie
RUP, stosowanie formalnych metod modelowania wymagań. Tak, to często bywa dla programistów większym wyzwaniem, niż nowe techniki!
Co znaczy „nowe”?
W jakimś stopniu każde zadanie programisty jest
nowe – nie programuje się zwykle ponownie tego, co już działa, lecz realizuje funkcjonalność dotąd nie istniejącą.
Po drugie, nowość to pojęcie względne: coś
może być nowością dla danej osoby, na przykład
język C# dla kogoś znającego Java, albo programowanie aplikacji MacOS dla kogoś, kto wcześniej pracował pod Windows.
Technologia może być nowością w jednej firmie, czy branży, choć gdzie indziej istniała już
wcześniej.
Wreszcie, istnieją też prawdziwe nowości: technologie, które wcześniej nie istniały w ogóle.
Takie technologie są dla programistów największym wyzwaniem: czasem wymagają radykalnej
zmiany dawnego podejścia, brak podręczników,
brak narzędzi, jest większe ryzyko popełnienia
błędów.
Programowanie
dla nowych technologii
Nowe technologie biznesu
Większość zmian w oprogramowaniu bierze się
z nowych potrzeb biznesowych. To biznes przychodzi do programistów i prosi „zróbcie to a to,
najlepiej na wczoraj”. Stara funkcjonalność na nowych urządzeniach, na przykład mobilnych; nowa funkcjonalność ze starych elementów, na przykład możliwość zeskanowania kodu kreskowego
towaru telefonem i sprawdzenie, czy produkt jest
naprawdę markowy; wreszcie zupełnie nowa funkcjonalność – na przykład nowe usługi bankowe
albo ubezpieczeniowe, dostępne przez Internet.
Tak, realizacja takich nowych technologii biznesowych to główny cel, podstawowe zadanie
i największe wyzwanie dla programistów! Dziś
oprogramowanie nie jest, jak 30 lat temu, dodatkiem do działania firmy czy instytucji, lecz jej
motorem! Umiejętność IT, aby szybciej, skuteczniej i taniej niż konkurencja realizować w niezawodnym, łatwym do modyfikowania kodzie,
zmieniające się jak w kalejdoskopie potrzeby
biznesu, jest kluczem do sukcesu firmy, albo…
powodem jej klęski, jeśli IT zawiedzie.
Nowe technologie platformy
Pojawienie się nowego procesora, zmiany
w systemie operacyjnym, nowe usługi internetowe (Web services), nowy protokół komunikacyjny, nowy algorytm szyfrowania danych, nowe,
pojemniejsze dyski – czy to wyzwania dla programistów, czy też sprawy dla nich obojętne?
Bywa bardzo różnie! Nowe urządzenie jest
wielkim wyzwaniem dla osoby, która pisze
sterownik dla tego urządzenia, a sprawą często
najzupełniej obojętną dla kogoś, kto tworzy kod
wysokiego poziomu. Pod warunkiem…
… pod warunkiem, że oprogramowanie ma
dobrą strukturę, realizuje zasady hermetyzacji
(encapsulation), modularyzacji, i ma właściwie
zbudowaną hierarchię klas.
Niezależnie od tego, jakiego rodzaju zmiany w technologiach miały, mają i będą miały
miejsce, umiejętność radzenia sobie z nimi
przez programistów zależy od umiejętności stosowania przez nich dobrego stylu programowania, wyboru właściwych języków
i nieulegania pokusie stosowania brzydkich
sztuczek (kludge) w pisaniu kodu!
Programowanie
jakiego poziomu?
Różne zmiany technologiczne mają różny wpływ
na pracę programistów, zależnie od tego, ja jakim
Programowanie w świecie nowych technologii
poziomie ich programowanie się odbywa. Programista sterowników sprzętu musi rozumieć nową
technologię i dostosowywać swój kod do jej zmian
przy każdej technicznej nowości, natomiast jest
zwykle obojętny na nowe wyzwania biznesowe.
Programista aplikacji WWW być może nie dba
(pod warunkiem, wspomnianej w poprzednim
akapicie, poprawnie realizowanej hermetyzacji)
o zmiany technologii układów scalonych, dysków
i wyświetlaczy, ale za to musi stawić czoła modyfikacjom biznesu, który jego aplikacja realizuje!
Tak więc, podsumowując, rozwój różnych
technologii jest – lub nie – trudnym wyzwaniem dla programistów, zależnie od tego, na
jakim poziomie wirtualnej maszyny działają!
Programowanie przy pomocy
nowych technologii
Nowe języki programowania
Programista szukający pracy ma czasem wrażenie, że znajomość właściwego języka programowania jest podstawowym warunkiem powodzenia! Jeśli wśród wymagań wobec stanowiska,
o które programista się ubiega, napisano „znajomość ADA95 | APL | Assembler | AWK |
Bash | Basic | C | C# | C++ … Ruby | Smalltalk
… Xbase | XHTML”, to nie ma zmiłuj! Bez znajomości tego języka jest się bez szans.
Cóż, wynika to z krótkowzroczności pracodawców, lub wręcz rozpaczliwej ignorancji działów zajmujących się rekrutacją, nie zdających
sobie sprawy z tego, że nowego języka programowania można się doskonale nauczyć w ciągu
kilku dni, natomiast opanowanie najlepszych
praktyk i zasad inżynierii oprogramowania zajmuje o wiele dłużej! Kiepski programista znający „właściwy” język, będzie wydajniejszy od
dobrego programisty, który tego właśnie języka
nie zna… przez pierwszy tydzień, a potem role
się odwrócą!
Czyli z punktu widzenia interesów własnej
kariery, zalecałbym programistom sprostanie
wyzwaniu uczenia się najnowszych, najmodniejszych języków, albo – przeciwnie – opanowaniu jakiegoś archaicznego dialektu, który jest
i niemodny, i bardzo potrzebny… jak COBOL
w roku 1999!
Natomiast z punktu widzenia faktycznych
umiejętności zlecam raczej znajomość kilku języków, co wybitnie ułatwi – w razie potrzeby
– szybkie uczenie się kolejnych.
Nie zapominajmy, że języki programowania
są dla ludzi, nie dla maszyn – mikroprocesor
i tak dostaje do wykonania sekwencję instrukcji
napisanych w kodzie maszyny, a psychologiczne podstawy, na których opiera się gołosłowne
twierdzenia o wyższości jednych języków nad innymi, są zwykle bardzo wątłe. Nie ma się czym
ekscytować!
Nowe paradygmaty programowania
W przeciwieństwie do poszczególnych języków,
ważna jest natomiast znajomość różnych paradygmatów, sposobów podejścia do programowania.
O ile przejście między C++, C# i Java nie powinno nastręczać żadnych trudności, o tyle zmiana
paradygmatu z asemblera na język strukturalny,
z języka strukturalnego na obiektowy, a z każdego
z nich – na rekurencyjny, jak Lisp czy Prolog, to
już większe wyzwanie. OK – takim wyzwaniom
programiści muszą sprostać, tak jak leśniczy nie
powinien błądzić w lesie, i nic ponadto. Zresztą,
nie wydaje się, aby należało się spodziewać czegoś
nowego w tej dziedzinie w najbliższej przyszłości.
Niekiedy, nowa technologia produktu programistycznego pociąga za sobą nowy paradygmat. Na przykład rozszerzająca się technologia
tworzenia usług internetowych, wykorzystująca
architekturę SOA, pociąga za sobą pewne nowe
sposoby programowania, niezależnie od używanego języka.
Czy nowe metody to też nowe
technologie?
To wprawdzie sprawa do teoretycznej dyskusji
(patrz wcześniejszy akapit: Co to właściwie jest
„technologia”?), ale nie ulega wątpliwości, że nowości czysto techniczne są dla programistów
w praktyce o wiele mniejszymi wyzwaniami, niż
stosowanie nowych metod wytwarzania oprogramowania. Dlatego pominięcie tego tematu oznaczałoby zamykanie oczu na to, co najistotniejsze!
Temu wyzwaniu programiści stawiają czoła, ze zmiennym powodzeniem, od ponad 60
lat. Kiedyś programowanie było zajęciem dla
samotnych geniuszy, często lauretaów Nobla
z fizyki1. Potem stało się zadaniem zespołowym,
trochę z pogranicza sztuki, trochę rzemiosła,
stopniowo – manufaktury. Rosnąca złożoność
przedsięwzięć informatycznych oraz ich efektowne niekiedy niepowodzenia spowodowały,
że usiłowano je uporządkować, zbiurokratyzować, uczynić bardziej przewidywalnymi. Z pra-oceanu pra-programowania wyłoniły się nowe,
nieznane wcześniej dyscypliny: analiza biznesowa, inżynieria oprogramowania, zarządzanie
konfiguracją, zapewnienie jakości, testowanie,
utrzymanie. Potem nadeszła kontr-rewolucja
„agile”, próba powrotu do pre-biurokratycznych
korzeni. Każda z tych zmian wywierała ogromny wpływ na treść i kształt pracy programistów,
każdorazowo wyzwaniem było poradzenie sobie w nowej rzeczywistości.
Programowanie,
kiedy świat się zmienia
Rozwój technologii oznacza zmiany. Jakim wyzwaniem są dla programistów zmiany?
Jak radzić sobie ze zmiennością
Na pierwszy rzut oka, zmiany, także te wynikające z rozwoju technologii, nie są dla programistów
ani większym, ani mniejszym wyzwaniem, niż
dla każdego innego. Zmiany powodują obawy,
poczucie zagrożenia, uaktywniają syndromy „tak
robiliśmy zawsze” oraz „lepiej nie próbować naprawić tego, co nie jest zepsute”. Jednak, zmiany w IT mają też swoją specyfikę, która odróżnia
je od zmian w, dajmy na to, hutnictwie, a upodabnia do zmian mody – są niezwykle szybkie
i nagłe.
Zmiany oprogramowania, wynikające ze
zmiany technologii, łatwo mogą doprowadzić
do chaosu, którego bezwinnymi (czasem, współwinnymi…) ofiarami często stają się programiści
i testerzy. Jeśli nie ma dobrze działającego procesu zarządzania zmianami wymagań, programiści
o zmianach dowiadują się często chaotycznie
i na ostatnią chwilę. Jeśli nie ma dobrego projektu, zmiany wdrażane przez programistów mogą
być niespójne. Jeśli nie dokonuje się analizy
wpływu (impact analysis), to zdarza się, że realizacja żądanej zmiany wymaga znacznie więcej
czasu, niż przewidywano. Tę litanię można by
ciągnąć jeszcze długo.
Łatwość modyfikacji
Rozwój technologii IT zwykle nie odbywa się skokowo, kwantowym skokiem, lecz drogą stopniowych, niewielkich zmian. Tak więc wyzwanie dla
programistów nie oznacza zwykle, że wyrzuca się
komplet starego oprogramowania i wszystko pisze zupełnie od nowa, lecz że dokonuje się modyfikacji już istniejących aplikacji i systemów. Dlatego łatwość, na ile oprogramowanie poddaje się
zmianom, tak zwana łatwość utrzymania (maintainability) decyduje, na ile rozwojowi technologii
towarzyszy nieustanna trauma, a na ile może się
on odbywać bezboleśnie, płynnie.
Niestety, przy projektowaniu systemów i podczas ich realizacji w projektach, ta właściwość
pada zbyt często ofiarą krótkowzroczności, chęci osiągnięcia pozornego sukcesu w bieżącym
projekcie kosztem… przyszłych pokoleń, jak
deficyt budżetowy państwa! W końcu szybciej
jest – zacytuję Adama Kolawę2, polskiego programistę-miliardera – przyspawać zapasowe
koło do osi, niż… mozolnie przykręcać pięć śrub!
Zaś kierownik projektu zostanie pochwalony
za zakończenie projektu w terminie - nikt nie
widzi, że osiągnięce kosztem jakości i łatwości
utrzymania. I tak oszczędność wynikająca ze
zwykłego niechlujstwa, wynosząca, dajmy na to,
100 K, powoduje wzrost kosztów testowania,
wdrożenia i napraw w ostatniej chwili o 1000 K,
zaś rozłożone na lata koszty utrzymania mogłyby być może i o 100.000 K mniejsze.
Nie magiczne języki programowania, nie mistyczne – zwinne, ekstremalne – metodyki,
nie betonowe normy typu PRINCE-2, ITIL czy
COBIT, lecz wyłącznie dobry proces inżynierii oprogramowania, dobre praktyki zapewniają, że programiści będą sobie radzic
z wyzwaniami płynącymi z rozwoju technologii bez potrzeby wylewania hektolitrów
potu i łez!
Bogdan Bereza,
[email protected], sqa.victo.eu
1
Artykuł na ten temat: „Przyszłość IT tworzą
geniusze” na victo.eu/PL/Wiedza.
2
Adam Kolawa „Skokowy wzrost wydajności”,
CeDeWu 2010, oraz www.nextleapinproductivity.com
26
Informacje prasowe
Xerox liderem
rynku urządzeń
wielofunkcyjnych
według raportu IDC
Warszawa, 8 października 2012 r. Według tegorocznego raportu IDC1, Xerox zajmuje pozycję lidera rynku sieciowych urządzeń wielofunkcyjnych dla biur różnej
wielkości. Eksperci wyróżnili szeroką i jedną z najbardziej kompleksowych w branży
ofert produktów z obszaru MFP. Analitycy docenili Xerox również za działania w obszarze rozwoju i promocji usług i rozwiązań z zakresu zarządzania dokumentami,
które są istotne z punktu widzenia realizacji celów biznesowych przedsiębiorstwa.
A
utorzy raportu „IDC MarketScape:
U.S., Networked Multifunction Peripherals for the Distributed Office
2012 Vendor Analysis” przeanalizowali oferty
dostawców MFP pod kątem konkurencyjności
i dopasowania do zmieniających się potrzeb
amerykańskiego rynku i klientów. Eksperci za
jeden z największych wyróżników firmy Xerox uznali szerokie portfolio produktów do
biur, zarówno kolorowych, jak i monochromatycznych drukarek i urządzeń wielofunkcyjnych, a także usług z obszaru zarządzania
drukiem.
„Xerox posiada szereg atutów potrzebnych
do zbudowania mocnej pozycji firmy na rynku urządzeń wielofunkcyjnych”, podsumowuje Keith Kmetz, vice president, Hardcopy
Peripherals Solutions and Services, IDC. „Sukces Xerox oznacza również, że klienci szukają
wartości dodanej i wybierają takich dostawców, którzy oprócz produktów dobrej jakości
potrafią dopasować strategię cenową do wymagań odbiorcy oraz zaproponować korzystny
model usługowy”, dodaje.
Xerox od wielu lat stawia na innowacyjność swoich produktów i usług, co sprzyja
zachowaniu równowagi pomiędzy tradycyjnymi a cyfrowymi rozwiązaniami. Narzędzia
opracowywane przez ekspertów firmy pomagają filtrować dane, szybko uzyskiwać najważniejsze informacje oraz upraszczać codzienne procedury i czynności. Przykładowo,
platforma Xerox Extensible Interface Platform® pozwala firmom na tworzenie opro-
28
gramowania, które umożliwia wykonywanie
skomplikowanych zadań z poziomu dotykowego ekranu urządzeń wielofunkcyjnych.
Informacje o Xerox
Xerox Corporation to spółka o wartości prawie
23 mld $, będąca światowym liderem w dziedzinie zarządzania procesami biznesowymi i
dokumentami. Firma, z siedzibą w Norwalk
w amerykańskim stanie Connecticut, dostarcza najnowocześniejsze rozwiązania technologiczne w zakresie dokumentów, usług, oprogramowania i materiałów eksploatacyjnych dla
produkcji i biur każdej wielkości. Dzięki ACS,
A Xerox Company, spółce przejętej przez Xerox w lutym 2010 roku, Xerox oferuje także
usługi outsourcingu procesów biznesowych
i usługi informatyczne, takie jak przetwarzanie danych, outsourcing procesów HR, pomoc finansowa i usługi zarządzania relacjami
z klientami, zarówno dla biznesu jak i sektora
publicznego na całym świecie. 140.000 pracowników Xerox obsługuje klientów w ponad
160 krajach.
Więcej informacji do zdobycia na stronach:
http://www.xerox.com, http://news.xerox.com,
http://www.realbusiness.com. Informacje z zakresu relacji inwestorskich są dostępne na stronie: http://www.xerox.com/investor.
konkretnym rynku. Badanie wykorzystuje metodologię bazującą na kryteriach jakościowych
i ilościowych. Jest prostą, graficzną ilustracją pozycji każdego dostawcy na rynku. IDC
MarketSpace zapewnia bazę porównawczą dla
produktów i usług, możliwości, strategii oraz
czynników obecnego i przyszłego sukcesu dostawców rozwiązań ICT. Badanie zapewnia
klientom możliwość oceny mocnych i słabych
punktów dostawców w różnych obszarach
i pod każdym kątem.
Kontakt dla mediów:
Aleksandra Żarkowska, Xerox Polska Sp. z o.o., +48 22 878 78 04, GSM +48 608 61 64 61,
[email protected]
Anna Podolak, Linkleaders Sp. z o.o., GSM +48
502 220 557, [email protected]
Uwaga:
Aby subskrybować kanały RSS firmy Xerox,
wejdź na stronę http://news.xerox.com/pr/xerox/
rss.aspx. Aby dodać swój komentarz lub sugestię, dowiedzieć się więcej o branży i ostatnich
wydarzeniach, wejdź na stronę: http://twitter.
com/xeroxcorp, http://realbusinessatxerox.blogs.
xerox.com, http://www.facebook.com/XeroxCorp,
http://www.youtube.com/XeroxCorp.
O IDC MarketScape
Analiza MarketScape została zaprojektowana
w celu zdobycia informacji na temat dostawców usług IT/telekomunikacyjnych (ICT) na
XEROX® i XEROX and Design® to znaki towarowe należące do Xerox Corporation
w USA i/lub innych krajach.
Szkolenia, certyfikacja, warsztaty, doradztwo
Inżynieria oprogramowania
Zarządzanie konfiguracją (wg iNTCCM)
Metodyki zwinne (agile)
Podstawy zapewnienia jakości
Zarządzanie ryzykiem (wg T. DeMarco)
Certyfikaty IT
Skuteczny dział IT (wg A. Kolawy)
Udoskonalanie procesów IT
Testowanie
Certified Associate in Software Testing
QAI
Certified Software Tester
Certified Manager of Software Testing
wg ISTQB
Podstawy testowania (CTFL)
Zaawansowany – analityk (CTAL TA)
Zaawansowany – kierownik (CTAL TM)
Zaawansowany – techniczny (CTAL TTA)
Ekspert – Improving the Testing Process
Ekspert – Test Manager
Automatyzacja testowania
Projektowanie przypadków testowych
Zarządzanie testowaniem
Testowanie aplikacji mobilnych
CAT – Certified Agile Tester
Skuteczne inspekcje i przeglądy
Inżynieria wymagań
IREB
wg REQB
Podstawy inżynierii wymagań
Pozyskiwanie i konsolidacja wymagań
Poziom podstawowy
Poziom zaawansowany
szkolenia.victo.eu
[email protected]
507 545 747

SDJ - Listopad 2012 ebook

Transkrypt

Podobne dokumenty