Your SlideShare is downloading. ×
0
Materiały do pobrania: http://goo.gl/Moln9o

Jak przejąć i dalej rozwijać projekt?

Przejęcie dalszego rozwoju projektu IT...
Materiały do pobrania: http://goo.gl/Moln9o

Kiedy przejmujemy projekt?
Przejęcie rozwoju projektu może następować z różny...
Materiały do pobrania: http://goo.gl/Moln9o

Co sprawdzić w ramach audytu?
Minimalny rozsądny zakres prac:
-Analiza logów ...
Materiały do pobrania: http://goo.gl/Moln9o

Dokumentacja i szkolenia
•

Dokumentacja nie musi być szczególnie długa. Jeśl...
Materiały do pobrania: http://goo.gl/Moln9o

Wywiad i poznanie systemu
Przejmując rozwiązanie informatyczne, warto porozma...
Materiały do pobrania: http://goo.gl/Moln9o

Czy kod jest dobry?
•
•
•
•

•

Czy jest używana spójna konwencja kodowania? ...
Materiały do pobrania: http://goo.gl/Moln9o

Zespół do zadań specjalnych
Rozwojem nieznanego systemu powinien zajmować się...
Materiały do pobrania: http://goo.gl/Moln9o

System kontroli wersji i śledzenie zmian
Zmiany, które będziemy wprowadzać, s...
Materiały do pobrania: http://goo.gl/Moln9o

Dziękuję za uwagę!

W razie pytań?
Piotr Karwatka – pkarwatka@divante.pl
Materiały do pobrania: http://goo.gl/Moln9o

Dziękuję za uwagę!

W razie pytań?
Piotr Karwatka – pkarwatka@divante.pl
Upcoming SlideShare
Loading in...5
×

Jak przejąć i rozwijać projekt?

778

Published on

