Rozwój prędkości Internetu
Internet-Speed Development to zwinna metoda rozwoju oprogramowania wykorzystująca połączony model spiralny / model kaskadowy z codziennymi kompilacjami mającymi na celu opracowanie produktu o dużej szybkości.
Został opracowany pod koniec lat dziewięćdziesiątych, ponieważ rozwój oprogramowania szybko się zmieniał. Firmy miały problemy z dostarczaniem produktów o odpowiednich wymaganiach w czasie przewidzianym na projekt i jako takie przechodziły na bardziej zwinne metody wytwarzania oprogramowania. Więcej szczegółów na temat tego, jak opracowano metodę prędkości Internetu, można zobaczyć na mapie ewolucyjnej w artykule Abrahamssona.
Główne idee stojące za rozwojem prędkości Internetu
Często jednym z największych problemów w inżynierii oprogramowania jest to, że wymagania szybko się zmieniają, a metoda rozwoju prędkości internetu została stworzona, aby dostosować się do tej sytuacji. Pomysł polega na połączeniu dwóch głównych standardów w modelach inżynierii oprogramowania, a mianowicie modelu spiralnego i modelu kaskadowego w nowy model i oparcie nowej metody inżynierii oprogramowania na tym nowym modelu. Główną wadą modelu kaskadowego było to, że był on bardzo sztywny i mało elastyczny, jeśli chodzi o zmiany wymagań, natomiast wadą modelu spiralnego było to, że był mało ustrukturyzowany. Ideą rozwoju prędkości Internetu jest to, że połączenie tych modeli da w rezultacie metodę, która nie ma tych wad i jest lepszą metodą do wykorzystania w sytuacjach, w których wymagania mogą się szybko zmieniać, ale projekt musi być realizowany w ustrukturyzowany sposób sposób.
Cel metody
Celem metody rozwoju prędkości Internetu jest umożliwienie programistom wykonania projektu w ustrukturyzowany sposób, ale nadal możliwość dostosowania się do potrzeb klienta. Ma na celu dostarczenie oprogramowania w krótkim czasie poprzez intensywny rozwój. Metoda zapewnia środki do dostarczenia w pełni wdrożonego systemu, a także umożliwia określanie postępu w projekcie za pomocą kamieni milowych. Jedna z głównych wersji tej metody jest tworzona przez firmę Microsoft i nosi nazwę Microsoft Solutions Framework.
Koncepcje metody rozwoju prędkości Internetu
Pierwszą koncepcją, która jest bardzo ważna dla rozwoju szybkości Internetu, jest stworzenie wizji i zakresu (zarządzanie projektami) . Oznacza to, że na początku projektu tworzona jest globalna definicja systemu, która wyjaśnia, czym ma być system i co mieści się w zakresie, a co nie. Jest to jeden z podstawowych kroków, ponieważ daje programistom pewne wytyczne co do tego, jaki będzie system bez zamrażania jakichkolwiek wymagań. Zakres można udokumentować w deklaracji wizji .
Kolejnym bardzo ważnym pojęciem w ramach tej metody jest zarządzanie zakresem. Zakres musi być zarządzany przez cały projekt, aby zapobiec pełzaniu zakresu , co skutkuje opóźnieniami. Zakres zostanie określony wcześnie, a zmiany w zakresie (takie jak dodanie dodatkowych funkcji, które początkowo były rozważane poza zakresem projektu) zostaną ocenione i zaakceptowane lub odrzucone. Można wprowadzić zmiany w zakresie, ale zawsze będzie to miało wpływ na kompromisy między funkcjami, zasobami i czasem.
Metoda rozwoju prędkości Internetu bardzo różni się od tradycyjnych metod i dlatego wykorzystuje zasady metody Agile. Koncentruje się na dostosowaniu do wymagań i jako taki opiera się na podstawowych zasadach zwinnego wytwarzania oprogramowania.
Rozwój szybkości Internetu koncentruje się również na użyciu jednej stałej architektury ramowej, z której zbudowany jest produkt, i w dużej mierze opiera się na narzędziach zwiększających szybkość programowania.
Inną podstawową koncepcją rozwoju prędkości Internetu jest to, że koncentruje się również na wykorzystaniu małych zespołów. Chodzi o to, aby wszystkie projekty można było podzielić na mniejsze działania, które często można wykonywać równolegle. Mniejsze zespoły często mogą być bardziej skoncentrowane na swoim zadaniu i łatwiej jest określić odpowiedzialność i monitorować postępy w projekcie.
Ostatnią koncepcją omówioną w tym wpisie dotyczącą rozwoju szybkości Internetu jest koncepcja rozwoju równoległego. Ta koncepcja zasadniczo oznacza, że cały rozwój oprogramowania odbywa się równolegle tak często, jak to możliwe. Pozwoli to na bardzo szybki rozwój i pozwoli mniejszym zespołom maksymalnie skupić się na własnej funkcji, co przekłada się na jakość. Aby jednak mniejsze zespoły współpracowały przy tworzeniu ostatecznego systemu, konieczna jest jednak częsta synchronizacja ich rozwoju. Można to zrobić za pomocą codziennych kompilacji co oznacza, że wszyscy programiści sprawdzają swój kod na koniec dnia, po czym tworzona jest kompilacja, którą można następnie ocenić i przetestować w celu monitorowania postępów. Po ukończeniu funkcji w kompilacji należy ją przetestować i udoskonalić, co jest czasami nazywane procesem synchronizacji i stabilizacji. Opracowane funkcje są synchronizowane z kompilacją i testowane. Po tych testach wszelkie błędy zostaną poprawione, a funkcja może zostać dopracowana, aby działała lepiej (co jest częścią stabilizacji).
Rozwój szybkości Internetu opiera się na zasadach zwinnych i jako taki ma wiele podobieństw z Extreme Programming , Rational Unified Process , DSDM i Feature Driven Development . Rozwój prędkości Internetu różni się jednak od tych metod, ponieważ obejmuje również bardziej rozbudowane planowanie zarządzania ryzykiem, a jakość jest bardzo ważnym celem projektu. Faza rozwoju szybkości Internetu również wykazuje pewne podobieństwa z oprogramowaniem typu open source model rozwoju, ponieważ wielu programistów na całym świecie może być częścią procesu rozwoju ze względu na komunikację przez Internet i wykorzystanie repozytoriów do przechowywania kodu i dokumentacji.
Fazy rozwoju prędkości Internetu
Model stojący za tą metodą wygląda następująco: Rysunek 1: Model fazowy Ten model przedstawia pięć podstawowych faz metody. Fazy te zostaną wyjaśnione w kolejnych częściach tego wpisu. Fazy to: przewidywanie, planowanie, rozwój, stabilizacja i wdrażanie. Po zakończeniu tego cyklu wersja systemu jest gotowa i rozpoczyna się nowy cykl tworzenia nowej wersji. Fazy są wyjaśnione w poniższych sekcjach i pokazane za pomocą metamodelowania . Więcej szczegółów na temat wielości i koncepcji w kontekście projektu można zobaczyć później w ogólnym modelu danych.
Faza wyobrażenia
Faza wyobrażania może być modelowana w następujący sposób:
Rysunek 2: Model procesu/danych w fazie wyobrażania
| Działalność | Definicja (źródło) |
|---|---|
| Analizuj wymagania | W fazie przewidywania należy zidentyfikować i przeanalizować wymagania biznesowe. „Są one dopracowywane bardziej rygorystycznie na etapie planowania”. (Model procesu MSF) |
| Zdefiniuj cele i ograniczenia | „Wyobraź sobie, tworząc ogólny pogląd na cele i ograniczenia projektu”. (Model procesu MSF) |
| Forma zespołu | Tworzenie zespołu podstawowego. |
| Stwórz wizję/zakres | „Przygotowanie i dostarczenie dokumentu wizji/zakresu.” (Model procesu MSF) |
| Utwórz ocenę ryzyka | „W fazie przewidywania zespół przygotowuje dokument ryzyka i przedstawia najważniejsze ryzyka”. (Model procesu MSF) |
Tabela 1: Wyobrażanie sobie działań
Podstawowe czynności wykonywane w fazie przewidywania to analiza wymagań, formowanie zespołu do projektu, określenie ryzyk i zakresu projektu. Na podstawie wymagań i celów projektu tworzony jest dokument Wizja/Zakres. Niniejszy dokument opisuje, jaki ma być produkt w momencie dostawy. Nie zawiera bardzo szczegółowych funkcjonalności produktu.
| Pojęcie | Definicja (źródło) |
|---|---|
| DOKUMENT WIZJI/ZAKRESU | „Dokument określający wizję i zakres”. (Model procesu MSF) |
| WIZJA | „ Wizja to nieograniczony pogląd na to, jakie może być rozwiązanie”. (Model procesu MSF) |
| ZAKRES | „ Zakres identyfikuje te części wizji, które można zrealizować w ramach ograniczeń projektu”. (Model procesu MSF) |
| DOKUMENT OCENY RYZYKA | „Standardowy dokument do oceny ryzyka” (dyscyplina zarządzania ryzykiem MSF) |
| LISTA PRIORYTETOWYCH RYZYK | „Szczegółowe informacje o ryzyku, w tym stan projektu, kontekst, przyczyna źródłowa oraz wskaźniki stosowane do ustalania priorytetów (prawdopodobieństwo, wpływ, ekspozycja) są często rejestrowane dla każdego ryzyka w formularzu zestawienia ryzyka”. (dyscyplina zarządzania ryzykiem MSF) |
| PLANOWANIE RYZYKA | „Przełożenie listy priorytetowych ryzyk na plany działania.” (dyscyplina zarządzania ryzykiem MSF) |
| DOKUMENT STRUKTURY PROJEKTU | „Dokument struktury projektu zawiera informacje o tym, jak zorganizowany jest zespół, kto pełni jakie role i ma określone obowiązki. Dokument dotyczący struktury projektu wyjaśnia również łańcuch odpowiedzialności wobec klienta oraz wyznaczone punkty kontaktowe zespołu projektowego z klientem. Mogą się one różnić w zależności od okoliczności projektu”. (Model procesu MSF) |
| ORGANIZACJA ZESPOŁU | „Informacje o organizacji zespołu.” (Model procesu MSF) |
| PUNKTY KONTAKTOWE | „Wyznaczone punkty styku, jakie zespół projektowy posiada z klientem.” (Model procesu MSF) |
| ROLE W ZESPOLE | „Określenie, kto odgrywa jakie role i ma określone obowiązki”. (Model procesu MSF) |
Tabela 2: Koncepcje w fazie wyobrażania
Faza planowania
Rysunek 3: Model procesu/danych fazy planowania
| Działalność | Definicja (źródło) | |
|---|---|---|
| Zdefiniuj wymagania | Na wczesnym etapie planowania zespół analizuje i dokumentuje wymagania na liście lub narzędziu. Wymagania dzielą się na cztery szerokie kategorie: wymagania biznesowe, wymagania użytkowników, wymagania operacyjne i wymagania systemowe (dotyczące samego rozwiązania). (Model procesu MSF) |
|
| Śledź wymagania do funkcji | „Gdy zespół przechodzi do projektowania rozwiązania i tworzenia specyfikacji funkcjonalnych, ważne jest, aby zachować identyfikowalność między wymaganiami a funkcjami. Identyfikowalność nie musi opierać się na zasadzie jeden do jednego. Zachowanie identyfikowalności jest jednym ze sposobów sprawdzenia poprawności projektu i sprawdzenia, czy projekt spełnia cele i wymagania rozwiązania”. (Model procesu MSF |
|
| Zdefiniuj specyfikację funkcjonalną | „Zespół przygotowuje specyfikację funkcjonalną.” (Model procesu MSF |
|
| Utwórz Planowanie | Oszacuj ryzyko | Zespół tworzy oszacowanie ryzyka. |
| Oszacuj koszty | Zespół tworzy kosztorys. | |
| Twórz plany pracy | Zespół tworzy plany pracy. | |
| Twórz harmonogramy | Zespół tworzy harmonogramy. | |
| Utwórz projekt | Utwórz model przypadków użycia | „Zaczyna się to od systematycznej analizy profili użytkowników
(zwane także „personami”), które opisują różne typy użytkowników i ich funkcje służbowe (użytkownikami są także pracownicy operacyjni). Wiele z nich często odbywa się w fazie wyobrażania sobie. Są one podzielone na szereg scenariuszy użytkowania , w których określony typ użytkownika próbuje wykonać określoną czynność, taką jak rejestracja recepcji w hotelu lub administrowanie hasłami użytkowników dla administratora systemu. Wreszcie, każdy scenariusz użycia jest podzielony na określoną sekwencję zadań, zwaną przypadkami użycia , które użytkownik wykonuje, aby ukończyć tę czynność. Nazywa się to „storyboardingiem”. (Model procesu MSF |
| Stwórz projekt koncepcyjny | Stworzenie projektu koncepcyjnego. | |
| Stwórz projekt logiczny | Tworzenie logicznego projektu. | |
| Utwórz projekt fizyczny | Stworzenie projektu fizycznego. | |
| Twórz architekturę | Tworzenie architektury produktu. | |
Tabela 3: Działania planistyczne W fazie planowania na podstawie wymagań tworzona jest specyfikacja funkcjonalna. Wybrane funkcje są uwzględnione w tej specyfikacji ( dla funkcji często stosowana jest metoda MoSCoW , aby łatwiej można było nadać im priorytet). W tej fazie tworzony jest również podstawowy projekt i planowanie. Projekt jednak w tej fazie nie jest zamrożony, ponieważ w fazie rozwoju mogą zostać wprowadzone zmiany.
| Pojęcie | Definicja (źródło) |
|---|---|
| LISTA WYMAGAŃ | Dokumentacja wymagań na liście lub narzędziu”. (Model procesu MSF |
|
RYZYKOWNY PLAN ZARZĄDZANIA |
Dokument o tym, jak zespół planuje wdrożyć proces zarządzania ryzykiem w kontekście projektu.” (dyscyplina zarządzania ryzykiem MSF) |
| GŁÓWNY PLAN PROJEKTU | Wszystko plany są synchronizowane i prezentowane razem jako główny plan projektu.” (Model procesu MSF |
| PLANY PRACY | Plan lub plany dotyczące rezultatów, które odnoszą się do roli i uczestniczy w sesjach planowania zespołu”. (Model procesu MSF |
| KOSZTORYSY | Oszacowanie kosztów projektu. |
| HARMONOGRAM | Szacunkowe terminy i harmonogramy dla Elementów Dostarczanych”. (Model procesu MSF |
| HARMONOGRAM PROJEKTU GŁÓWNEGO | The różne harmonogramy są następnie synchronizowane i integrowane w głównym harmonogramie projektu”. (Model procesu MSF |
| SPECYFIKACJA FUNKCJONALNA | The Specyfikacja funkcjonalna szczegółowo opisuje jak każda cecha ma wyglądać i zachowywać się. Opisuje również architekturę i projekt wszystkich funkcji”. (Model procesu MSF |
Tabela 4: Koncepcje w fazie planowania
Faza rozwoju
Rysunek 4: Faza opracowywania modelu procesu/danych
| Działalność | Definicja (źródło) |
|---|---|
| Rozwijaj funkcje | Budowa komponentów rozwiązania (dokumentacja jak i kod).” (Model procesu MSF) Obejmuje również testowanie po codziennej kompilacji, naprawianie błędów i ocenę funkcji. |
| Twórz codzienną kompilację | Tworzenie kompilacji po dniu roboczym. |
| Sfinalizuj zakres | Na tym etapie wszystkie funkcje są kompletne, a rozwiązanie jest gotowe do zewnętrznych testów i stabilizacji”. (Model procesu MSF) |
| Rozwijaj infrastrukturę | Infrastruktura jest rozwinięta.” (Model procesu MSF) |
Tabela 5: Działania rozwijające Najważniejszą czynnością w fazie opracowywania jest rozwój funkcji. Oprócz implementacji tych funkcji, w tej fazie finalizowany jest również zakres. Podczas opracowywania do produktu mogą być dodawane nowe funkcje, ale po sfinalizowaniu zakresu funkcje zostają zamrożone i gotowe do testowania i stabilizacji. W tej fazie rozwijana jest również infrastruktura, co oznacza identyfikację struktur sieciowych i zdefiniowanie serwerów, takich jak np. serwer bazy danych.
| Pojęcie | Definicja (źródło) |
|---|---|
| SKRYPTY INSTALACJI I USTAWIENIA KONFIGURACJI DO WDROŻENIA | Zbiór skryptów i ustawień potrzebnych do zainstalowania/uruchomienia produktu. |
| SKRYPTY INSTALACJI | Skrypty potrzebne do zainstalowania produktu. |
| USTAWIENIA KONFIGURACJI |
Właściwości konfiguracyjne produktu. |
| ELEMENTY WSPIERAJĄCE WYDAJNOŚĆ | Elementy wspierające działanie produktu (dodatkowe bazy danych, serwery itp.). |
| SPECYFIKACJE TESTOWE I PRZYPADKI TESTOWE | Specyfikacja testów i przypadków testowych stosowanych do walidacji produktu. |
| SPECYFIKACJA FUNKCJONALNA | Specyfikacja funkcjonalna szczegółowo opisuje, jak każda cecha ma wyglądać i zachowywać się. Opisuje również architekturę i projekt wszystkich funkcji”. (Model procesu MSF) |
| KOD ŹRÓDŁOWY I PLIKI WYKONAWCZE | Kombinacja kodu źródłowego/plików wykonywalnych. |
| KOD ŹRÓDŁOWY | Kod źródłowy produktu. |
| WYKONYWALNE | Plik wykonywalny utworzony przez kod źródłowy. |
Tabela 5: Koncepcje w fazie rozwoju
faza stabilizacji
Rysunek 5: Proces fazy stabilizacji/model danych
| Działalność | Definicja (źródło) |
|---|---|
| Testowanie | Testy w tej fazie kładą nacisk na użytkowanie i działanie w realistycznych warunkach środowiskowych.“ (Model procesu MSF) |
| Rozwiąż błędy | Zespół koncentruje się na rozwiązywaniu i segregowaniu (nadawanie priorytetów) błędom oraz przygotowywaniu rozwiązania do wydania”. (Model procesu MSF) |
| Wdróż pilota | Gdy kompilacja zostanie uznana za wystarczająco stabilną, aby mogła być kandydatem do wydania, rozwiązanie jest wdrażane w grupie pilotażowej”. (Model procesu MSF) |
| Recenzja | Po sprawdzeniu i zatwierdzeniu rozwiązanie jest gotowe do pełnego wdrożenia w środowisku produkcyjnym na żywo”. (Model procesu MSF) |
Tabela 6: Działania stabilizacyjne Główne działania to testowanie i usuwanie błędów. Gdy wersja kompilacji zostanie uznana za wystarczająco stabilną dla pilota, tworzona jest i wdrażana wersja pilotażowa. Z tego pilotażowego albo wróci do pętli testowania/stabilizowania, albo zostanie zatwierdzony i zweryfikowany.
| Pojęcie | Definicja (źródło) |
|---|---|
| WYNIKI TESTÓW I NARZĘDZIA TESTOWE | Zbiór wyników testów i narzędzi używanych do testowania. |
| WYNIKI TESTU | Wyniki przeprowadzonych testów. |
| NARZĘDZIA DO TESTOWANIA | Narzędzia używane do testowania. |
| ZŁOTE WYDANIE | Wersja używana do ostatecznej recenzji. |
| INFORMACJE O WYDANIU | Uwagi dotyczące wersji wydania. |
| KOD ŹRÓDŁOWY I WYKONYWALNY | Kombinacja kodu źródłowego/plików wykonywalnych. |
| KOD ŹRÓDŁOWY | Kod źródłowy produktu. |
| WYKONYWALNE | Plik wykonywalny utworzony przez kod źródłowy. |
| PRZEGLĄD KAMIENIA MILOWEGO | Przegląd ostatecznej wersji i dokumentów projektowych. |
| DOKUMENTY PROJEKTOWE | Zbieranie wszystkich dokumentów projektowych. |
Tabela 7: Koncepcje w fazie stabilizacji
faza rozmieszczenia
Rysunek 6: Proces/model danych w fazie wdrażania
| Działalność | Definicja (źródło) |
|---|---|
| Wdróż podstawowe składniki | Wdrożenie wszystkich komponentów wymaganych przez produkt (takich jak serwery baz danych, serwery poczty itp.) |
| Wdróż rozwiązanie na miejscu | W przypadku systemów dostosowanych do potrzeb wdrożenie produktu odbywa się tutaj (można pominąć w przypadku oprogramowania). |
| Ustabilizuj wdrożenie | Sczepianie, monitorowanie i ulepszanie wdrożonych komponentów. |
| Przenieś projekt do operacji i wsparcia | Przekazanie wszystkich dokumentów i kodu do zespołu operacyjnego i wsparcia. |
| Uzyskaj ostateczną akceptację od klienta | Klient musi zaakceptować, że zespół osiągnął swoje cele, zanim będzie mógł zadeklarować, że rozwiązanie jest w fazie produkcyjnej i zamknąć projekt. Wymaga to stabilnego rozwiązania, a także jasno określonych kryteriów sukcesu. Aby rozwiązanie można było uznać za stabilne, muszą istnieć odpowiednie systemy operacyjne i wspierające”. (Model procesu MSF) |
| Przejrzyj projekt | Końcowa ocena projektu. |
Tabela 8: Działania związane z wdrażaniem Głównym działaniem w fazie wdrażania jest instalacja infrastruktury potrzebnej do uruchomienia produktu (wdrożenie serwerów itp.). Finalizowane są również dokumenty i przekazywane do działu operacji i wsparcia, tworzona jest baza wiedzy oraz weryfikowany jest produkt i projekt przez klienta (jeśli dotyczy) i zespół projektowy.
| Pojęcie | Definicja (źródło) |
|---|---|
| PROCEDURY I PROCESY | Zbiór procedur i procesów. |
| PROCEDURY | Zbiór procedur, które należy zastosować podczas instalacji i obsługi produktu. |
| PROCESY | Zbiór procesów, które mają być użyte do instalacji i obsługi produktu. |
| BAZA WIEDZY, RAPORTY, DZIENNIKI | Gromadzenie bazy wiedzy, raportów i dzienników. |
| BAZA WIEDZY | Baza wiedzy powiązana z produktem. |
| RAPORTY | Raporty powiązane z produktem. |
| DZIENNIKI | Dzienniki powiązane z produktem. |
| REPOZYTORIUM DOKUMENTÓW | Repozytorium wszystkich dokumentów. |
| OSTATECZNE WERSJE WSZYSTKICH DOKUMENTÓW PROJEKTOWYCH | Ostateczne wersje dokumentów projektowych. |
| DZIAŁANIE I WSPARCIE SYSTEMÓW INFORMACYJNYCH | Systemy używane przez zespoły operacyjne i wsparcia powiązane z produktem. |
| DANE DOTYCZĄCE SATYSFAKCJI KLIENTÓW/UŻYTKOWNIKÓW | Zbieranie danych od klienta/użytkownika o jego zadowoleniu z produktu. |
| OKREŚLENIE KOLEJNYCH KROKÓW | Opis kolejnych kroków, które należy wykonać, aby udoskonalić produkt. |
| RAPORT Z ZAKOŃCZENIA PROJEKTU |
Raport końcowy dotyczący produktu, projektu i przekazania do operacji i wsparcia. |
Tabela 9: Koncepcje w fazie wdrażania
Ogólny model danych
Rysunek 7: Ogólny model danych Ten model danych przedstawia wszystkie koncepcje z krotnościami i relacjami w pełnym kontekście projektu.
Narzędzia do użytku z Internet-Speed Development
- Narzędzia do rysowania (przykłady: Microsoft Visio, Rational Rose, Dia ) Do tworzenia diagramów.
- Edytory tekstu (przykłady: Microsoft Word, OpenOffice.org Writer, AbiWord , Calligra Words ) Do tworzenia dokumentów tekstowych, takich jak deklaracja wizji lub dokument zakresu.
- Arkusze kalkulacyjne (przykłady: Microsoft Excel, OpenOffice.org Calc, Gnumeric , Calligra Sheets ) Do tworzenia priorytetowych list ryzyka i kalkulacji kosztów.
- Narzędzia projektowe (przykłady: Microsoft Project, OpenProj , Gnome Planner, Calligra Plan ) Do planowania działań projektowych.
- Narzędzia do zarządzania bazami danych i bazami danych (przykłady: MS SQL Server, MySQL , Oracle, PostgreSQL ) Do tworzenia baz wiedzy.
- Zautomatyzowane narzędzia do testowania (przykłady: Skrypty testowe) Do wykonywania testów po każdej codziennej kompilacji.
Zobacz też
- Zwinne tworzenie oprogramowania
- Rozwój przyrostowy i iteracyjny
- Ramy rozwiązań firmy Microsoft
- Metoda rozwoju systemów dynamicznych (DSDM)
- Metoda MoSCoW
Notatki
- ^ Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003
- ^ Jak pokazano w artykule Zuser, Heil i Grechening.
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad Microsoft Solutions White Paper, czerwiec 2002
- ^ a b c d Biała księga dyscypliny zarządzania ryzykiem firmy Microsoft
- Microsoft czerwiec 2002 Microsoft Solutions Framework (biała księga) Microsoft Press
- Microsoft, czerwiec 2002 MSF Risk Management Discipline, wersja 1.1 (biała księga) Microsoft Press
- Wolfgang Zuser, Stefan Heil, Thomas Grechenig 2005 Tworzenie i zapewnianie jakości oprogramowania w RUP, MSF i XP - badanie porównawcze Postępowanie z warsztatów 2005 na temat jakości oprogramowania
- Pekka Abrahamsson, Juhani Warsta, Mikko T. Siponen, Jussi Ronkainen 2003 Nowe kierunki metod zwinnych: analiza porównawcza ICSE
- Michael A. Cusumano, David B. Yoffie 1999 Tworzenie oprogramowania w czasie internetowym 32 IEEE
- Balasubramaniam Ramesh, Jan Pries-Heje 2002 Internetowa inżynieria oprogramowania: inna klasa procesów Annals of Software Engineering 14 169–195