Modernizacja oprogramowania

Modernizacja starszej wersji, znana również jako modernizacja oprogramowania lub modernizacja platformy, odnosi się do konwersji, przepisania lub przeniesienia starszego systemu do nowoczesnych języków programowania komputerów , architektur (np. mikroserwisów ), bibliotek oprogramowania, protokołów lub platform sprzętowych. Transformacja starszego typu ma na celu zachowanie i zwiększenie wartości dotychczasowej inwestycji poprzez migrację na nowe platformy, aby skorzystać z zalet nowych technologii.

Podstawą i pierwszym krokiem inicjatyw modernizacji oprogramowania, strategii, zarządzania ryzykiem, oszacowania kosztów i jej realizacji jest wiedza o modernizowanym systemie. Wiedza o tym, do czego służą wszystkie funkcjonalności i wiedza o tym, jak zostały opracowane. Ponieważ eksperci merytoryczni (MŚP), którzy pracowali na początku i podczas wszystkich ewolucji aplikacji, są już niedostępni lub mają częściową wiedzę oraz brak odpowiedniej i aktualnej dokumentacji, inicjatywy modernizacyjne rozpoczynają się od oceny i odkrywanie aplikacji za pomocą analizy oprogramowania .

Strategie

Podejmowanie decyzji dotyczących modernizacji oprogramowania jest procesem w pewnym kontekście organizacyjnym. Podejmowanie decyzji w „realnym świecie” w organizacjach biznesowych często musi opierać się na „ograniczonej racjonalności”. Poza tym istnieje wiele (i prawdopodobnie sprzecznych) kryteriów decyzyjnych; pewność, kompletność i dostępność przydatnych informacji (będących podstawą decyzji) jest często ograniczona.

Modernizacja starego systemu to często duży, wieloletni projekt. Ponieważ te przestarzałe systemy mają często krytyczne znaczenie w działaniach większości przedsiębiorstw, jednoczesne wdrożenie zmodernizowanego systemu wprowadza niedopuszczalny poziom ryzyka operacyjnego. W rezultacie starsze systemy są zazwyczaj modernizowane stopniowo. Początkowo system składa się całkowicie ze starszego kodu. Po ukończeniu każdego przyrostu procent starszego kodu maleje. Docelowo system zostaje całkowicie zmodernizowany. Strategia migracji musi zapewniać pełną funkcjonalność systemu podczas prac modernizacyjnych.

Strategie modernizacyjne

Istnieją różne czynniki i strategie modernizacji oprogramowania:

  • Architecture Driven Modernization (ADM) to inicjatywa mająca na celu standaryzację widoków istniejących systemów w celu umożliwienia wspólnych działań modernizacyjnych, takich jak analiza i zrozumienie kodu oraz transformacja oprogramowania.
  • Podejście zorientowane na biznes: Strategia modernizacji jest powiązana z biznesową wartością dodaną przez modernizację. Oznacza to zdefiniowanie punktu przecięcia krytyczności dla biznesu aplikacji z jej jakością techniczną. To podejście forsowane przez firmę Gartner stawia analizę portfolio aplikacji (APA) jako warunek wstępny decyzji dotyczących modernizacji portfela aplikacji w celu pomiaru stanu oprogramowania, zagrożeń, złożoności i kosztów, zapewniając wgląd w mocne i słabe strony aplikacji.
  • Model Driven Engineering (MDE) jest badany jako podejście do inżynierii odwrotnej, a następnie do inżynierii kodu oprogramowania.
  • Renaissance Metoda iteracyjnej oceny starszych systemów z perspektywy technicznej, biznesowej i organizacyjnej.
  • WMU (ang. Warrants, Maintenance, Upgrade) to model doboru odpowiednich strategii utrzymania w oparciu o założony poziom satysfakcji klienta i ich wpływ na ten poziom.

Zarządzanie ryzykiem modernizacji

