CDM, cz1


CZĘŚĆ I

PRZEGLĄD

W tym rozdziale przedstawiony zostanie skład i struktura metody wytwarzania systemu na zlecenie klienta (na żądanie klienta) tzw. Metody CDM.

    1. Co to jest CDM

Metoda Oracle wytwarzania systemu na żądanie klienta adresuje funkcje przedsiębiorstwa i procesy, które nie mogą być rozwiązane przez aplikacje off-the self. CDM jest zbiorem dobrze zdefiniowanych procesów wytwarzania systemu na żądanie klienta, które mogą być kierowane różnymi drogami do prowadzenia ciebie przez projekt wytwarzania systemu na żądanie klienta.

CDM projekt definiuje jak wszystkie wewnętrzne, zewnętrzne i w czasowe zdarzenia przedsiębiorstwa są trzymana i wiążą każde zdarzenie z wymaganymi procesami przedsiębiorstwa i systemu. W ten sposób, społeczność przedsiębiorstwa określa stosowny (odpowiedni) zakres wymagań przedsiębiorstwa po to, aby otrzymać ostateczny system.

CDM, odnajdywane w podejściu metod Case, zapewnia, że potrzeby przedsiębiorstwa są jasno zdefiniowane w zewnętrznym zbiorze i pozostają widoczne na zewnątrz procesu rozwoju.

CDM gwałtownie zwiększa twoją sposobność zakończenia implementacji przez dostarczenie celu, aplikacji klienta, która obsługuje długo-terminowe potrzeby przedsiębiorstwa.

Chociaż, było to rozwijane w średniego i dużego rozmiaru projektach, CDM jest bezpośrednio dający się zastosować w mniejszych projektach również. Także, podczas CDM jest bardziej efektywne w projektach które używają technologii relacyjnych bazach danych Oracle i repozytorium Designer/2000 Case, Klasyczne i Dosłowne podejścia mogą być dostarczone używając innych technologii, z pewnymi mniejszymi zmianami w technice.

Podobnie jak inne metody Oracle, CDM wyprowadza zadania i rozwiązania, które powinny być zawarte w pełnym cyklu rozwoju projektu. Każde zadania w CDM ma obiekty generujące pojedyncze rozwiązania. CDM przydziela zadania do procesów opartych na powszechnych techniki, umiejętności lub zależności.

Zadania wewnątrz tych procesów są wtedy przydzielane do fazy, opartej na wyselekcjonowanym podejściu rozwoju. Koniec fazy odzwierciedla kompletny główny zbiór obiektów i kamienie milowe w wysiłku wytwarzania systemu na żądanie klienta.

Podejście Oracle CDM jasno definiuje naturę zależności tych rozwiązań. Każde zadanie zaczyna się od przedstawienia wstępnych warunków, które muszą być dostępne przed rozpoczęciem pracy. Te wstępne warunki musiały być kompletne i w inny sposób dostarczone inne różne. Zależność opisów pozwala zarządzać projektem tak aby poznać powrotny strumień implikacji zawierającego rozwiązanie podczas programowania.

    1. Proces w CDM

Organizacja CDM jest wyrażona przez metodologię podstawowego procesu wytwarzania systemów.

Proces jest kohezyjnym zbiorem lub wątkiem powiązanych zadań, które kieruj ą do specyficznego obiektu projektu. Rezultaty (wyniki) procesu w jednym lub więcej kluczowych rozwiązań. Każdy proces jest dyscypliną, która zwykle pociąga za sobą podobne zdolności spełnić zadania wewnątrz procesu. Możesz myśleć o procesie jako o ciągłym podprojekcie wewnątrz dużego projektu wytwarzania systemu.

Każdy pełny cykl życia projekty wytwarzania systemu na żądanie klienta pociągaj ą za sobą większość jeśli nie wszystkie następujące procesy, czy one są zespołu wytwarzania systemu, użytkowników, SI personelu, trzeciej części lub kombinacją. Większość procesów nachodzi na siebie w czasie z innymi i są wewnętrznie powiązane przez wspólne cele. Kilka procesów (mało, niewiele) jest dokładnymi poprzednikami każdego innego procesu, takich jak Wdrażania i Asysta po wdrożeniu.

Ten podrozdział opisuje następujące procesy:

Definicja wymagań przedsiębiorstwa

Proces definicji wymagań definiuje potrzeby przedsiębiorstwa aplikacji systemu. Zespół analityków najpierw buduje model procesów organizacji, który identyfikuje wszystkie zdarzenia organizacji i podsekwencje odpowiedzi, które aplikacji musi utrzymywać. Zespół analityków wtedy dodaje wymagania technologiczne do modeli takich jak: interfejs użytkownika, czas reakcji, etc. W ten sposób, analitycy przekształcają modele wymagane przedsiębiorstwa w modele wymagane systemu.

Analiza istniejących systemów

Znaczącym wymaganiem w wielu projektach wytwarzania systemów na żądanie klienta jest zastąpienie funkcjonalności istniejącego systemu lub działać z istniejącą architekturą techniczną. Proces analizy istniejących systemów prowadzi do zidentyfikowania tych potrzeb.

Wiele zadań w tym procesie może być wyeliminowanych jeśli projekt nie jest funkcjonalnym odzwierciedleniem istniejącego systemu. Proces może być pominięty jeśli istnieje aktualna dokumentacja szczegółów funkcjonalnych i technicznych.

Architektura techniczna

Proces technicznej architektury specyfiku] e elementy technicznej podstawy wytwarzanego projektu. Przyjmuje się, że strategia dużego systemu informatycznego już istnieje i że te elementy dostosowują się wewnątrz tej strategii.

Rozpoczynając z planem wstępnego rozmiaru (pojemności) analitycy rozwijaj ą wstępną techniczną architekturę. Gdy więcej szczegółowych informacji jest dostępnych zespół analityków przekształci te cele w dwóch częściach: definicji podstawy oprogramowania i sprzętu i podziału architektury.

