Zadania wykonawcze rozwoju

Zadanie rozwoju jest mała ilość prac rozwojowych, które wynika z wymogiem.Realizacji zadania rozwoju polega na dodaniu odpowiednich nowych funkcji związanych z oprogramowaniem.Po zakończeniu pracy zadania rozwoju, powinno się jednostki przetestowane, przeglądowi, kod, analizowane i włączone do istniejącego kodu podstawowej.

W tym temacie

Oszacowanie

Dokumentów projektów

Ocena projektu

Testy jednostkowe

Analizy kodu

Proces przeglądania kodu

(Diagnostyka)

Integrowanie zmian

Oszacowanie

Oszacowaniu kosztu rozwoju zadań pomaga kontrolować zakres funkcji i harmonogram prac rozwojowych.Szacowanie kosztów dla wszystkich zadań rozwoju powinna być sporządzona i wszelkie problemy powinny zostać rozwiązane przed iteracji planowania spotkania.Jeśli całkowity koszt zadania programowania jest więcej niż można wykonać w iteracji, zadania być odroczone lub ponownie przydzielone.Po rozwoju zadania zostanie wybrana, jest odpowiedzialny za autora do kosztów zadania.

Utwórz element pracy zadania dla każdego zadania rozwoju, która została wybrana i połączyć go z wymogu, z którego został utworzony.Można to zrobić na karcie implementacji dla zadania ani elementu pracy zapotrzebowania.Podstawy oszacowania na czas, który był wymagany, aby wykonywać podobne zadania i należy upewnić się, że współczynnik kosztów pisania testów jednostkowych.Dla każdego zadania wprowadzaniu oszacowania Oszacowanie oryginalnego elementu pracy zadania.

Formularz dla zadania działać elementy przechowuje dane w polach i kart, które są na poniższych ilustracjach pokazano:

Po zadania zostały utworzone i oszacowane, umożliwia wyświetlanie podziału wymagań i zadań kwerendy podziału pracy.Aby uzyskać więcej informacji, zobacz Kwerendy udostępnione (CMMI).

Dokumentów projektów

Dokumenty projektu powinny obejmować wystarczająco dużo informacji do opisu do dewelopera jak napisać kod w celu zaimplementowania wymóg w produkcie.

Dokumenty projektu mogą być to zbiór specyfikacji, wymóg elementów pracy i inne dokumenty, w zależności od procesu zespołu.

Należy rozważyć użycie wzorach projektowych, projektowanie zorientowane obiektowo, modelach strukturalnych, języków modelowania, modele relacji encji i innych technik w wytycznych dla projektu, który jest określony dla zespołu.To jest również udokumentowanie racjonalne uzasadnienie kluczowe decyzje, które zostały wprowadzone.Na przykład jeśli istnieje znaczny wpływ na koszt, harmonogram lub parametrów technicznych, udokumentować przyczynę decyzje za te efekty, a dołączyć tę informację w projekcie.

Po utworzeniu dokumentów niezbędnych projektów należy przechowywać je gdzie członkowie zespołu mogą dzielić się nimi.Aby uzyskać więcej informacji, zobacz Zarządzanie dokumentami i bibliotekami dokumentów.

Ocena projektu

Ocena projektu służy do zapewnienia, że nowy lub poprawiony projekt jest technicznie dokładne, kompletne, sprawdzalne i wysokiej jakości i który implementuje wymóg poprawnie.Audyty projektu są kluczy metodą zagwarantowania jakości wcześnie poprzez zidentyfikowanie problemów, zanim pojawią się w kodzie.Audyty projektu udostępniają dodatkowe wiedzę na temat projektu z innymi programistami.

Deweloper, który jest odpowiedzialny za tworzenie projektu należy organizować ocena projektu, identyfikowanie recenzentów, recenzji planowania i dystrybucji projekt do wszystkich recenzentów.

Wszelkie zainteresowanych stron, które są uczestniczą lub wpłynąć projektu powinny uczestniczyć w przeglądzie.Zazwyczaj to obejmować menedżera projektu, główny programista i tester dla obszaru projektu.Wszyscy deweloperzy, którzy znajdują się na ten sam zespół, ale również autora, którego kod jest redagowany uczestniczyć w przeglądzie.

Zaplanować spotkanie przeglądowe i rozpowszechniania dokumentów projektów już wystarczająco, aby dać wystarczająco dużo czasu każdego recenzenta je przeczytać.Plan długość spotkania przeglądowego odpowiadają jak wiele szczegółów technicznych należy dokonać przeglądu.