Modernizacja oprogramowania to ryzykowny, trudny, długi i wysoce intelektualny proces angażujący wielu interesariuszy. Zadania modernizacji oprogramowania są wspierane przez różne narzędzia związane z architekturą Model-driven z grupy Object Management Group oraz procesy takie jak ISO/IEC 14764:2006 czy Service-Oriented Migration and Reuse Technique (SMART). Modernizacja oprogramowania wiąże się z różnymi ręcznymi i automatycznymi zadaniami wykonywanymi przez wyspecjalizowanych pracowników wiedzy. Narzędzia wspierają zadania uczestników projektu oraz pomagają organizować współpracę i sekwencjonowanie prac.

Ogólne podejście do zarządzania modernizacją oprogramowania z wyraźnym uwzględnieniem ryzyka (zarówno celów technologicznych, jak i biznesowych) obejmuje:

  • Analiza istniejącego portfela: pomiar jakości technicznej i wartości biznesowej. Konfrontacja jakości technicznej z celami biznesowymi w celu określenia właściwej strategii: zastąpić, nie iść, niski priorytet, dobry kandydat.
  • Zidentyfikuj interesariuszy: wszystkie osoby zaangażowane w modernizację oprogramowania: programiści, testerzy, klienci, użytkownicy końcowi, architekci, …
  • Zrozum wymagania: wymagania są podzielone na 4 kategorie: użytkownik, system, ograniczenia i niefunkcjonalne.
  • Utwórz uzasadnienie biznesowe: uzasadnienie biznesowe wspiera proces decyzyjny w rozważaniu różnych podejść, gdy decydenci tego potrzebują.
  • Zrozumienie systemu, który ma zostać zmodernizowany: jest to krytyczny krok, ponieważ dokumentacja oprogramowania rzadko jest aktualna, a projekty są tworzone przez wiele zespołów, zarówno wewnętrznych, jak i zewnętrznych, i zwykle pozostają poza zasięgiem wzroku przez długi czas. Wyodrębnianie zawartości aplikacji i projektu jej architektury pomaga zrozumieć system.
  • Zrozumienie i ocena docelowej technologii: pozwala to na porównanie technologii i możliwości z wymaganiami i istniejącym systemem.
  • Zdefiniuj strategię modernizacji: strategia definiuje proces transformacji. Strategia ta musi uwzględniać zmiany zachodzące w procesie modernizacji (zmiany technologii, dodatkowa wiedza, ewolucja wymagań).
  • Pogodź strategię z potrzebami interesariuszy: implikowani interesariusze mogą mieć różne opinie na temat tego, co jest ważne i jaki jest najlepszy sposób postępowania. Ważne jest, aby osiągnąć konsensus między zainteresowanymi stronami.
  • Oszacuj zasoby: po zdefiniowaniu poprzednich kroków można oszacować koszty. Pozwala kierownictwu określić, czy strategia modernizacji jest wykonalna przy dostępnych zasobach i ograniczeniach.

Koszty modernizacji

  • Softcalc (Sneed, 1995a) to model i narzędzie do szacowania kosztów przychodzących zgłoszeń serwisowych, opracowane w oparciu o COCOMO i FPA.
  • EMEE (Early Maintenance Effort Estimation) to nowe podejście do szybkiego szacowania prac konserwacyjnych przed rozpoczęciem właściwej konserwacji.
  • RENAISSANCE to metoda wspierania ewolucji systemu poprzez przywrócenie stabilnej podstawy za pomocą reengineeringu, a następnie ciągłe doskonalenie systemu poprzez strumień stopniowych zmian. Podejście to z powodzeniem integruje się z różnymi procesami zarządzania projektami

Wyzwania związane z modernizacją spuścizny