Dostarcza strategie dla bezpieczeństwa i kontroli, interfejsu użytkownika i zapasu oraz odzysk. Jednym z ostatnich celów tego procesu jest końcowy plan pojemności systemu, który może być użyty jako wejście aby mieć wymiar zakończonej aplikacji systemu.

Projekt i budowa bazy danych

W procesie tym zaczyna się od stworzenia projektu logicznej bazy danych z modelu danych systemu, i kończy stworzeniem bazy danych DDL. Proces projektowania i budowania relacyjnej bazy danych zawiera określający indeks projektu i schemat dla implementowanego obiektu bezpieczeństwa bazy danych. Fizyczna baza danych używa obu planu pojemności i dystrybucji architektury dostarczanej jako zasadnicze wejścia.

Projekt i budowa modułu

Proces ten jest sercem projektu CDM. Projektanci używają modelu procesów, modelu danych i modelu funkcji systemu wzdłuż z architekturą techniczną, w pierwszej fazie projektują architekturę systemu i moduł modelu procesów i wtedy specyfiku)ą szczegóły funkcjonalne i techniczne każdego modułu.

Programiści wtedy używaj ą dokumentacji i/lub prototypów do konstrukcji kodu aplikacji.

Proces ma relatywnie postawione kilka dużych zadań. Zarządzanie i kontrola strategii tego procesu może różnić się mocno, zależeć od podejścia projektu. Na przykład, w wysoko interaktywnych podejściach wytwarzania sytemu, możesz duplikować proces wejściowy dla każdego funkcjonalnego obszaru lub budowy. Bardzo złożona aplikacji może wymagać całej dokumentacji projektu po to, aby być kompletną i zatwierdzoną przed wykonaniem aktualnego programowania.

Konwersja danych

Celem procesu konwersji danych jest konwersja i testowanie poprawności wszystkich danych, które są potrzebne do testowania i do operacji nowej aplikacji. Pierwszym krokiem tego procesu jest jasno zdefiniować daną, które należy poddać konwersji, wzdłuż jej źródła. Dana może być potrzebna testowania systemu, testowania integracji systemu, szkolenia i zatwierdzenia testowania równie dobrze jak wdrażanie.

Następujące jest to, że zespół projektu określa całokształt strategii po to, aby zidentyfikować wymagania, zawierając obie metody automatyczna i ręczna. Proces zawiera projektowanie, kodowanie i testowanie konwersji modułów, które są potrzebne i, oczywiście, spełniając wszystkie własne konwersje.

Dokumentacja

Proces ten jest ukierunkowany na wytworzenie wysokiej jakości tekstowych rozwiązań. Na tym poziomie wytwarzania sytemu otrzymujemy całą dokumentację użytkownika, techniczną i szkolenia projektu.

Dwa zasadnicze typy dokumentacji zorientowane na użytkownika to Przewodnik Użytkownika i Referencja Użytkownika. Pierwszy typ jest podstawą modelu modułu procesu i dąży do kierowania rolą każdego użytkownika w użyciu aplikacji aby wykonać procesy przedsiębiorstwa. Drugi typ jest referencją przewodnika, która identyfikuje (dokładnie określa) funkcjonalność każdego modułu aplikacji.

Testowanie

Proces ten jest zintegrowanym podejściem testowania jakości wszystkich elementów aplikacji systemu. Zawiera w sobie testowanie modułu zorientowanego funkcjonalnie i scalenia modułu zorientowanego na ekonomię przedsiębiorstwa, system, scalenie systemów i zaakceptowanego testowania. Testowanie zorientowane na ekonomię organizacji jest prowadzone przez model procesów, aby ustalić mocną, trwałą ścieżkę powrotną wymagań przedsiębiorstwa. Proces testowania podkreśla z naciskiem podejście programowania wspólnego do wszystkich typów testowania. Podtrzymuje ponowne użycie skryptów testowania, aby przeprowadzić test zakończony sukcesem dużych i większych części aplikacji systemu.

Szkolenie

Celem procesu szkolenia jest przeszkolenie przyszłych użytkownikowi administratorów do wykonywania zadań uruchamiania aplikacji systemu. Zespół projektu może także przeszkolić przyszły personel i zaakceptowany zespół testowania.

Wdrażanie

Proces wdrażania zaczyna we wczesnej fazie projektu przez definiowanie swoistych wymagań dla dopasowania do nowej aplikacji systemu. Zawiera wtedy zadania, aby wykonać elementy strategii takie jak wytworzenie planu instalacji, przygotowanie środowiska produkcji, dokonanie dopasowania., i zapobieganie spadkom wydajności pracy systemów.

Asysta po wdrożeniu

Cztery cele powyższego procesu to monitorować i odpowiadać na problemy systemu przez pomoc na pulpicie, aktualizować aplikacje po to, aby naprawiać błędy i wykrywać problemy, ewoluować system w produkcji i planować rozszerzenie systemu.

    1. Podejścia CDM

Używając fundamentu podstawowego procesu CDM, można określić podejście wytwarzania systemu, które ma rację bytu w waszym projekcie. Metody są wprowadzane i dokumentowane przez stopniowe działanie. Działanie stopniowe jest użyteczną i potrzebną koncepcją dla zarządzania projektanta, ale może spowodować niepotrzebne koszty i nieefektywności w projekcie, jeśli tylko model fazowania jest dostępny dla wszystkich rozmiarów i typów projektów. Zadania i rozwiązania CDM były skonstruowane na podstawie nisko umiejscowionych zależności między zadaniami, bez sztucznych punktów hamujących lub działając stopniowo wewnątrz procesu. Założenie procesu udowadnia dowodzi pożyteczność mniejsza o to, który model stopniowego działania wybrałeś dla projektu.

Ponieważ projekty tworzone przez ludzi o różnych umiejętnościach zdolnych do wypełniania (spełniania) wyselekcjonowanych zadań, może być trudne do skoordynowania zakończenia działania stopniowego podczas bilansowania wszystkich w zespole. Procesy CDM są udokumentowane niezależnością działania stopniowego, a więc członkowie zespołu mogą zobaczyć następne zadania, które wymagają wykonania i mogą zacząć te zadania, jeśli wskazał podczas robienia końcowych raportów fazy działania stopniowego i zaakceptowane zadania są spełnione(wykonane).