Weryfikacja jakości

Upewnij się, że projekt jest sprawdzalne.Czy budować kod, który nie może zostać zweryfikowane lub potwierdzone w rozsądny sposób?W takim przypadku nie jest możliwe zapewnienie jakości kodu, a projekt musi być ponownie obrobione.Bada on dokumenty projektu występują problemy, które doprowadzą do błędów kodu.Poszukaj opisów nieprawidłowy interfejs, błędów projektu lub błąd nazewnictwa.Porównaj dokumenty projektu w zamian za istniejących kryteriów, takich jak standardy interfejsów operatora, norm bezpieczeństwa, ograniczenia produkcji, tolerancją wykonawczą lub części normy.Utwórz błąd pozycje robocze, które opisują wszelkich wad, które znajdują się w dokumentacji projektowej i przypisać je do odpowiedzialnego autora.

Tworzenie elementu pracy recenzji dla projektu

Element pracy recenzji jest tworzony do dokumentowania wyniki przeglądu projektu.Zespół kontroli należy zdecydować, aby kolejne kroki dotyczące projektowania, które zależą od wielkości koniecznych zmian.Jeśli żadne zmiany nie są niezbędne, ustaw stan elementu pracy na zamknięte, ustaw powód akceptowana (jak jest) i należy zauważyć, że kodowania mogą uruchamiać na projekt.Jeśli konieczne jest wprowadzenie drobnych zmian, ustaw stan elementu pracy na rozwiązany i ustawić powód na zaakceptowana z niewielkimi zmianami.Oznacza to, czy kodowanie mogą być uruchamiane po zaimplementowaniu niewielkie zmiany w projekcie.Jeśli konieczne są duże zmiany, ustaw stan elementu pracy na rozwiązany i ustawić powód na zaakceptowana z najważniejsze zmiany.Projekt musi być ponownie obrobione i innym ocena projektu muszą być przeprowadzane przed rozpoczęciem kodowania na projekt.

Testy jednostkowe

Testy weryfikacji wdrażania poprawny kod jednostki.Pisania i wykonywania testów jednostkowych identyfikuje błędy przed testowania zaczyna się i, w związku z tym, przyczynia się do zmniejszenia kosztów kontroli jakości.Programiści muszą pisać testy jednostkowe dla całego kodu, który zostanie zapisany w ramach realizacji zadania rozwoju lub naprawiania błędu.Aby uzyskać więcej informacji, zobacz Sprawdzanie kodu za pomocą jednostki badań.

Analizy kodu

Analizy kodu sprawdza, czy kod ze zbiorem reguł, które pomagającego wymusić wskazówki przeznaczone dla deweloperów.Celem analizy kodu jest nie mają kodu analizy naruszenia lub ostrzeżenia.Analizy kodu można sprawdzić czy kod nie więcej niż 200 potencjalnych problemach w konwencji nazewnictwa, projekt biblioteki, lokalizacja, bezpieczeństwa i wydajności.

Jeśli zaczniesz uruchomienie analizy kodu we wczesnej fazie rozwoju cyklu, można zminimalizować naruszenia i ostrzeżenia na bieżąco.

Jednakże jeżeli uruchamiasz analizy kodu na istniejący kod, który nie została sprawdzona przed mogą mieć wiele naruszeń reguł.Jeśli tak jest, można utworzyć zestaw linii bazowej regulaminu krytycznych, że kod musi przekazać, a następnie rozwiń węzeł zestawu, jak bardziej krytyczne problemy nie są rozwiązane reguł.W ten sposób zespół może Przechodzenie do przodu na nową funkcjonalność lepszą jego istniejącego kodu podstawowej.

Aby uzyskać więcej informacji, zobacz Analizowanie jakości aplikacji za pomocą narzędzia do analizy kodu i Poprawy jakości kodu z zespołu projektu Check-in Policies.

Proces przeglądania kodu

Główny programista powinien zorganizować audyt kodu identyfikacji recenzentów, planowanie audyt kodu i wysyłając kod do recenzji do wszystkich recenzentów.Aby przygotować się do przeglądu kodu, należy podjąć następujące kroki:

