Inżynieria metodyczna - Method engineering
Inżynieria metod w „dziedzinie systemów informatycznych jest dyscypliną polegającą na konstruowaniu nowych metod z istniejących metod”. Skupia się na „projektowaniu, budowie i ocenie metod, technik i narzędzi wspomagających rozwój systemów informatycznych ”.
Ponadto inżynieria metod „chce poprawić użyteczność metod opracowywania systemów poprzez stworzenie ram adaptacyjnych, dzięki którym metody są tworzone w celu dopasowania do konkretnych sytuacji organizacyjnych”.
Rodzaje
Inżynieria metod komputerowych
Metamodelowanie-process proces jest często wspierany przez narzędzia programowe, zwana metoda technika wspomaganego komputerowo (CAME) narzędzia, ani narzędzi MetaCASE (meta-poziomie komputera Assisted narzędzi inżynierii oprogramowania). Często technika instancji „była wykorzystywana do budowania repozytorium środowisk inżynierii metod wspomaganych komputerowo”. Istnieje wiele narzędzi do modelowania metaprocesów.
Dostosowywanie metod
W literaturze różne terminy odnoszą się do pojęcia adaptacji metody, w tym „dopasowywanie metody”, „adaptacja fragmentów metody” i „sytuacyjna inżynieria metod”. Dostosowywanie metod definiuje się jako:
Proces lub zdolność, w której ludzie poprzez reagujące zmiany i dynamiczne interakcje między kontekstami, intencjami i fragmentami metod określają podejście do rozwoju systemu dla konkretnej sytuacji projektowej.
Potencjalnie prawie wszystkie metody zwinne nadają się do dostosowywania metod. W tym celu wykorzystywana jest nawet metoda DSDM, która została z powodzeniem dostosowana w kontekście maszyn współrzędnościowych . Adekwatność sytuacyjna może być uznana za cechę odróżniającą metody zwinne od tradycyjnych metod tworzenia oprogramowania, przy czym te ostatnie są stosunkowo bardziej sztywne i nakazowe. Praktyczne implikacje są takie, że metody zwinne pozwalają zespołom projektowym dostosowywać praktyki pracy do potrzeb poszczególnych projektów. Praktyki to konkretne działania i produkty, które są częścią ram metodycznych. Na bardziej ekstremalnym poziomie można by dostosować filozofię metody, składającą się z szeregu zasad .
Inżynieria metod sytuacyjnych
Inżynieria metod sytuacyjnych to tworzenie metod dostosowanych do konkretnych sytuacji projektów deweloperskich. Można to opisać jako stworzenie nowej metody wg
- wybranie odpowiednich komponentów metody z repozytorium komponentów metod wielokrotnego użytku,
- odpowiednie dostosowanie tych składników metody, oraz
- integrację tych dostosowanych komponentów metody w celu utworzenia nowej metody dostosowanej do sytuacji.
Umożliwia to tworzenie metod rozwoju odpowiednich dla każdej sytuacji rozwojowej. Każdy rozwój systemu rozpoczyna się wtedy od fazy definiowania metody, w której metoda opracowywania jest konstruowana na miejscu.
W przypadku rozwoju biznesu mobilnego dostępne są metody dla określonych części procesu projektowania modelu biznesowego i rozwoju technologii informacyjno-komunikacyjnych. Inżynieria metod sytuacyjnych może być wykorzystana do połączenia tych metod w jedną ujednoliconą metodę, która przyjmuje cechy mobilnych usług ICT.
Proces inżynierii metody
Twórcy języków modelowania IDEF , Richard J. Mayer i in. (1995), opracowali wczesne podejście do inżynierii metod na podstawie analizy powszechnych praktyk inżynierskich metod i doświadczenia w opracowywaniu innych metod analizy i projektowania . Poniższy rysunek przedstawia podejście zorientowane na proces. Ten obraz wykorzystuje metodę przechwytywania opisu procesu IDEF3, aby opisać ten proces, w którym ramki z wyrażeniami czasownikowymi reprezentują działania, strzałki reprezentują relacje pierwszeństwa, a warunki „wyłączność lub” wśród możliwych ścieżek są reprezentowane przez pola połączeniowe oznaczone znakiem „X”.
Zgodnie z tym podejściem istnieją trzy podstawowe strategie w inżynierii metod:
- Ponowne użycie : jedną z podstawowych strategii inżynierii metod jest ponowne wykorzystanie. Tam, gdzie to możliwe, przyjmuje się istniejące metody.
- Dostosowane : znajdź metody, które mogą zaspokoić zidentyfikowane potrzeby po niewielkich modyfikacjach. Ta opcja jest atrakcyjna, jeśli modyfikacja nie wymaga fundamentalnej zmiany podstawowych pojęć lub celów projektowych metody.
- Nowy rozwój : projektanci metod powinni dążyć do opracowania nowej metody tylko wtedy, gdy żadna z tych opcji nie jest wykonalna.
Te podstawowe strategie można opracować w podobnym procesie tworzenia koncepcji
Podejście do inżynierii wiedzy
Inżynieria wiedzy podejście jest dominującym mechanizmem poprawy sposobu i rozwoju nowych metod. Innymi słowy, z nielicznymi wyjątkami, opracowanie metody obejmuje wyodrębnienie, udokumentowanie i opakowanie istniejących praktyk dla danego zadania w formie, która promuje wiarygodny sukces wśród praktyków. Nastroje eksperckie są najpierw scharakteryzowane w postaci podstawowych intuicji i koncepcji metod. Są one często początkowo identyfikowane poprzez analizę technik, diagramów i wyrażeń używanych przez ekspertów. Te odkrycia pomagają w poszukiwaniu istniejących metod, które można wykorzystać do wspierania początkujących praktyków w zdobywaniu tych samych umiejętności i umiejętności.
Rozwój nowej metody odbywa się poprzez ustalenie zakresu metody, dopracowanie charakterystyki koncepcji i intuicji metody, zaprojektowanie procedury, która zapewnia zarówno wykonanie zadań, jak i podstawowe wsparcie praktyk zawodowych dla początkujących praktyków, a także rozwój języka (-ów) wypowiedzi. Następnie opracowywane są techniki stosowania metod, określające wytyczne do stosowania w trybie samodzielnym oraz w połączeniu z innymi metodami. Każdy element metody jest następnie wielokrotnie udoskonalany poprzez testy laboratoryjne i terenowe.
Proces projektowania języka metod
Proces projektowania języka metody ma charakter wysoce iteracyjny i eksperymentalny. W przeciwieństwie do tworzenia procedur, w których zestaw heurystyk i technik z istniejącej praktyki można zidentyfikować, połączyć i udoskonalić, projektanci języków rzadko mają do czynienia z dobrze rozwiniętymi mechanizmami wyświetlania graficznego lub przechwytywania informacji tekstowych. Kiedy można znaleźć struktury językowe, które mogą być ponownie użyte, są one często słabo zdefiniowane lub tylko częściowo dostosowane do potrzeb metody.
Krytycznym czynnikiem w projektowaniu języka metody jest jasne ustalenie celu i zakresu metody. Cel metody określa potrzeby, które metoda musi zaspokoić. Służy do określenia siły ekspresji wymaganej od języka pomocniczego. Zakres metody określa zakres i głębokość pokrycia, które również muszą zostać ustalone, zanim będzie można zaprojektować odpowiednią strategię projektowania języka. Określenie zakresu wiąże się również z podjęciem decyzji, jakie czynności poznawcze będą wspierane poprzez zastosowanie metody. Na przykład, projektowanie języka można ograniczyć do wyświetlania tylko końcowych wyników zastosowania metody (jak w przypadku dostarczania IDEF9 z graficznymi i tekstowymi udogodnieniami językowymi, które przechwytują logikę i strukturę ograniczeń). Alternatywnie może zaistnieć potrzeba wsparcia językowego w trakcie procesu, ułatwiającego gromadzenie i analizę informacji. W takich sytuacjach można zaprojektować określone konstrukcje językowe, aby pomóc praktykom metod organizować, klasyfikować i przedstawiać informacje, które później zostaną zsyntetyzowane w dodatkowe struktury reprezentacji przeznaczone do wyświetlenia.
Na tej podstawie projektanci języka rozpoczynają proces decydowania o tym, co należy wyrazić w języku i jak należy to wyrazić. Projektowanie języka można rozpocząć od opracowania języka tekstowego, który jest w stanie przedstawić pełen zakres informacji, którymi należy się zająć. Następnie można opracować graficzne struktury językowe zaprojektowane do wyświetlania wybranych fragmentów języka tekstowego. Alternatywnie, graficzne struktury języka mogą ewoluować przed rozwojem języka tekstowego lub równolegle z nim. Kolejność tych czynności w dużej mierze zależy od stopnia zrozumienia wymagań językowych, jakie posiadają twórcy języków. Mogą one stać się jasne dopiero po kilku iteracjach projektowania języka graficznego i tekstowego.
Graficzny projekt języka
Projekt języka graficznego rozpoczyna się od zidentyfikowania wstępnego zestawu schematów oraz celu lub celów każdego z nich pod względem tego, gdzie i jak będą one wspierać proces stosowania metody. Centralny element zainteresowania jest określany dla każdego schematu. Na przykład, eksperymentując z alternatywnymi projektami języka graficznego dla IDEF9, przewidziano schemat kontekstu jako mechanizm klasyfikowania różnych kontekstów środowiskowych, w których mogą obowiązywać ograniczenia. Centralnym punktem tego schematu był kontekst. Po podjęciu decyzji o centralnym punkcie zainteresowania schematu, identyfikowane są dodatkowe informacje (pojęcia i relacje), które należy uchwycić lub przekazać.
Do tego momentu w procesie projektowania języka główny nacisk położono na informacje, które powinny być wyświetlane na danym schemacie, aby osiągnąć cele schematu. W tym miejscu projektant języka musi określić, które elementy zidentyfikowane do ewentualnego włączenia do schematu nadają się do reprezentacji graficznej i będą służyły utrzymaniu koncentracji użytkownika na pożądanej treści informacyjnej. Z tym ogólnym zrozumieniem bada się wcześniej opracowane graficzne struktury językowe, aby zidentyfikować potencjalne możliwości ponownego wykorzystania. Badając potencjalne projekty języków graficznych dla nowych metod IDEF, zidentyfikowano i zbadano szeroką gamę diagramów. Dość często nawet niektóre z głównych koncepcji metody nie zawierają graficznego elementu języka w metodzie.
Na przykład metoda modelowania informacji IDEF1 obejmuje pojęcie bytu, ale nie ma elementu składniowego dla encji w języku graficznym. Gdy projektant języka zdecyduje, że element składniowy powinien zostać uwzględniony w koncepcji metody, projektowane i oceniane są symbole kandydatów. W całym procesie projektowania języka graficznego projektant języka stosuje szereg zasad przewodnich, aby pomóc w tworzeniu projektów wysokiej jakości. Wśród nich projektant języka unika nakładających się klas pojęć lub słabo zdefiniowanych. Starają się również ustanowić intuicyjne mechanizmy, które wskażą kierunek czytania schematów.
Na przykład schematy mogą być zaprojektowane do czytania od lewej do prawej, w sposób oddolny lub centralnie na zewnątrz. Potencjał bałaganu lub przytłaczająco dużej ilości informacji na pojedynczym schemacie jest również brany pod uwagę, ponieważ każdy z tych warunków sprawia, że czytanie i zrozumienie schematu jest niezwykle trudne.
Testowanie metod
Każdy proponowany projekt jest następnie testowany poprzez opracowanie szerokiej gamy przykładów w celu zbadania użyteczności projektów w odniesieniu do celu każdego schematu. Początkowe próby opracowania metody, aw szczególności opracowania wspierających struktur językowych, są zwykle skomplikowane. Wraz z kolejnymi iteracjami projektu eliminowane są niepotrzebne i złożone struktury językowe.
Gdy projekt języka graficznego zbliża się do poziomu dojrzałości, uwaga zwraca się na język tekstowy. Cele, którym służą języki tekstowe, sięgają od zapewnienia mechanizmu do wyrażania informacji, które zostały wyraźnie pominięte w języku graficznym, po zapewnienie mechanizmu standardowej wymiany danych i automatycznej interpretacji modelu. Zatem język tekstowy wspierający metodę może być prosty i nieustrukturyzowany (pod względem komputerowej interpretacji) lub może wyłonić się jako wysoce ustrukturyzowany i złożony język. Cel metody w dużej mierze determinuje, jaki poziom struktury będzie wymagany od języka tekstowego.
Techniki formalizacji i aplikacji
Gdy język metody zaczyna zbliżać się do dojrzałości, stosuje się matematyczne techniki formalizacji, aby nowy język miał jasną składnię i semantykę. Proces formalizacji metod często pomaga odkryć niejednoznaczności, zidentyfikować niewygodne struktury językowe i usprawnić język.
Kulminacją tych ogólnych działań jest język, który pomaga skupić uwagę użytkownika na informacjach, które muszą zostać odkryte, przeanalizowane, przekształcone lub przekazane w trakcie wykonywania zadania, dla którego metoda została zaprojektowana. Zarówno procedura, jak i komponenty językowe metody pomagają również użytkownikom w rozwijaniu niezbędnych umiejętności i nastawień potrzebnych do uzyskiwania niezmiennie wysokiej jakości wyników w zamierzonym zadaniu.
Po opracowaniu metody zostaną zaprojektowane techniki aplikacyjne, które pozwolą z powodzeniem zastosować ją w trybie samodzielnym, jak również razem z innymi metodami. Techniki aplikacji stanowią element „użytkowy” metody, który ewoluuje i rozwija się przez cały okres użytkowania metody. Procedura metody, konstrukcje językowe i techniki aplikacji są przeglądane i testowane w celu iteracyjnego udoskonalenia metody.
Zobacz też
Bibliografia
- Atrybucja
Ten artykuł zawiera tekst z US Air Force , Information Integration for Concurrent Engineering (IICE), raport z kompendium metod autorstwa Richarda J. Mayera i in., 1995, publikacja będąca obecnie w domenie publicznej.
Dalsza lektura
- Sjaak Brinkkemper , Kalle Lyytinen, Richard J. Welke (1996). Inżynieria metod: zasady konstrukcji metod i wsparcie narzędziowe: materiały z IFIP TC8, WG8.1 / 8.2 Working Conference on Method Engineering 26–28 sierpnia 1996, Atlanta, USA . Skoczek. ISBN 041279750X doi : 10.1007 / 978-0-387-35080-6
- Sjaak Brinkkemper , Saeki i Harmsen (1998). Techniki montażowe w inżynierii metod. Zaawansowana inżynieria systemów informatycznych, materiały z CaiSE'98 . Nowy Jork: Springer. doi : 10.1007 / BFb0054236
- Ajantha Dahanayake (2001). Inżynieria metodyczna wspomagana komputerowo: projektowanie repozytoriów CASE na miarę XXI wieku . Hershey, PA: Idea Group Inc (IGI), 2001. ISBN 1878289942
- Brian Henderson-Sellers , Jolita Ralyté, Pär J. Ågerfalk i Matti Rossi (2014). Inżynieria metod sytuacyjnych . Berlin: Springer. ISBN 9783642414664 doi : 10.1007 / 978-3-642-41467-1
- Brian Henderson-Sellers , Jolita Ralyté i Sjaak Brinkkemper , wyd. (2008). Inżynieria metod sytuacyjnych: podstawy i doświadczenia: obrady konferencji roboczej IFIP WG 8.1, 12–14 września 2007 r., Genewa, Szwajcaria . Nowy Jork: Springer. ISBN 0387739467 doi : 10.1007 / 978-0-387-73947-2
- Brian Henderson-Sellers , C. Gonzalez-Perez i Donald Firesmith (2004) Inżynieria metod i ocena COTS w: ACM SIGSOFT Software Engineering Notes archiwum . Tom 30, wydanie 4 (lipiec 2005).
- Manfred A. Jeusfeld, Matthias Jarke i John Mylopoulos , wyd. (2009). Metamodeling w inżynierii metod . Cambridge, MA: MIT Press. ISBN 0262101084
Zewnętrzne linki
- Prezentacja dotycząca metamodelingu i inżynierii metod autorstwa Minny Koskinen, 2000.