Główne problemy związane z istniejącym systemem obejmują bardzo stare systemy z brakiem dokumentacji, brak MŚP/wiedzy na temat istniejących systemów oraz brak umiejętności technologicznych, w których zostały wdrożone istniejące systemy. Typowe starsze systemy istnieją od ponad dwóch dekad. Migracja jest pełna wyzwań:

  • Brak wglądu w duże portfele aplikacji — duże organizacje IT mają setki, jeśli nie tysiące systemów oprogramowania. Technologia i wiedza funkcjonalna są z natury rozproszone, rozmyte i nieprzejrzyste. Brak centralnego punktu widoczności dla kierownictwa wyższego szczebla i architektów korporacyjnych nie jest głównym problemem — podejmowanie decyzji dotyczących modernizacji systemów oprogramowania bez posiadania niezbędnych danych ilościowych i jakościowych na temat tych systemów w całym przedsiębiorstwie jest trudne.
  • Zarządzanie zmianami organizacyjnymi — Użytkownicy muszą zostać ponownie przeszkoleni i wyposażeni, aby skutecznie używać i rozumieć nowe aplikacje i platformy.
  • Współistnienie starszych i nowych systemów — Organizacje z dużą liczbą starszych systemów nie mogą przeprowadzić migracji od razu. Należy przyjąć podejście polegające na stopniowej modernizacji. Jednak wiąże się to z własnym zestawem wyzwań, takich jak zapewnienie pełnego pokrycia biznesowego z dobrze zrozumiałą i wdrożoną nakładającą się funkcjonalnością, duplikacją danych; wyrzucane systemy, aby połączyć stare i nowe systemy potrzebne w fazach przejściowych.
  • Słabe zarządzanie jakością strukturalną (patrz jakość oprogramowania ), w wyniku czego zmodernizowana aplikacja niesie ze sobą więcej problemów z bezpieczeństwem, niezawodnością, wydajnością i łatwością konserwacji niż oryginalny system.
  • Znaczne koszty i czas trwania modernizacji — modernizacja złożonego systemu o znaczeniu krytycznym może wymagać dużych inwestycji, a czas posiadania w pełni działającego zmodernizowanego systemu może ciągnąć się latami, nie wspominając o nieprzewidzianych niepewnościach w tym procesie.
  • Zaangażowanie interesariuszy - Główny interesariusz organizacji musi być przekonany o inwestycji w modernizację, ponieważ korzyści i natychmiastowy zwrot z inwestycji mogą nie być widoczne w porównaniu z kosztami inwestowania w modernizację.
  • Kompozycja oprogramowania — niezwykle rzadko zdarza się, aby programiści tworzyli w dzisiejszych czasach w 100% oryginalny kod w czymkolwiek zbudowanym po 2010 roku. Często używają frameworków i komponentów oprogramowania innych firm i open source, aby uzyskać wydajność, szybkość i możliwość ponownego użycia. Wprowadza to dwa zagrożenia: 1.) luki w kodzie strony trzeciej oraz 2.) ryzyko licencji open source.

Wreszcie, nie ma jednego rozwiązania, które pasowałoby do każdego rodzaju opcji modernizacji. Przy wielu komercyjnych i niestandardowych opcjach modernizacji, niezwykle ważne jest, aby klienci, sprzedawcy i wykonawcy zrozumieli zawiłości różnych technik modernizacji, ich najlepsze implementacje, przydatność w określonym kontekście oraz najlepsze praktyki, których należy przestrzegać przed wybór właściwego podejścia do modernizacji.

Opcje modernizacji