Podręczna metoda CDM omawia trzy główne modele działania stopniowego projektu. Poniżej są przedstawione trzy podejścia wyżej wskazane:

  1. Klasyczne

  2. Szybka ścieżka

  3. Lite

Następne akapity w tym rozdziale wyjaśniają każde z podejść CDM przez podsumowanie(streszczenie) faz podejścia. Dla porównania informacji pomiędzy podejściami i wyboru kryteria, które może pomóc wyznaczyć najlepsze podejście dla twojego projektu, odsyłam do rozdziału 3 -„Wyznaczanie podejścia projektowego”.

      1. Podejście klasyczne

Preferowanym podejściem w dużych projektach wytwarzania systemu na żądanie klienta jest podejście klasyczne CDM. Podejście klasyczne CDM składa się z sześciu faz, które zostaną omówione poniżej.

Część II podręcznika jest dedykowana dokumentowaniu klasycznego podejścia CDM. Poniżej znajduje się krótki opis faz klasycznego podejścia:

Definicja

Celem fazy definicji jest określenie wysokiego poziomu wymagań przedsiębiorstwa i systemu informacyjnego potrzebnych do zidentyfikowania zbioru obiektów przedsiębiorstwa. Faza definicji kończy się jasnym i wykonalnym zakresem projektu. Ostateczny cel fazy definicji jest otrzymanie aprobaty zarządu rozpoczęcie fazy analizy.

Analiza

Celem fazy analizy jest sformułowanie szczegółowych wymagań dla komputera aplikacji systemu. Faza analizy bada obszar przedsiębiorstwa poprzednio zdefiniowane przez fazę definicji. Członkowie zespołu analityków osiągają całkowite zrozumienie obszaru przedsiębiorstwa przez stworzenie dokładnego zbioru modeli i opisów tego, co obszar przedsiębiorstwa robi i informacji, które używa(wykorzystuje). Wtedy przekształca je w modele specyfikujące szczegółowe wymagania dla komputerowej aplikacji systemu , definiuje architekturę techniczną, aby uruchomić ten system i proponuje strategię dla wdrażania do tego systemu z jakiegoś innego bieżących systemów.

Projekt

Celem tej fazy jest zebranie wymagań z fazy analizy i przetłumaczenie ich na specyfikacje uszczegółowionego systemu, biorąc pod uwagę architekturę techniczną i dostępną technologię.

Budowa

Celem fazy budowy jest zakodowanie i przetestowanie aplikacji, używając odpowiednich technik. Techniki zależą od typu źródła modułów wciągniętych, ale może szeregować od konwencjonalnego wytwarzania do serii szybkiego budowania używając przyrostowego, wzrostowego wytwarzanie systemu.

Wdrażanie

Celem fazy wdrażania jest instalacja nowej aplikacji systemu, przygotowanie personelu klienta do korzystania z aplikacji i administratora aplikacji systemu i wtedy wprowadzić do produkcji. Zespół wdrożeniowy wykonuje instalację, szkoli personel, utrzymuje zaakceptowane testy i wprowadza aplikację systemu do produkcji. Wdrażanie nie powinno generować nowej dokumentacji lub kodu, ale zamiast tego być fazą, w której istniejący kod, dokumentacja i dana są wprowadzana do użycia.

Produkcja

Celem fazy produkcji jest dostarczenie aplikacji pomocy, monitora aplikacji, zapewnić równe uruchamianie aplikacji i plan dla przyszłego funkcjonalnego rozszerzenia (powiększenia) aplikacji systemu.

      1. Szybka ścieżka tworzenia /The Fast Track Approach/

Zalecanym sposobem uzyskania działającej aplikacji przy projektowaniu średnich systemów jest CDM Fast Track approach. Składa się on z trzech etapów, przedstawionych poniżej:

Rysunek 1-4 CDM Fast Track Approach

Część trzecia tej instrukcji użytkownika jest poświęcona pełnemu przedstawieniu CDM Fast Track Approach. Poniżej znajduje się krótki opis poszczególnych etapów:

Modelowanie wymagań

Celem tego etapu jest dostarczenie wystarczającej ilości informacji do szybkiego stworzenia szkieletu systemu, zgodnego z oczekiwaniami użytkownika co do tego, co system ma robić oraz osiągnięcie tego w jak najkrótszym czasie. Podczas etapu modelowania wymagań należy określić plan szkolenia, testowania, konwersji danych, sporządzania dokumentacji i wdrażania.

Projektowanie i Generowanie Systemu

Celem tego etapu jest szybkie zbudowanie działającej aplikacji na podstawie opartego na repozytorium kodu z generatora. Użycie generatora kodu do stworzenia prototypu projektu pozwala nie tylko osiągnąć wysoką wydajność ale również gwarantuje, że udokumentowane wymagania będą miały swoje odbicie w prototypie, a zmiany w prototypie znajdą odbicie w wymaganiach.

Wdrażanie do produkcji

Celem tego etapu jest zainstalowanie nowego systemu, przeszkolenie personelu w zakresie użytkowania i administrowania systemem oraz rozpoczęcie produkcji. W czasie, gdy system jest wytwarzany, należy monitorować prace aplikacji, dbać o bezawaryjne działanie oraz obmyślać, jakby ją funkcjonalnie wzbogacić.

      1. The Lite Approach

Zalecanym sposobem posterowania przy projektowaniu małych systemów jest CDM Lite Approach. Składa się z dwóch etapów przedstawionych poniżej:

Rysunek 1-5 CDM Lite Approach

The Lite Approach nie jest w pełni omówiony w tym podręczniku. Poniżej znajduje się krótki opis etapów, z jakich się składa:

Prototyp i budowa

Celem tego etapu jest szybkie zbudowanie aplikacji. W tradycyjnym projekcie ta faza koncentruje się raczej na określeniu tego, co wymaga się, by system robił, a nie na określeniu, jak ma to robić, co jest przesunięte do fazy projektowania. W Lite Approach takie rozdzielenie nie jest widoczne, ponieważ niekiedy najlepszym sposobem upewnienia się, czy wszystko właściwie się rozumie, jest pokazanie użytkownikowi, czy takie rozwiązanie zaspokaja jego oczekiwania.