1. Tworzenie elementu pracy recenzji śledzenie decyzji, które są wykonane w przeglądzie.Jeśli żadne zmiany nie są niezbędne, ustaw stan elementu pracy na zamknięte, ustaw powód akceptowana (jak jest) i należy zauważyć, że kodowania mogą uruchamiać na projekt.Jeśli konieczne jest wprowadzenie drobnych zmian, ustaw stan elementu pracy na rozwiązany i ustawić powód na zaakceptowana z niewielkimi zmianami, która wskazuje, czy kodowanie mogą być uruchamiane po zaimplementowaniu niewielkie zmiany.Jeśli konieczne są duże zmiany, ustaw stan elementu pracy na rozwiązany i ustawić powód na zaakceptowana z najważniejsze zmiany.Projekt musi być ponownie obrobione i innym ocena projektu muszą być przeprowadzane przed rozpoczęciem kodowania na projekt.

2. Określić, kto będzie uczestniczyć w audyt kodu.Zazwyczaj, na co najmniej główny programista i architekta, który jest odpowiedzialny za obszar kodu powinny uczestniczyć w przeglądzie.

3. Zaplanować spotkanie przeglądu z recenzentów i miał wystarczająco dużo czasu dla każdego recenzenta do odczytania i zrozumienia kod przed spotkaniem.Plan długość spotkania przeglądowego odpowiadają ile kod musi być przedmiotem oceny.

Audyt kodu

Audyt kodu jest używana do zapewnienia, że kod nowych lub zmienionych spełnia słupek jakości przed jest zintegrowany codziennych konsolidacji.Uwagi dotyczące jakości są kodowanie norm, zgodność architektury i projektowania, wydajność, czytelności i bezpieczeństwo.Przeglądanie kodu także dodatkowy wgląd z innymi programistami o sposób zapisywania kodu.

Sprawdź kod znaczenie	Kod, który jest redagowany jest istotne dla zadania, w których napisano kod.Żadne zmiany w kodzie należy przewidzieć, że nie zajmują się funkcje, które jest realizowane lub poprawione.
Sprawdź rozszerzalności	Kod jest napisana tak, że może on być przedłużony, jeżeli jest to zamiarem lub wielokrotnie używane w innych częściach systemu. Stałe w postaci ciągów, które są używane w kodzie prawidłowo są umieszczane w zasoby, które mogą być umiędzynarodowione.
Sprawdź minimalne złożoność kodu	Powtarzające się kodu mogą być uproszczone do typowych funkcji. Podobną funkcjonalność zostaje umieszczone na wspólnej procedury lub funkcje.
Sprawdź, co do złożoności algorytmicznych	Liczba ścieżek wykonanie w kodzie, który jest rozpatrywana jest zminimalizowany.
Sprawdź zabezpieczenia dla kodu	Kod jest sprawdzana pod kątem ochrony aktywów, poziomy uprawnień i wykorzystywanie danych w punktach wejścia.

Refaktoringu kodu

Kod jest refactored po audyt kodu ustalono, że zmiany muszą być wprowadzone do rozwiązania jakość kodu, wydajność lub architektury.

Odczytać informacji elementu kodu przegląd prac, aby określić, jak będzie refaktoringu kodu.

Zastosowanie Refaktoryzacja jedną zmianę naraz w porządku rosnącym.Zmienić kod i wszystkie odwołania do obszaru zmodyfikowanych to konieczne.

Tak, aby obszar pozostaje semantycznie równoważne po refaktoryzacji, należy wykonać badania jednostki.Rozwiąż wszystkie testy jednostki, które nie działają.Wykonywanie analizy kodu i naprawić wszelkie ostrzeżenia.Testy należy ponownie wykonać, jeśli kod zmian w wyniku analizy kodu.

Integrowanie zmian

Ostatnim krokiem jest Integracja zmian przez sprawdzanie ich celu kontroli wersji.Zanim kod zostanie zaewidencjonowany, powinny być wykonywane wszystkie testy, które są wymagane przez proces.Aby uzyskać więcej informacji dotyczących sposobu sprawdzania kodu występują problemy, zanim zostanie on zaewidencjonowany, zobacz Poprawy jakości kodu z zespołu projektu Check-in Policies.

Jeśli element, który jest skojarzony z uwzględnieniem zmian jest scenariusz lub jakości wymagania usługi, których nie jesteś właścicielem, powiadamia właściciela, że zmiany są kompletne.Ustaw element pracy zadania na rozwiązany i przypisać ją do jednego z rzeczoznawcy, który utworzył przypadków testowych dla elementu pracy.

Jeśli element, który jest skojarzony z uwzględnieniem zmian jest błąd, Ustaw element pracy błąd na rozwiązany i przypisać ją do pierwotnej osoby, która go utworzyła.