Na przestrzeni lat pojawiło się kilka różnych opcji modernizacji spuścizny — każda z nich spotkała się z różnym powodzeniem i przyjęciem. Nawet teraz istnieje szereg możliwości, jak wyjaśniono poniżej, i nie ma „opcji” dla wszystkich dotychczasowych inicjatyw transformacji.

  • Ocena aplikacji: analiza istniejącego portfela aplikacji przy użyciu analizy oprogramowania w celu zrozumienia kondycji, jakości, składu, złożoności i gotowości oprogramowania do chmury do rozpoczęcia segmentacji i ustalania priorytetów aplikacji pod kątem różnych opcji modernizacji.
  • Wykrywanie aplikacji : Komponenty aplikacji są silnie przeplatane, co wymaga zrozumienia złożoności i rozwiązania współzależności komponentów oprogramowania.
  • Migracja: migracja języków (3GL lub 4GL), baz danych (przestarzałe do RDBMS i jednego RDBMS do innego), platformy (z jednego systemu operacyjnego do innego), często przy użyciu automatycznych konwerterów lub systemów transformacji programów w celu uzyskania wysokiej wydajności . Jest to szybki i ekonomiczny sposób na przekształcenie starszych systemów.
  • Migracja do chmury: migracja starszych aplikacji na platformy chmurowe, często przy użyciu metodologii, takiej jak metodologia 5 Rs firmy Gartner, w celu segmentacji i priorytetyzacji aplikacji w różnych modelach (Rehost, Refactor, Revise, Rebuild, Replace).
  • Re-engineering: Technika przebudowy starszych aplikacji w nowej technologii lub na nowej platformie, z tą samą lub ulepszoną funkcjonalnością – zwykle poprzez przyjęcie architektury zorientowanej na usługi (SOA). Jest to najbardziej wydajny i zwinny sposób przekształcania starszych aplikacji. analizy oprogramowania na poziomie aplikacji ze starszymi systemami, które nie są dobrze znane ani udokumentowane.
  • Re-hosting: Uruchamianie starszych aplikacji bez większych zmian na innej platformie. Logika biznesowa jest zachowywana podczas migracji aplikacji i danych do otwartego środowiska. Ta opcja wymaga jedynie wymiany oprogramowania pośredniego, sprzętu, systemu operacyjnego i bazy danych. Jest to często używane jako krok pośredni w celu wyeliminowania starszego i drogiego sprzętu. Najczęstsze przykłady obejmują ponowne hostowanie aplikacji mainframe na platformie UNIX lub Wintel .
  • Implementacja pakietu: Zastąpienie starszych aplikacji, w całości lub w części, gotowym oprogramowaniem (COTS), takim jak ERP, CRM, SCM, oprogramowanie rozliczeniowe itp.

Starszy kod to dowolna aplikacja oparta na starszych technologiach i sprzęcie, taka jak komputery mainframe, która nadal zapewnia organizacji podstawowe usługi. Starsze aplikacje są często duże i trudne do modyfikacji, a złomowanie lub zastępowanie ich często oznacza również przeprojektowanie procesów biznesowych organizacji. Jednak coraz więcej aplikacji napisanych w tak zwanych nowoczesnych językach, takich jak java , staje się dziedzictwem. Podczas gdy „starsze” języki, takie jak COBOL znajdują się na szczycie listy tego, co można by uznać za dziedzictwo, oprogramowanie napisane w nowszych językach może być równie monolityczne, trudne do modyfikacji, a zatem może być kandydatem do projektów modernizacyjnych.

Ponowne wdrażanie aplikacji na nowych platformach w ten sposób może obniżyć koszty operacyjne, a dodatkowe możliwości nowych technologii mogą zapewnić dostęp do funkcji, takich jak usługi sieciowe i zintegrowane środowiska programistyczne. Po zakończeniu transformacji i osiągnięciu równoważności funkcjonalnej aplikacje można lepiej dostosować do obecnych i przyszłych potrzeb biznesowych poprzez dodanie nowych funkcji do przekształconej aplikacji. Niedawny rozwój nowych technologii, takich jak transformacja programu poprzez modernizację oprogramowania przedsiębiorstwa uczyniły proces transformacji dotychczasowego oprogramowania efektywnym kosztowo i dokładnym sposobem zachowania dotychczasowych inwestycji, a tym samym uniknięcia kosztów i wpływu migracji na całkowicie nowe oprogramowanie na działalność biznesową.