To podejście zakłada, że twoim celem jest stworzenie nowego systemu, a nie modyfikacja istniejącego.

Wdrażanie do produkcji

Celem tego etapu jest zainstalowanie nowego systemu, przeszkolenie personelu w zakresie użytkowania i administrowania systemem oraz rozpoczęcie produkcji. W czasie, gdy system jest wytwarzany, należy monitorować prace aplikacji oraz ustalać przyszłe udoskonalanie systemu.

    1. Oszacowanie przeciętnego projektu

Zanim rozpocznie się tworzenie projektu pojawiają się pytania: „Ile to będzie kosztować?” i „Kiedy system będzie gotowy?” Jedynymi możliwymi odpowiedziami są oszacowania.

Najbardziej niezawodną metoda oszacowania jest liczenie od dołu w górę. Może być ono przeprowadzone tylko po stworzeniu struktury projektu, która zawiera wszystkie przewidziane do wykonania zadania wraz z podziałem ról przy realizacji tych zadań i określony procentowy udział zadań na poszczególnych etapach. Zadania i planowane role dostarczają potem infrastruktury dla dokumentacji estymowanych czynników, które oddziałuj ą na każde zadanie. Szacowane czynniki są później sekwencyjnie używane w formułach szacowanych dla każdego zadania, a to z kolei może być użyte w wyliczeniu oszacowania całego projektu. Tabela poniżej podsumowuje doświadczenia firmy Oracle przy tworzeniu średniej wielkości projektu. Ten „Procentowy udział poszczególnych procesów w całym projekcie” przedstawia rezultat szacowania modelem od dołu w górę. Każda komórka reprezentuje procentowy udział wysiłku wkładanego na wykonanie zadania na danym etapie w całościowym wysiłku przy realizacji projektu. Suma wartości w kolumnach przedstawia udział poszczególnych etapów tworzenia projektu w całości przedsięwzięcia, natomiast suma wartości z wierszy przedstawia całkowity udział poszczególnych procesów (zadań). Na przykład na podstawie tabeli okazuje się, że najbardziej absorbującym wysiłek etapem jest budowa, natomiast Projektowanie i Implementacja Modułów (Module Design and Bulid) najbardziej absorbującym procesem.

PROCES

Strategia

Analiza

Projektowanie

Budowa

Wdrażanie

Produkcja

Suma

Określanie wymagań

2,9%

5,6%

8%

Badanie systemu istniejącego

1%

1,6%

3%

Architektura Techniczna

0,3%

1,5%

0,3%

2%

Projektowanie i budowa BD

0,9%

0,4%

1%

Projektowanie i budowa modułów

17,5%

19,8%

37%

Konwersja danych

0,4%

1,2%

1,8%

3,2%

0,7%

7%

Dokumentacja

0,1%

0,1%

2,2%

1,8%

4%

Testowanie

0,1%

1,8%

13,6%

0,8%

16%

Szkolenie

0,3%

0,4%

0,6%

0,6%

2%

Wdrażanie

0,1%

0,1%

0,2%

0,5%

1%

Serwis

3,4%

3%

Zarządzanie projektem

0,8%

1,7%

4,1%

6,6%

0,4%

0,6%

14%

Suma

6%

12%

29%

46%

3%

4%

100%

Tabela 1-1 Procentowy udział poszczególnych procesów w całości projektu

Tabela 1-2 przedstawia dane uzyskane w firmie Oracle dla średnich projektów, ale pokazuje jaką część czasu zajmują kolejne procesy w poszczególnych etapach tworzenia projektu. Każda komórka tej tabeli prezentuje jaką część na poszczególnych etapach tworzenia projektu zajmuje dany proces. Suma wartości w każdej kolumnie zawsze wynosi 100%, a komórki na przecięciu poszczególnych wierszy i ostatniej kolumny przedstawiaj ą udział poszczególnych procesów w całości projektu. Na przykład tabela informuje, że na etapie Projektowania najwięcej wysiłku pochłania proces Projektowania i Tworzenia Modułów.

Ten rozdział opisuje podstawowe założenia, na których opiera się Metodyka Wytwarzania Aplikacji na Zamówienie Klienta (Gustom Development Method). Podzielony jest na następujące części:

W typowym podejściu inżynierskim do tworzenia aplikacji, aplikacja reprezentowana jest przez j ej biznesowe, logiczne i fizyczne charakterystyki lub warstwy. Poniższy przegląd wykorzystuje warstwy te dla uwidocznienia rdzenia ścieżki rozwojowej lub podejścia głównonurtowego dla rozwoju systemu aplikacyjnego.

„Custom Development Metod” (CDM) rozpoczyna się i kończy wraz z przyporządkowaniem jej do biznesu.

Przy rozpoczęciu projektu CDM duży nacisk kładzie się na rozumienie biznesu. Członkowie zespołu analizują firmę w kontekście obszaru biznesowego projektu wewnątrz warstwy biznesowej aplikacji. Analitycy używaj ą modelowania projektowego jako podstawowej techniki w tej warstwie ze względu na próby zrozumienia, w jaki sposób firma oddziałuje z funkcjonowaniem dokumentów w kontekście przepływów procesów biznesowych. Warstwa biznesowa dostarcza modelu biznesowego, który składa się z procesów, funkcji i modeli danych.

Po zakończeniu badania i modelowania firmy, używaj ą tych informacji w celu rozwoju reprezentacji logicznej biznesu. Praca zakończona w warstwie logicznej uwydatnia silne powtórne użycia modeli biznesowych i dostarcza architektury systemu, specyfikacji modułu i logiczną bazę danych.

W warstwie fizycznej zespół tworzy aplikację i bazę danych przez użycie generatora aplikacji i serwera DDL. Zespół weryfikuje aplikację fizyczną w trakcie testów, a końcowe ułożenie dokumentów biznesowych przez uruchamianie skryptów testowych wytworzonych bezpośrednio z odzyskanych i rozszerzonych procesów biznesowych (które wcześniej zostały stworzone w warstwie biznesowej).

