Your SlideShare is downloading. ×
Jak przejąć i rozwijać projekt?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Jak przejąć i rozwijać projekt?

746
views

Published on

Przejęcie, migracja, aktualizacja projektu IT

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
746
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. 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. 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. Materiały do pobrania: http://goo.gl/Moln9o Dziękuję za uwagę! W razie pytań? Piotr Karwatka – pkarwatka@divante.pl
  • 10. Materiały do pobrania: http://goo.gl/Moln9o Dziękuję za uwagę! W razie pytań? Piotr Karwatka – pkarwatka@divante.pl

×