Celem transformacji starszego typu jest zachowanie wartości starszego zasobu na nowej platformie . W praktyce transformacja ta może przybierać różne formy. Może to na przykład obejmować tłumaczenie kodu źródłowego lub ponowne wykorzystanie istniejącego kodu w pewnym stopniu, a także możliwość połączenia z hostem w celu zapewnienia klientom dostępu wymaganego przez firmę. Jeśli przepisanie , istniejące reguły biznesowe można wyodrębnić, aby stanowiły część zestawienia wymagań dla przepisania.

Migracja oprogramowania

Migracja oprogramowania to proces przechodzenia z jednego środowiska operacyjnego do innego, które w większości przypadków jest uważane za lepsze. Na przykład przejście z systemu Windows NT Server do systemu Windows 2000 Server byłoby zwykle uważane za migrację, ponieważ wymaga upewnienia się, że nowe funkcje są wykorzystywane, stare ustawienia nie wymagają zmiany, a także podjęcie kroków w celu zapewnienia, że ​​obecne aplikacje będą nadal działać w nowym środowisko. Migracja może również oznaczać przejście z systemu Windows NT do systemu opartego na systemie UNIX system operacyjny (lub odwrotnie). Migracja może obejmować przejście na nowy sprzęt, nowe oprogramowanie lub jedno i drugie. Migracja może być na małą skalę, na przykład migracja pojedynczego systemu, lub na dużą skalę, obejmującą wiele systemów, nowe aplikacje lub przeprojektowaną sieć.

Można migrować dane z jednego rodzaju bazy danych do innego rodzaju bazy danych. Zwykle wymaga to danych w jakimś wspólnym formacie, który można wyprowadzić ze starej bazy danych i wprowadzić do nowej bazy danych. Ponieważ nowa baza danych może być inaczej zorganizowana, może być konieczne napisanie programu, który będzie mógł przetwarzać migrowane pliki.

Gdy migracja oprogramowania osiągnie równoważność funkcjonalną, migrowana aplikacja może być bardziej dostosowana do obecnych i przyszłych potrzeb biznesowych poprzez dodanie nowych funkcji do przekształconej aplikacji.

Migrację zainstalowanego oprogramowania ze starego komputera na nowy można przeprowadzić za pomocą narzędzia do migracji oprogramowania. Migracja jest również używana w odniesieniu do procesu przenoszenia danych z jednego urządzenia pamięci masowej do drugiego.

Artykuły, dokumenty i książki

Tworzenie oprogramowania wielokrotnego użytku

Ze względu na ewolucję technologii niektóre firmy lub grupy ludzi nie znają znaczenia starszych systemów. Niektóre z ich funkcji są zbyt ważne, aby ich nie używać, i zbyt drogie, by odtworzyć je ponownie. Branża oprogramowania i badacze zwrócili ostatnio większą uwagę na tworzenie oprogramowania opartego na komponentach w celu zwiększenia produktywności i skrócenia czasu wprowadzenia produktu na rynek.

Modernizacja zarządzana ryzykiem

Ogólnie rzecz biorąc, trzy klasy technologii systemów informatycznych są przedmiotem zainteresowania przy modernizacji starszych systemów: Technologie wykorzystywane do budowy starszych systemów, w tym języki i systemy baz danych. Nowoczesne technologie, które często oznaczają nirwanę dla tych, którzy pogrążyli się w technologii sprzed dziesięcioleci i które niosą (często niespełnioną) obietnicę potężnych, efektywnych i łatwych w utrzymaniu systemów informatycznych przedsiębiorstwa. Technologie oferowane przez starszych dostawców systemów — te technologie zapewniają ścieżkę aktualizacji dla tych, którzy są zbyt nieśmiali lub zbyt mądrzy, aby rzucić się w wir najnowszej fali ofert IT. Dostawcy starszych systemów oferują te technologie z jednego prostego powodu: aby zapewnić ścieżkę aktualizacji do modernizacji systemu, która nie wymaga wychodzenia z komfortu „łona mainframe”. Chociaż te technologie mogą zapewnić płynniejszą drogę do nowoczesnego systemu, często dają akceptowalne rozwiązanie, które nie jest idealne.