Poniższy diagram przedstawia trzy podejścia projektowe CDM - klasyczne, „Fast Track” oraz „Lite”, a także pokazuje jak postępuje standardowy proces rozwoju poprzez warstwy biznesową, logiczną i fizyczną.

Diagram ilustruje grupy funkcjonalne i przepływy technik oraz narzędzia używane przy tych trzech podejściach projektowych.

Ta kartka jest celowo pusta

[Figurę 2-1]

[Figurę 2-1] kontynuacja

[Figurę 2-1] kontynuacja l

[Figurę 2-1] kontynuacja 2

    1. Warstwa biznesowa

Celem warstwy biznesowej jest dostarczenie modelu biznesowego, składającego się z kontekstu, procesu, funkcji i modeli danych.

      1. Modele biznesowe

Model kontekstowo-procesowy.

Model ten tworzy się w celu identyfikacji procesów kluczowych które odgrywaj ą rolę w biznesie. Identyfikuje się zasadnicze zdarzenia wyzwalające, główne przepływy procesów oraz wysokopoziomowych jednostek biznesowych. Interfejsy do innych systemów również są udokumentowane.

Funkcje biznesowe warstwy pierwszej

Tworzenie hierarchii funkcjonalnej warstwy pierwszej w celu ukazania wysokopoziomowych biznesowych funkcjonalnych grupowań zasadniczych obszarów funkcjonalnych wewnątrz organizacji.

Model procesu biznesowego

W modelu procesu biznesowego dokumentuje się procesy i zdarzenia biznesowe. Uszczegóławia się każdy proces poprzez kroki procesu, przepływy procesów, punkty decyzji biznesowych, jednostki organizacyjne, zdarzenia wyzwalające i rezultaty. Krok procesu na jego najniższym poziomie staje się elementarną funkcją biznesową. Model procesu biznesowego zajmuje się dokumentowaniem co jest do zrobienia, bez względu na to, w jaki sposób zostanie to zrealizowane.

Sugestia: Wymagania użytkownika biznesowego są kluczem do udanego modelowania procesów biznesowy

Model funkcji biznesowych.

W modelu funkcji biznesowych organizuje się elementarne funkcje biznesowe w hierarchie obszarów funkcjonalnych. Dodaje się także funkcje nie oparte o procesy, takie jak funkcje utrzymujące i jednokrokowe, do hierarchii funkcji. Planuje się też elementarne funkcje biznesowe w powiązaniu z encjami i atrybutami i uszczegóławia się ich funkcjonalność w pseudokodzie.

Model danych biznesowych.

W modelu danych biznesowych dokumentuje się wymagania dotyczące danych biznesowych. Tworzy się encje biznesowe i powiązania między encjami, oraz identyfikuje się zasadnicze atrybuty.

Macierz Encje/Atrybuty do Funkcji.

W celu uzupełnienia modelu funkcji biznesowych mapuje się encje biznesowe i atrybuty z modelu danych biznesowych na funkcje biznesowe.

    1. Warstwa logiczna.

Praca wykonana w warstwie logicznej uwydatnia silne powtórne użycie modeli biznesowych i dostarcza architektury systemowej specyfikacji modułów i logicznej bazy danych.

      1. Modele systemowe.

Podejście klasyczne: Modele systemowe prezentują architekturę systemu i są wyraźnie dostarczane w podejściu klasycznym. Podejście „Fast Track” spełnia wiele takich samych zadań jak podejście klasyczne, jednak zadania te zawarte są wewnątrz modułu definicyjnego „Fast Track” i logiczna baza danych projektuje zadania jako kroki zadaniowe.

Model procesów systemowych.

Model procesów systemowych identyfikuje w jaki sposób procesy będą spełniane poprzez wskazywanie które kroki procesów są formatkami, raportami lub programami wsadowymi.

Odzyskaj: Nie ma sensu rozpoczynać od nowa. Należy wzbogacić model procesów biznesowych o procesy systemowe i kroki procesów w celu stworzenia modelu procesów systemowych.

Model funkcji systemowych.

Model funkcji systemowych zawiera wszystkie funkcje potrzebne do wsparcia systemu aplikacyjnego. Elementarne funkcje biznesowe są teraz mapowane w encje i atrybuty i dokumentowane w języku pseudokodu, który uszczegóławia ich funkcjonalność.

Odzyskaj: Nie ma sensu rozpoczynać od nowa. Należy wzbogacić model funkcji biznesowych o funkcje wspierające kroki procesu systemowego i encje systemowe.

Model danych systemowych.

Model danych systemowych zawiera wszystkie encje potrzebne do wsparcia systemu aplikacyjnego. W pełni rozwija się atrybuty dla każdej encji.

Decyduje się wyprowadzone i przenormowane atrybuty i tworzy się interfejs i encje kontrolne.

Odzyskaj: Nie ma sensu rozpoczynać od nowa. Należy wzbogacić model danych biznesowych o encje wspierające procesy i funkcje systemowe.

Macierz Encje/Atrybuty do Funkcji.

W celu uzupełnienia modelu funkcji systemowych mapuje się encje biznesowe i atrybuty z modelu danych biznesowych na funkcje biznesowe.

      1. Specyfikacja Modułu.

Model procesu modułu.

Model procesu modułu (składnik Projektu Aplikacyjnego) przedstawia drogę, jaką specyficzne moduły wspieraj ą proces biznesowy. Odzyskaj: Nie ma sensu rozpoczynać od nowa. Należy stworzyć model procesu modułu z modelu procesu systemowego (klasyczny) lub biznesowego („Fast Track”).

Definicja modułu.

W definicji modułu mapuje się elementarne funkcje biznesowe na moduły zasadnicze oraz mapuje się szczegółowe użycia tablic i kolumn. Rozwija się logikę funkcji, wygląd modułu i dołącza się standardy interfejsu użytkownika.

      1. Logiczna Baza Danych.

