| „Zastosowanie Inżynierii Oprogramowania. Biznes a Inżynieria Oprogramowania." |
|---|
| Napisane przez Mon 20 Dec 2010 przez Artur (1233 cztane) |
|
„Zastosowanie Inżynierii Oprogramowania. Biznes a Inżynieria Oprogramowania." Autor: Artur Machura artur.machura (at) uml.com.pl tel. 501-176-256 Streszczenie Artykuł ma celu poruszyć szeroko rozumiane zagadnienie nauki Inżynierii Oprogramowania w rzadziej spotykanym kontekście, mianowicie wykorzystania tej wiedzy w praktyce. Cel napisania tego artykułu, wynika z faktu - że praktyczne wykorzystanie nauki Inżynieria Oprogramowania w przedsięwzięciach informatycznych, jest zależne od wielu czynników, m.in.: biznesowych, rodzajów projektów, doświadczeń członków zespołu wytwórczego. Należy tu również zauważyć, że zwykle pojęcia Inżynierii Oprogramowania, wynikają z doświadczeń zespołów realizujących projekty w krajach, gdzie informatyka znacznie wcześniej zaczęła odgrywać istotną rolę w gospodarce. Co z drugiej strony prowadzi do konkluzji, że kraje z mniejszymi doświadczeniami, bez pewnego niezbędnego czasu ewolucji i doskonalenia dojrzałości procesów wytwórczych - mają znaczne trudności w bezpośrednim i praktycznym przełożeniu aktualnych i najnowszych nurtów Inżynierii Oprogramowania. Wykorzystanie tej nauki w praktyce, zasługuje na szczególną uwagę - zważywszy na odgrywającą tu istotną rolę historii kreowania się zagadnień, takich jak: jakość, procesy wytwórcze, metody i techniki, narzędzia wspierające prace projektowe. Zawarta w artykule treść, poruszy w rezultacie następujące tematy: Pojmowanie zagadnień Inżynierii Oprogramowania w wielu przedsięwzięciach budowy systemów informatycznych. Zidentyfikowanie istotnych problemów i niuansów związanych z praktycznym zastosowaniem Inżynierii Oprogramowania. Scharakteryzowanie związku Inżynierii Oprogramowania z otaczającym ją przez pryzmat przedsięwzięć informatycznych - biznesem. Przedstawienie wybranych istotnych wskazówek, pozwalających na lepsze wykorzystanie wielu dyscyplin Inżynierii Oprogramowania podczas budowy systemów informatycznych. Przede wszystkim, chciałbym podkreślić fakt istoty nauki Inżynieria Oprogramowania. Pojęcie to pojawiło się oficjalnie w 1968 roku na konferencji sponsorowanej przez NATO. Zupełnie nie przypadkowo, bo już w tamtym czasie istniały przesłanki o potrzebie wprowadzenia do przedsięwzięć budowy systemów informatycznych pojęć inżynierskich, które porządkowałyby i systematyzowały realizowane prace. Pozwalałyby na lepsze i efektywniejszą realizację projektów, zważywszy na: Wsparcie wielu prac projektowo-developerskich poprzez -wykorzystanie zintegrowanych narzędzi z rodziny CASE. Podnoszenie efektywności prac poprzez zastosowanie sprawdzonych metod i technik. Porządkowanie prac przez pryzmat stosowania określonych procesów wytwórczych. Zdefiniowanie jakości i dążenie do wytworzenia systemu informatycznego/ produktu spełniającego tą jakość. Kluczowe, do zrozumienia przesłania niniejszego artykułu, jest zwrócenie szczególnej uwagi na sposób pojmowania zagadnień Inżynierii Oprogramowania w realnych przedsięwzięciach budowy systemów informatycznych. Rozwarstwienie pojęć Inżynierii Oprogramowania znacznie ułatwia dokonanie takiej interpretacji.  Ze względu, na wzajemną zależność poszczególnych warstw Inżynierii Oprogramowania, tj. dbanie o jakość, proces wytwórczy, metody, narzędzia -scharakteryzuję ich często interpretację w przedsięwzięciach informatycznych w kolejności: od najbardziej do najmniej wpływowych na pozostałe. Dbanie o jakość , jest z jednej strony gruntowną i najistotniejszą warstwą pojęć Inżynierii Oprogramowania. Natomiast z drugiej strony, charakteryzuje się największą trudnością w jej zapewnieniu. Dbanie o jakość, niewątpliwie wiąże się z jej definicją w danym przedsięwzięciu informatycznym i następnie konsekwentnym jej przestrzeganiem w ramach postępu prac. A więc, jak zdefiniować jakość w przedsięwzięciu budowy systemu informatycznego ? Posłużę się następującą definicją: „Jakość najczęściej definiowana jest jako ogół właściwości obiektu, wiążących się z jego zdolnością do zaspokojenia stwierdzonych i oczekiwanych potrzeb klienta lub jako stopień, w jakim zbiór inherentnych właściwości spełnia wymagania. (2)” Należy tu podkreślić, że wspomniany w definicji klient, często nie jest w stanie określić precyzyjnie potrzeb - co w rezultacie gruntownie utrudnia na konsekwentnie przestrzeganie jakości. Ponadto skupienie uwagi na potrzebach klienta, siłą rzeczy musi być rozszerzone o charakterystyki techniczne oraz ekonomiczne produktu - systemu informatycznego. Gasparski, określił jakość (J) jako iloczyn danych typu boolowskiego racjonalności (R) i dokładności (D). J = RD Dokładność (D) wykonania produktu informatycznego przybiera jeden z dwóch stanów binarnych „0” lub „1”. Racjonalność (R) wykonania przedmiotu technicznego zależy od efektywności użytkowej (E), która z kolei jest określana jako ilość zasobów zaoszczędzonych w działaniu dzięki instrumentalizacji przypadających na jednostkę nakładów poniesionych na wyprodukowanie i eksploatowanie przedmiotu technicznego. W tym właśnie miejscu, chciałbym aby czytelnik bez względu na stanowisko jakie obejmuje bądź obejmował w projektach odpowiedział sobie na pytanie: „Czy spostrzegłeś działania zmierzające do definicji jakości w projekcie, w oparciu o wytyczne której realizowane byłyby prace?” Jako doświadczony Analityk w przedsięwzięciach informatycznych, muszę stwierdzić, że: „Zarówno Biznes jak i Inżynieria Oprogramowania mają wpływ na pojęcie jakości w przedsięwzięciach informatycznych. Przy czym, to właśnie biznes odgrywa kluczową rolę w pojęciu jakości systemów informatycznych.” Zatem, drogi Czytelniku - kontynuacje niniejszego wątku pt. „Dbanie o jakość” należałoby przenieść zupełnie w inny krąg rozważań - biznesowych. Dlatego, że to nie zasady Inżynierii Oprogramowania przesądzają o definicji jakości w przedsięwzięciach informatycznych a Biznes. Proces wytwórczy, względem organizacji projektu opartej o praktyki zebrane przez doświadczonych specjalistów z całego świata a więc i Inżynierię Oprogramowania, jest pewnym sposobem na właściwą organizację i realizację przedsięwzięcia informatycznego. Proces wytwórczy, jak można wywnioskować z przedstawionego rysunku 1, umiejscowiony jest w nauce Inżynieria Oprogramowania pomiędzy warstwami „Dbanie o Jakość” oraz „Metody”. Wobec czego, chciałbym scharakteryzować pojmowanie Procesu Wytwórczego, właśnie w tym zasadnym kontekście. Jak wspomniałem wcześniej, o jakości systemu informatycznego decydują w dużej mierze uzgodnienia na poziomie menadżerskim, handlowym a więc biznesowym. Co też, w zasadzie przesądza o pojmowaniu tak ważnego zagadnienia dla Inżynieria Oprogramowania, jakim jest Proces Wytwórczy. Wobec czego, interpretacja pojęcia „Proces Wytwórczy” jest zależna bezpośrednio od firmy/ wykonawcy projektu a więc i jego organizacji a nie definicji opisanych przez liczną literaturę i publikacje w tym zakresie. Wymienia się tam najczęściej następujące „modele” procesów wytwórczych: Sekwencyjny model liniowy. Model oparty o prototypowanie. Model szybkiej rozbudowy aplikacji. Model ewolucyjny - przyrostowy. Model ewolucyjny - spiralny. Należy tu wymienić również powszechnie stosowane modele z rodziny metodyk zwinnych, takie jak: XP (ang. Extreme Programming) SCRUM (3). Interpretacja pojęcia „proces wytwórczy” w przedsięwzięciach informatycznych, jest zależna zarówno od wykonawcy, otoczenia biznesowego oraz członków jego zespołu projektowego. Inaczej pojmowane są pojęcia przez przedstawicieli różnych kategorii: dyrektorów i prezesów, kierowników, reprezentantów różnych dyscyplin inżynierii oprogramowania, klientów i użytkowników. Jednolita interpretacja zagadnienia „procesu wytwórczego” wymaga określonych działań organizacyjnych i strategicznych firmy. Stopniowego budowania wiedzy, gdzie w drodze ewolucji organizacji zarówno wiedza, jak i świadomość będzie podlegała stopniowym zmianom. W innym przypadku, pomimo nawet faktu wprowadzenia określonych cząstkowych szkoleń, w dalszym ciągu realizacja przedsięwzięć informatycznych narażona jest na zwyczajny chaos, jaki towarzyszysz organizacjom o poziomie dojrzałości procesu wytwórczego - pierwszym, według modelu CMMI(4). Metody, a więc pewien zbiór wytycznych, które umożliwiają na realizację prac inżynierskich w określony sposób. Ich zastosowanie jest niezmiernie wartościowe nie tylko dla końcowego efektu prac, ale również przewidywalności czasu realizacji bądź osiągnięcia określonej jakości w projekcie. Jednak, posługując się dla przykładu językiem modelowania UML (Unified Modeling Language), jego właściwe zastosowanie jest znacznie utrudnione w projektach, gdzie zarówno dbanie o jakość jak i definicja procesu wytwórczego została pominięta. Dlaczego ? Z zagadnieniem poprawnego wykorzystania języka modelowania UML w projektach, wiążą się co najmniej właściwości takich pojęć, jak: Semantyka. Syntaktyka. Pragmatyka(5). Ale również niezmierna elastyczność notacji. Jako, że język modelowania UML, pozwala na różne sposoby wykorzystania w projektach. A więc, poprzez: Obrazowanie, Specyfikowanie, Tworzenie, Dokumentowanie(6). Poziom dojrzałości procesu wytwórczego, ma również bardzo duże znaczenie dla sposobu wykorzystania języka UML. Jako, że im bardziej ten proces jest dojrzały, tym dokumentacja nabiera większego znaczenia a więc stopniowo wzrasta również zakres wykorzystania języka UML. W rezultacie, istnieje bardzo wiele interpretacji sposobu wykorzystania UML. Nie wynika to tylko z przedsięwzięć dotyczących różnych projektów informatycznych, ale i jak w/w elastycznością i szerokimi możliwościami języka. Narzędzia, stanowią implementację w/w zagadnień, a więc umożliwiają Inżynierowi Oprogramowania na wykonywanie prac wysokiej jakości. Z tej właśnie racji, praca poprzez te narzędzia wyrażana - pozwala doświadczyć w/w kwestii i ustosunkowania się Inżynierowi do zagadnień: jakości, realizacji postanowień wynikających z procesów wytwórczych czy też do reguł wynikających z metod i technik. Istnieje również inny praktyczny wymiar stosowania narzędzi w przedsięwzięciach informatycznych. Być może, że słabo podkreślany w publikacjach naukowych ale i kluczowy - w praktycznym stosowaniu Inżynierii Oprogramowania. Mianowicie - pracy zespołowej. Biorąc pod uwagę podstawy powstania Inżynierii Oprogramowania, gdzie mowa o wprowadzeniu do prac projektowych pojęć inżynierskich w celach: sprawnej produkcji systemów z myślą umożliwienia produkcji oprogramowania na czas bez uszczerbku dla jego jakości(7), konserwowania oprogramowania, które powstało wiele lat temu i ciągle jest w użyciu (systemy spadkowe), rozwiązywania problemów integracji systemów zbudowanych z użyciem różnych języków i technologii (systemy heterogeniczne), oraz faktu, że tam gdzie Inżynieria Oprogramowania ma szczególne znaczenie a więc złożonych, wieloosobowych projektach - efektywna współpraca zespołu jest kluczowa zarówno do wykonania pracy, jak i zastosowania w praktyce pojęć Inżynierii Oprogramowania. Wśród istotnych zagadnień powiązanych z pracą zespołową, wymienia się: repozytorium projektu i przemyślane reguły związane z jego edycją, wzajemna świadomość wybranej metodyki pracy, proces wytwórczy, który poza ideą uwzględnia również właściwości środowiska, cechy osobowe członków zespołu. Reasumując, postrzeganie Inżynierii Oprogramowania w efektach pracy zobrazowanych przez narzędzia sprowadza się bardzo często do oceny „wierzchołka góry lodowej”, często diagramów, wycinków algorytmów czy też jakości fragmentów dokumentów. Podczas gdy o całościowym przestrzeganiu celu Inżynierii Oprogramowania, przesądza znacznie wiele więcej czynników (co najmniej wymienione w dokumencie i więcej). Podsumowanie Niewątpliwie Inżynieria Oprogramowania jest tą nauką, która ma na celu zapewnić przedsięwzięciom informatycznym sukces, zarówno podczas jak i po zakończeniu ich realizacji. Pomijanie pojęć Inżynierii Oprogramowania podczas budowy większości systemów informatycznych, na którą składają się dyscypliny takie jak: Analizowanie Biznesowe, Analizowanie Systemowe, Projektowanie, Programowanie, Testowanie, Zarządzanie projektem, Wdrożenie, Zarządzanie Konfiguracją i Zmianami prowadzi do chaosu. W rezultacie czego - z projektem wiążą się znaczące problemy a nawet jego klęska. Trudno sobie wyobrazić produkcję wysokiej jakości systemów informatycznych, począwszy nawet od tych najprostszych a kończąc na najbardziej złożonych - pomijając zagadnienia Inżynierii Oprogramowania, które w rezultacie pozwalają: sprawnie produkować systemy, efektywnie eksploatować i konserwować systemy, integrować systemy. Doświadczeni uczestnicy projektów, zdają sobie sprawę z dużej dynamiki środowisk projektowych. Fuzje firm, nieustanne zmiany tym bardziej podkreślają znaczenie ujednoliconego sposobu wytwarzania systemów informatycznych. Elastyczność zastosowania pojęć Inżynierii Oprogramowania, ma właśnie na celu na świadome i sensowne ich dostosowanie do różnych środowisk wytwórczych. Zastosowanie Inżynierii Oprogramowania w praktyce, tym bardziej zasługuje na uwagę, że koszt jej wdrożenia - wynika głównie z umiejętności producentów oprogramowania we wprowadzaniu niezbędnych zmian w ich organizacjach. Literatura: 1) Praktyczne podejście do Inżynierii Oprogramowania. Roger S. Pressman. Wydawnictwo Naukowo Techniczne 2004. 2) Certyfikacja w Informatyce. Jerzy Krawiec, Grażyna Ożarek. Polski Komitet Sterujący 2010. 3) http://pl.wikipedia.org/wiki/Proces_wytwórczy_oprogramowania 4) CMMI - Doskonalenie Procesów w Organizacji“. Mariusz Chrapko. Wydawnictwo Naukowe PWN, 2010 5) http://www.uml.com.pl 6) UML Przewodnik Użytkownika. Booch Grady, Rumbaugh James, Jacobson Ivar. Wydawnictwo Naukowo Techniczne. 7) http://pl.wikipedia.org/wiki/In%C5%BCynieria_oprogramowania |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.