Zobacz też

  1. ^ a b Gardner, D: „Nie tylko szczypanie i zakładanie, modernizacja aplikacji wydłuża cykl życia starszych zasobów kodu” , ZDNet , 24 października 2006
  2. ^    Wolfart, Daniele; Assunção, Wesley; da Silva, Ivonei; Domingos, Diogo; Schmeing, Ederson; Villaca, Guilherme; Paza, Diogo (czerwiec 2021). „Modernizacja starszych systemów za pomocą mikrousług: plan działania” . Ocena i ocena w inżynierii oprogramowania : 149–159. doi : 10.1145/3463274.3463334 . ISBN 9781450390538 . S2CID 235474042 .
  3. ^    Bartoszuk, Cezary; Dąbrowski Robert; Stencel, Krzysztof; Timoszuk, Grzegorz (czerwiec 2013). „O szybkim zrozumieniu i ocenie oprogramowania” . Materiały z 14. Międzynarodowej Konferencji Systemów i Technologii Komputerowych : 161–168. doi : 10.1145/2516775.2516806 . ISBN 9781450320214 . S2CID 17034416 .
  4. ^ Ograniczona racjonalność Simona. Geneza i zastosowanie w teorii ekonomii
  5. Bibliografia _ Tomasza Klineta. „Tworzenie uzasadnienia biznesowego modernizacji aplikacji wieloplatformowych” . {{ cite journal }} : Cite journal wymaga |journal= ( pomoc )
  6. ^ ab Menychtas , Andreas; Santzaridou, Krystyna; Kousiuris, George; Varvarigou, Teodora; Orue-Echevarria, Leire; Alonso, Juncal; Gorronogoitia, Jezus; Bruneliere, Hugo; Strauss, Oliver; Senkova, Tatiana; Pellens, Bram; Stuer, Peter (2013), „ARTIST Methodology and Framework: A Novel Approach for the Migracy of Legacy Software on the Cloud” (PDF) , 2013 15th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing , 15th International Symposium on Symbolic and Numeric Algorytmy dla obliczeń naukowych (SYNASC), IEEE, s. 424–431, doi    : 10.1109/SYNASC.2013.62 , ISBN 978-1-4799-3036-4 , S2CID 8150975
  7. ^ ab Menychtas , Andreas; Konstanteli, Kleopatra; Alonso, Juncal; Orue-Echevarria, Leire; Gorronogoitia, Jezus; Kousiuris, George; Santzaridou, Krystyna; Bruneliere, Hugo; Pellens, Bram; Stuer, Piotr; Strauss, Oliver; Senkova, Tatiana; Varvarigou, Theodora (2014), „Modernizacja i chmura oprogramowania przy użyciu metodologii i struktury migracji ARTIST”, Scalable Computing: Practice and Experience , 15 (2), doi : 10.12694/scpe.v15i2.980
  8. ^ Projekt badawczy ARTIST
  9. Bibliografia     _ Jane okup (2002). „Renesans: metoda wspierania ewolucji systemu oprogramowania” . 26. doroczna międzynarodowa konferencja dotycząca oprogramowania i aplikacji komputerowych . s. 415–420. CiteSeerX 10.1.1.137.7362 . doi : 10.1109/CMPSAC.2002.1045037 . ISBN 978-0-7695-1727-8 . S2CID 16563177 .
  10. Bibliografia _ Fatemeh „Mariam” Zahedi (2001). „Analiza zasad dotyczących gwarancji, konserwacji i aktualizacji systemów oprogramowania”. Journal of Software Maintenance: Research and Practice . 13 (6): 469–493. doi : 10.1002/smr.242 .
  11. Bibliografia _ Jarmo Ahonena; Heikki Lintinen; Henna Sivula; Tero Tilus. „Oszacowanie wartości biznesowej modernizacji oprogramowania” . {{ cite journal }} : Cite journal wymaga |journal= ( pomoc )
  12. Bibliografia    _ Morris, E.; Smith, D.; O'Brien, L. (2005). „Technika migracji i ponownego wykorzystania zorientowana na usługi (SMART)” . 13. międzynarodowe warsztaty IEEE dotyczące technologii oprogramowania i praktyki inżynierskiej (STEP'05) . s. 222–229. doi : 10.1109/step.2005.24 . hdl : 10344/2208 . ISBN 0-7695-2639-X . S2CID 18912663 .
  13. ^   Lewis, Grace A .; Plakosz, Daniel; Seacord, Robert C. (2003). Modernizacja starszych systemów: technologie oprogramowania, procesy inżynieryjne i praktyki biznesowe . Addison-Wesley Professional. s. 27–37. ISBN 0321118847 .
  14. Bibliografia _ „Szybka ścieżka do modernizacji oprogramowania | Mobilize.Net” . www.mobilize.net . Źródło 2021-03-19 .
  15. Bibliografia    _ Eugenio Pompella i Silvio Stefanucci (lipiec 2002). „Oszacowanie nakładu pracy związanego z naprawczą konserwacją oprogramowania” (PDF) . Materiały z 14. międzynarodowej konferencji Inżynieria oprogramowania i inżynieria wiedzy - SEKE '02 . SEKE '02 Ischia, Włochy. P. 409. doi : 10.1145/568760.568831 . ISBN 978-1581135565 . S2CID 10627249 . {{ cite book }} : CS1 maint: lokalizacja ( link )
  16. ^    De Lucia, A.; Fasolino, AR; Pompelle, E. (2001). „Ramy decyzyjne dla zarządzania starszymi systemami”. Proceedings Międzynarodowa konferencja IEEE na temat konserwacji oprogramowania. ICSM 2001 . s. 642–651. doi : 10.1109/ICSM.2001.972781 . ISBN 0-7695-1189-9 . S2CID 32184332 .
  17. Bibliografia   _ Lintinen, Heikki; Sivula, Henna; Tilus, Tero. „Ocena metod szacowania modernizacji oprogramowania przy użyciu NIMSAD Meta Framework” . Publikacje Instytutu Badań Informatycznych . CiteSeerX 10.1.1.106.2633 .
  18. ^ Santhosh G. Ramakrishna; VV (maj 2007). „Modernizacja dziedzictwa logistycznego” (PDF) . Infosys Technologies Limited.
  19. Bibliografia    _ „Wspieranie niezawodnej ewolucji” . W Gruhn, Volker; Striemer, Rüdiger (red.). Esencja inżynierii oprogramowania . s. 32–33. doi : 10.1007/978-3-319-73897-0 . ISBN 978-3-319-73897-0 . S2CID 49187426 .
  20. ^ „Modernizacja komputerów mainframe w pigułce” . Centrum modernizacji . Źródło 2017-08-23 .
  21. ^ Seria AS (ISO 9001:2008). Legacy Modernizacja – Transformacja w zwinne przedsiębiorstwo. Biała księga na temat starszej modernizacji
  22. ^ SzukajCIO.com
  23. ^ SK Mishra; DS Kushwaha; AK Misra (lipiec-sierpień 2009). „Tworzenie komponentu oprogramowania wielokrotnego użytku ze starszego systemu obiektowego poprzez inżynierię wsteczną” . Dziennik technologii obiektowej . 8 (5): 133–152. doi : 10.5381/jot.2009.8.5.a3 .
  24. ^ Moltke, H. v. (środa, 22 stycznia 2003 r., 21:55). Modernizacja zarządzana ryzykiem. Jawaharlal Nehru, Przemówienie do Parlamentu New Delhi,: Seacord.book.
Pobrano z „ https://en.wikipedia.org/w/index.php?title=Software_modernization&oldid=1131262228 ”