Definicja Bazy Danych.

W rozwijaniu definicji bazy danych projektuje się tablice i kolumny, rozwija definicje kluczy podstawowych i obcych i projektuje sekwencje i indeksy. Rozwija się reguły walidacji, analizuje zagadnienia nad- i podtypów, a także tworzy się obliczenia i przenormowanie kolumn.

    1. Warstwa Fizyczna.

W warstwie fizycznej zespół tworzy aplikację użytkową i bazę danych poprzez wykorzystanie generatorów aplikacji i serwera DDL. Zespół weryfikuje aplikację fizyczną podczas testów, a końcowe ustawienia biznesowe dokumentów przez uruchamianie testowych skryptów wytworzonych bezpośrednio z odzyskanych i rozszerzonych procesów biznesowych (które wcześniej zostały stworzone w warstwie biznesowej).

      1. Aplikacja.

Generacja Modułu.

Należy użyć generatory Designer/2000 w celu wytworzenia formularzy, raportów i wyzwalaczy (server triggers). Używa się narzędzi Developer/2000 w celu dopasowania aplikacji do wymagań stawianych

przez podejście klasyczne bądź „Lite”. Podejście „Fast Track” nie potrzebuje użycia Developer/2000, lecz może dokonywać zmian bezpośrednio w warstwie logicznej i powtórnie generować. Przy podejściu klasycznym oraz „Lite” można wybrać powtórne projektowanie i powtórnie generować, lub kontynuować pełne użytkowanie Developer/2000 przy pomocy generowanej aplikacji jako punkt początkowy dla dopasowania.

      1. Fizyczna Baza Danych.

Generacja Bazy Danych.

Używa się generatorów Designer/2000 w celu stworzenia skryptów definiujących obszary tabel i segmenty typu „rollback”, wyznaczania obiektów bazy danych do obszarów tabel, obliczania zasięgu, procentowego zużycia. Określa się rozmiar i liczbę plików bazy na każdy obszar tabeli, i definiuje się pliki logu dla każdej bazy. Należy uruchomić skrypty w celu zbudowania bazy i jej obiektów.

      1. Weryfikacja.

Testowanie modułów.

Należy wykonać testowanie każdego z modułów, jak tylko stanie się on dostępny. Projektuje się testy modułów dla ćwiczenia funkcyjności opartej o elementarne funkcje biznesowe, walidację, kalkulacje, obsługę błędów, bezpieczeństwo modułów, zachowanie interfejsu użytkownika, teksty pomocnicze oraz warstwy.

Odzyskaj: W celu stworzenia skryptów testowych należy użyć „Module Process Model” oraz „Module Functional Documentation”.

Testowanie integralności modułów.

Należy wykonać testowanie integralności modułów odpowiadających tym samym zdarzeniom biznesowym i procesom w obszarze funkcjonalnym. Test integracji modułów weryfikuje więzi i integracje między modułami.

Odzyskaj: Skrypty testujące integralność modułów są rozszerzeniem modelu procesów modułu. Scenariusze testów integralności modułów są specyficznymi odpowiedziami na zdarzenie.

Testowanie systemu.

Testowanie systemu weryfikuje cały system aplikacyjny poprzez testowanie integracji między procesami. Testy systemowe są specjalnie zaprojektowane dla testów odnośnie historii, bezpieczeństwa, dokumentacji, danych wprowadzonych i skonwertowanych, integracji procesów, uzgadniania zapisów systemu, strumieni pracy, backup'ów i ich odzyskiwania oraz archiwizacji danych. Dla sprawdzenia ładowności serwera należy uruchomić scenariusze równolegle. Należy też sprawdzić blokowanie wierszy i kolumn.

Odzyskaj: Skrypty testujące system, które wykonuj ą integrację procesów, są po prostu skryptami testowymi poukładanymi kolejno i opartymi na wspólnych profilach danych.

Testowanie integracji systemu

Testowanie integracji systemu weryfikuje współegzystencję i integrację systemu aplikacji z „sąsiadującymi" systemami aplikacji. Zaprojektuj testy integracji systemu by sprawdzić integrację modułów lub działanie interfejsów między systemami aplikacji. Żeby przetestować obciążenie sieci, zasymuluj obciążenia użytkownikami przez wykonanie wielu współbieżnych scenariuszy.

Rozszerz skrypty testowania systemu w skrypty testowania integracji systemu. Użyj skryptów testowania krytyczności systemu by przetestować obciążenie sieci i serwera oraz wydajność systemu

Testowanie odbioru

Testowanie odbioru weryfikuje czy nowy system aplikacji spełnia kryteria użytkownika dotyczące odbioru.

Testowanie odbioru symuluje eksploatację i jest wykonywane w podobnym środowisku przez końcowego użytkownika wykonującego skrypty testowania systemu dla ostatnio konwertowanych danych. Jeśli klucze użytkownika zostały wywołane w systemie i testowaniu integracji systemu, testowanie odbioru może być niedokładne.

Użyj wyznaczonych skryptów testujących system by wykonać testowanie odbioru.

Niezwykle ważny jest wybór właściwego podziału projektu na etapy. Etap jest techniką zarządzania używaną do skupienia wysiłku zespołów projektu na celach krótkoterminowych oraz do przedstawiania postępów kierownictwu. Raporty tworzone na końcu etapu dostarczaj ą możliwości oceny kondycji projektu przez „ludzi spoza projektu".

    1. Porównanie podejść CDM

Relacja między podejściem a etapem

Poniższy diagram przedstawia trzy podejścia projektowe CDM - klasyczne,

szybkiej ścieżki i „Lite” - oraz relacje między ich etapami. Te trzy podejścia są opisane w rozdziale 1.

„Lite”

prototypowanie i budowa

wdrożenie i ekspl.

szybka ścieżka

modelowanie wymagań

projektowanie i generacja systemu

wdrożenie i ekspl.

klasyczne

definicja

analiza

projektowanie

budowa

wdrożenie

eksploatacja

warstwa przedsiębiorstwa

warstwa logiczna

warstwa fizyczna

kontekst

zasięg