Przejęcie, migracja, aktualizacja projektu IT

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
778
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Jak przejąć i rozwijać projekt?"

  1. 1. Materiały do pobrania: http://goo.gl/Moln9o Jak przejąć i dalej rozwijać projekt? Przejęcie dalszego rozwoju projektu IT zawsze budzi emocje. Pierwsza myśl to zazwyczaj „przepiszmy to od nowa”. Piotr Karwatka, Grupa Divante
  2. 2. Materiały do pobrania: http://goo.gl/Moln9o Kiedy przejmujemy projekt? Przejęcie rozwoju projektu może następować z różnych przyczyn – wcale nie negatywnych. Najczęściej: -w projekcie jest tyle zmian i potrzeby rozwoju są tak duże, że zewn. firma nie jest opłacalna, -projekt jest dla nas strategicznie kluczowy i zależy nam na bezpieczeństwie technologii, -wykonawca upada / kończy z daną technologią, -problemy wydajnościowe, bezpieczeństwa, -podejrzenie niezgodności ze sztuką (kiepski kod) -wykonawca nie może zakończyć wdrożenia. Najlepiej: -zacząć od poproszenia o dokumentację -następnie wykonać krótki
  3. 3. Materiały do pobrania: http://goo.gl/Moln9o Co sprawdzić w ramach audytu? Minimalny rozsądny zakres prac: -Analiza logów serwera i logów systemu pod kątem występowania błędów. Pobieżna diagnoza czym błędy są spowodowane -Przegląd kodów źródłowych i ocena ich czytelności, komentarzy, dokumentacji i dobrych praktyk -Testy wydajnościowe narzędziem Siege, AB -Testy bezpieczeństwa narzędziami automatycznymi. Następujące podatności będą sprawdzone: XSS, SQL Injection, CSRF -Sporządzenie krótkiego opisu/raportu. Ocena, wnioski, sugerowane rozwiązania – 8 godzin roboczych Jaka dokumentacja? -dokumentacja kodu, -dokumentacja instalacji, -projekt funkcjonalny.
  4. 4. Materiały do pobrania: http://goo.gl/Moln9o Dokumentacja i szkolenia • Dokumentacja nie musi być szczególnie długa. Jeśli na etapie analitycznym (przedwdrożeniowym) była tworzona dokumentacja funkcjonalna, to jest już ona zalążkiem, wokół którego można zbudować dokumentację techniczną. •opis architektury aplikacji — opis podziału na moduły, przeznaczenie modułów, ew. zależności; •opis działania algorytmów, które nie są trywialne — np. mechanizmy wyliczania cen (powinny być one dokładnie opisane), •opis procedury instalacji i uruchomienia systemu — także opis, co i kiedy powinno być „czyszczone” w bazie danych •opis najważniejszych klas i warstw aplikacji — typowo programistyczny opis pozwalający szybciej znaleźć miejsce w kodzie, •opis struktury bazy danych — przy skomplikowanych relacyjnych bazach oprócz opisu tabel konieczne jest opisanie zależności (relacji). •opis radzenia sobie w sytuacjach problematycznych (Troubleshooting) — jeśli istnieją typowe sytuacje awaryjne i istnieją procedury na ich okoliczność, to dokumentacja powinna koniecznie zawierać ich szczegółowy opis; •opis innych czynności, które muszą być wykonywane, aby aplikacja działała.
  5. 5. Materiały do pobrania: http://goo.gl/Moln9o Wywiad i poznanie systemu Przejmując rozwiązanie informatyczne, warto porozmawiać z użytkownikami/właścicielami o tym, co sprawia w systemie największe problemy. Musimy wiedzieć, czy nie ryzykujemy zbyt wiele, podejmując się samodzielnego rozwoju. Uruchomienie i podstawowe czynności Podstawowe czynności związane z utrzymaniem aplikacji muszą zostać opanowane natychmiast. Uruchomienie, tworzenie kopii zapasowych, tworzenie kopii bazy danych oraz czynności związane z usuwaniem logów — to podstawa. Bez umiejętności realizacji tych zadań aplikacja może ulec awarii lub po prostu przestać działać. Analiza kodu źródłowego Niezależnie od tego, czy posiadamy dokumentację, czy nie, analiza kodu źródłowego pewnie prędzej czy później będzie konieczna. Jeśli kod jest napisany zgodnie ze standardami i używa wzorców projektowych, to pół biedy. Gorzej, jeśli kod, który otrzymaliśmy, to spaghetti kodu aplikacji, kodu widoków (znaczniki HTML i skrypty), a może nawet danych konfiguracyjnych. Taką metodą można rozpoznać każdą aplikację. Czasami jest to jednak dość czasochłonne. Ważne, aby spisywać wnioski z analizy kodu, tworząc dokumentację.
  6. 6. Materiały do pobrania: http://goo.gl/Moln9o Czy kod jest dobry? • • • • • Czy jest używana spójna konwencja kodowania? Czy nazwy klas, funkcji, metod i zmiennych są nazywane wg tego samego wzoru? W tym samym języku? Czy nazwy tłumaczą się same, czy może używane są jakieś magiczne stałe i dziwne skróty? Czy używane są wzorce projektowe? Czy przyspieszają komunikację (tzn. czy występowanie danego wzorca samo tłumaczy działanie i strukturę fragmentu aplikacji)? Czy aplikacja korzysta ze sprawdzonych frameworków i bibliotek? Ich występowanie znacząco ułatwia rozwój. Znane frameworki nie tylko zwiększają stabilne działanie systemu, ale sprawiają, że nowi programiści będą mogli łatwiej wdrożyć się do pracy. Czy w kodzie są komentarze do metod i klas opisujące ich przeznaczenie, działanie algorytmu oraz typy parametrów? Ma to szczególne znaczenie przy językach skryptowych (bez ścisłej typizacji). W takich językach bez odpowiedniego komentarza funkcje mogą być używane nieprawidłowo. Czy istnieje pokrycie kodem testów jednostkowych? Takie testy świadczą o dużej staranności wykonania i są podstawą do wprowadzania dalszych zmian (dzięki nim błyskawicznie wykryjemy problemy).
  7. 7. Materiały do pobrania: http://goo.gl/Moln9o Zespół do zadań specjalnych Rozwojem nieznanego systemu powinien zajmować się zespół do zadań specjalnych. Działa on jak jednostka antyterrorystyczna. Szybko wkracza do akcji i opanowuje sytuację. Musimy mieć na uwadze, że pierwsze zadania związane z nowym projektem z dużym prawdopodobieństwem będą dotyczyły zgłoszeń błędów i konieczności wprowadzania poprawek. Najbardziej doświadczeni programiści szybko odnajdą się w nowej sytuacji, najszybciej z całego zespołu znajdą przyczyny i mogą zaproponować rozwiązanie błędów. To z nich powinna się składać nasza jednostka szybkiego reagowania. Testy jednostkowe Korzystając z testów jednostkowych, możemy pracować w trybie: działa – nie działa – -poprawiam – -działa, ale tylko wtedy, jeśli wiemy, jakie dokładnie są skutki wprowadzonych zmian. Jeśli jednak nie znamy dokładnie systemu, wprowadzane przez nas modyfikacje mogą powodować reperkusje w częściach aplikacji, które nie są z nimi logicznie powiązane.
  8. 8. Materiały do pobrania: http://goo.gl/Moln9o System kontroli wersji i śledzenie zmian Zmiany, które będziemy wprowadzać, siłą rzeczy są obarczone sporym ryzykiem. Powinny być wersjonowane w osobnych branchach, co pozwoli na ich szybkie wycofywanie i publikowanie transakcyjne. Zmiany powinny być wprowadzane możliwie w małych ilościach, związanych z pojedynczymi zadaniami i fragmentami kodu. Dzięki takiemu podziałowi znacząco ułatwimy testy oraz zmniejszymy ilość zależnych modułów, które mogłyby ulec awarii w przypadku wystąpienia błędów. Dziennik (log) projektu i dokumentacja Log projektu to ważne narzędzie i warto je stosować wszędzie tam, gdzie rozwijamy oprogramowanie. Log jest wygodną formą dokumentowania prac. Zapisujemy w nim ważne obserwacje dotyczące kodu i przede wszystkim sposoby obejścia problemów, jakie pojawiły się w czasie prac. Nowe osoby nie będą musiały odkrywać koła na nowo, mogąc po prostu spojrzeć do loga. Ciężko przecenić wkład w rozwój wiedzy o projekcie, jaki niesie za sobą nawyk bieżącego dokumentowania najważniejszych zmian.
  9. 9. Materiały do pobrania: http://goo.gl/Moln9o Dziękuję za uwagę! W razie pytań? Piotr Karwatka – pkarwatka@divante.pl
  10. 10. Materiały do pobrania: http://goo.gl/Moln9o Dziękuję za uwagę! W razie pytań? Piotr Karwatka – pkarwatka@divante.pl
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×