wymagania

architektura

specyfikacja

aplikacja

Rysunek 3-1 Relacja między podejściami a etapami.

Skala i złożoność projektu

Podstawową rzeczą braną pod uwagę przy wyborze podejścia projektowego są skala i złożoność projektu. Skala projektu jest określona przez jego zasięg funkcjonalny, wielkość wysiłku, stabilność wymagań, różnorodność i ilość użytkowników oraz stopień współdziałania z innymi systemami. Stopień złożoności jest funkcją złożoności reguł przedsiębiorstwa, stopnia automatyzacji systemu i liczby zewnętrznych interfejsów.

Generalnie duża skala projektu towarzyszy bardziej złożonemu projektowi. Razem ze wzrostem skali i złożoności w planie projektu powinna być umieszczana większa ilość punktów kontrolnych w celu określenia, czy ciągle jesteśmy „na ścieżce", i oszacowania wielkości wysiłku wymaganego na resztę projektu.

Rysunek 3-2 Skala i złożoność projektu.

Czas trwania projektu

Kolejnym czynnikiem branym pod uwagę przy wyborze podejścia projektowego jest czas trwania projektu. CDM szuka równowagi między złożonością wymagań a szybkością implementacji w każdym z podejść. Rysunek 3-3 pokazuje relację między czasem trwania projektu a każdym z podejść CDM.

Rysunek 3-3 Czas trwania projektu.

Krytyczność aplikacji

Jak ważna jest dla przedsiębiorstwa aplikacja? Niektóre aplikacje tylko pomagają w ograniczonej ilości funkcji przedsiębiorstwa, podczas gdy inne wywierają wpływ na całe przedsiębiorstwo. Mniej krytyczne aplikacje mają bardziej ograniczony aspekt funkcjonalny, automatyzują niektóre ręcznie wykonywane zadania, są używane przez małą ilość użytkowników lub wykonują tylko tysiące transakcji każdego dnia. Bardziej krytyczne aplikacje wywierają wpływ na finanse przedsiębiorstwa, mają bezpośredni kontakt z klientem, są używane przez setki użytkowników lub wykonują setki tysięcy transakcji każdego dnia.

Krytyczna natura aplikacji również wpływa na wybór podejścia. Mniej krytyczne aplikacje mogą nie wymagać wiele kontroli podczas cyklu rozwoju. Krytyczne aplikacje nakazują więcej kontroli z większą ilością punktów kontrolnych, etapów i elementów dostawy oprogramowania.

Nie krytyczne - Aplikacja nie wywiera wpływu na bazę klientów lub inną krytyczną funkcję przedsiębiorstwa. Aplikacja służy jako funkcja wspierająca dla przedsiębiorstwa, z ograniczoną ilością użytkowników.

Krytyczne dla przedsiębiorstwa - Aplikacja jest używana na poziomie działu. Jest używana przez tych, którzy bezpośrednio z klientami załatwiają umowy albo wykonuj ą operacje przedsiębiorstwa. Niepoprawna lub błędna funkcjonalność ma wpływ na stan finansowy przedsiębiorstwa, możliwość wykonywania operacji przedsiębiorstwa lub bazę klientów.

Krytyczne dla misji - Aplikacja jest używana w całym przedsiębiorstwie przez tych, którzy bezpośrednio z klientami załatwiaj ą umowy albo wykonuj ą krytyczne operacje przedsiębiorstwa. Niepoprawna lub błędna funkcjonalność ma wpływ na stan finansowy przedsiębiorstwa, możliwość wykonywania operacji przedsiębiorstwa lub bazę klientów.

Tabela porównawcza

Podejście

„Lite”

Szybka ścieżka

Klasyczne

Modele przedsiębiorstwa

Model procesów

Ograniczony

V

V

Model funkcji

V

V

Model danych

V

V

Modele systemu

Model procesów

V

Model funkcji

V

Model danych

V

Prototypowanie

V

V

Pilotowe

Powtarzające się Projekt=>Generacja==>Test

V

V

W 100 % wygenerowana aplikacja bez modyfikacji wygenerowanego kodu

V

Podział czasu: przygotuj zasoby, ustal skalę czasu, ustal priorytety elementów dostawy oprogramowania

V

V

Ograniczony

Developer/2000 zmienia wygenerowany kod

V

V

Architektoniczne ograniczenie fizycznej bazy danych i funkcjonalności

V

V

Zasięg projektu

Mały

Średni

Duży

Integracja między funkcjami w procesie przedsiębiorstwa

Pojedynczy

Pojedynczy

Wielokrotny

Duże ryzyko:

  • trudne do uzyskania lub stale zmieniające się wymagania

  • duża ilość użytkowników z rozległego obszaru geograficznego

  • niedoświadczeni ludzie rozwijający aplikację

  • nowa działalność przedsiębiorstwa

  • niedoświadczeni użytkownicy

V

Duże potrzeby kontroli projektu:

  • rygorystyczna kontrola zmiany

  • dodatkowe elementy dostawy oprogramowania

V

Tabela 3-1 Porównanie podejść CDM

    1. CDM - Podejście klasyczne

Klasy podejście wspiera projekty, które są określone następującymi zagadnieniami:

Skala i złożoność projektu

Czas trwania projektu

Krytyczność aplikacji

Znaczące aspekty modelowania

Podejście klasyczne wykorzystuje dwa podstawowe typy modeli wymagań -model przedsiębiorstwa i model systemu. W ogólności, model przedsiębiorstwa odnosi się do pytania „co”, zaś model systemu do pytania „jak”. Sformalizowane podejście do rozwijania systemów, takie jak klasyczne, wymaga obu modeli.

Model przedsiębiorstwa obejmuje wymagania dokładnie dotyczące działalności, nie rozpatruje sposobu implementacji aplikacji. Klasyczne zadania modelowania procesów wywołują zadania modelowania funkcji i danych. Model przedsiębiorstwa jest zarysowany, kiedy model procesów przedsiębiorstwa, model funkcji przedsiębiorstwa i model danych przedsiębiorstwa są ze sobą uzgodnione.

Model systemu używa modelu przedsiębiorstwa jako punktu startowego, następnie dodaje wymagania specyficzne dla systemu i rozwija architekturę dla opisu, w jaki sposób system będzie implementowany.

Jedynym w swoim rodzaju rozróżnieniem między podejściem klasycznym a innymi jest w Designer/2000 wybór narzędzi do wykonania zadań architektury systemu. Podstawowymi narzędziami architektury systemu są: Process Modeller, Function Hierarchy Diagrammer i Entity Relationship Diagrammer. Również różnicą od innych podejść jest użycie regulacji czasu i Database Wizard.

W podejściu klasycznym wszystkie aspekty architektury systemu są tworzone za pomocą Entity Relationship Diagrammer, gdy model danych jest w postaci encji i atrybutów. To znaczy, że identyfikacja i tworzenie denormalizowanych i pochodnych atrybutów, tworzenie komunikacyjnych, interfejsowych i sterujących encji, uzgadnianie nad- i podtypów oraz rozkładanie relacji wiele-na-wiele są wykonywane przy użyciu Entity Relationship Diagrammer.

Żeby pozostać w zgodzie z modelem danych, model funkcji musi być rozszerzony o odpowiednie funkcje komunikacyjne i sterujące, i uaktualniony o użycie encji/atrybutów w oparciu o encje o wyraźnym charakterze intersekcji lub z podtypami, a także o denormalizowane i pochodne atrybuty. Kiedy model danych i funkcji są kompletne, powinny zostać wywołane Database Wizard oraz Aplication Wizard.

Podejście klasyczne przy użyciu Designer/2000

Poniższy rysunek ilustruje relację między podejściem klasycznym a Designer/2000.

Rysunek 3-4 Podejście klasyczne przy użyciu Designer/2000

    1. CDM - Podejście „szybka ścieżka”

Podejście „szybka ścieżka” rozwija projekty, które intensywnie generują kod. Zaletą tego podejścia jest to, że opiera się na modelach z repozytorium, które są istotne dla rozwoju średnich i dużych projektów. Podejście „szybka ścieżka” jest przeznaczone dla projektów, które maj ą następujące charakterystyki:

Skala i złożoność projektu

Czas trwania projektu

Krytyczność aplikacji

Znaczące aspekty modelowania

Pojedynczy model przedsiębiorstwa przyspieszoną naturę podejścia „szybka ścieżka”, gdyż projekty dążą do zmniejszenia zasięgu, skrócenia czasu trwania i wymagaj ą mniej kontroli niż projekty podejścia klasycznego. Klasyczne zadania modelowania procesów wywołują zadania modelowania funkcji i danych. Model przedsiębiorstwa jest zarysowany, kiedy model procesów przedsiębiorstwa, model funkcji przedsiębiorstwa i model danych przedsiębiorstwa są ze sobą uzgodnione.

„Szybka ścieżka” opiera się na własnościach Designer/2000 służących do rozwoju architektury systemu.

Unikalne różnice w modelowaniu systemów przy wykorzystaniu podejście „szybkiej ścieżki” a innymi podejściami polegają na szybszym użyciu Designer/2000 Database Wizard. W podejściu „szybkiej ścieżki”, wszystkie elementy architektury technicznej systemu tworzone są w tabelach i kolumnach za pomocą Data Schema Diagrammer.

Podejście „szybkiej ścieżki” używa Database Wizard do przekształcania encji i atrybutów w tabele i kolumny, uzgadniania nad- i podtypów, jak i rozkładania relacji wiele do wielu. De normalizacja i pochodzenie są wykonywane na kolumnach, natomiast wiadomości, interfejsy i zarządzanie całą strukturą jest tworzone jako tabele używając Data Schema Diagrammer.

W podejściu „szybkiej ścieżki” model funkcjonalny jest transformowany bezpośrednio w moduły kandydujące używając Application Wizard. Moduły kandydujące mogą być rozwijane (przebudowywane) przy użyciu narzędzi Designer/2000 Module Structure, Module Data i Module Logic służących do implementowania wymagań dotyczących systemu jak i jego architektury.

Poniższy diagram pokazuje relacje pomiędzy podejściem „szybkiej ścieżki" a Designer/2000:

Figure 3-5

    1. Podejście Okrojone

Podejście okrojone jest przeznaczone do wytwarzania małych projektów gdzie główne problemy są rozwiązywane poprzez tworzenie ekranów i raportów, a zarazem nie jest żądany model funkcji lub model danych jako zdobywanie i sprawdzanie wymagań systemu. Podejście okrojone przeznaczone jest dla projektów, które posiadając następujące cechy :

Skala i złożoność projektu

Czas wykonania

Krytyczność aplikacji

Uwagi do modelowania

Zasadniczymi elementami podejścia okrojonego jest „prototypowanie i budowanie”, co nie wymaga stosowania modeli biznesowych. Zamiast tego, członkowie zespołu tworzą moduły wykorzystując narzędzia Designer/2000 Module Structure, Module Data i Module Logic służące do tworzenia aplikacji i nie rozpoczynaj ą tworzenia systemu od hierarchii funkcji. Członkowie zespołu tworzą tabele używając narzędzia Designer/2000 Data Schema, bez używania modelu encji. Generują oni kod aplikacji i skrypty DDL poza repozytorium Designer/2000 i przygotowują do prototypowania. Wymagania, żądania, które zostały wykryte w trakcie prototypowania są przechowywane w repozytorium dla kolejnej iteracji. Po zakończeniu zespół za pomocą narzędzi do budowania aplikacji rozbudowuje prototyp i cykl rozpoczyna się od początku. Programiści mogą używając generatorów Designer/2000 w celu wytworzenia aplikacji Developer/2000, Visual Basic i Web.

Uwaga: Mimo że to podejście jest opisane w terminach Designer/2000 do budowania swoich aplikacji możesz używać różnego rodzaju narzędzi projektowych.

Poniższy diagram przedstawia relacje pomiędzy elementami podejścia „okrojonego” i Designer/2000:

Figure 3-6

3-13


Wyszukiwarka