Dodatkowe założenia dotyczące wdrażania systemu zintegrowanego Zarządzanie projektem, a zarządzanie firma informatyczną

W literaturze podaje się szereg efektywnych metod zarządzania i wytwarzania oprogramowania. Większość opracowanych metodyk odnosi się odpowiednio do:

• Grupy projektowej. Jest to typowe podejście, w którym analizuje się klasę projektu i w zależności od jego rodzaju określa się sposób realizacji projektu.

• Grupy roboczej pracującej nad rodziną oprogramowania. Grupa robocza realizuje podobne tematycznie projekty (ten sam asortyment produktów programowych).

• Pojedynczych osób w celu określenia rozwoju umiejętności i przydziału ról projektowych.

• Całej firm y, w której grupy robocze m ogą realizować różnorodne projekty informatyczne.

Celem niniejszego opracowania ma być wspomaganie całej firmy informatycznej w zakresie zarządzania i wytwarzania oprogramowania.

Zintegrowany system ma stworzyć dla takiego przedsiębiorstwa zdolność efektywnej realizacji projektów przy założonym standardzie jakości wytwarzania i zarządzania. Dlatego ważne jest opracowanie bardziej ogólnych metodyk, które charakteryzowałyby się spójnością i jednolitym sposobem wykorzystania.

W wyniku prac powinno powstać wspólne podejście do wszystkich projektów.

Natomiast specyfika dotycząca projektu powinna być udokumentowana w sposób jednolity dla wszystkich projektów.

Opracowane rozwiązania m uszą uwzględnić specyfikę rozpatrywanych firm i ich szybkie reagowanie na potrzeby klienta. Oznacza to, że w proponowanych rozwiązaniach m uszą być uwzględnione zwinne metodyki wytwarzania oprogramowania. Następnym ważnym zagadnieniem przyjęcie założenia o wytwarzaniu oprogramowanie z wykorzystaniem komponentów.

Powoduje to konieczność stosowania pewnych rozwiązań typowych dla inżynierii systemów. Zaproponowane rozwiązania odnosić się będą do całej firmy, lecz winny mieć organizację pro-projektową, muszą dodatkowo wspomagać pracę grup roboczych i projektowych oraz poszczególnych członków grup projektowych.

Dla każdego obszaru zarządzania przewiduje się ewolucyjny sposób wdrażania. Zakłada się opracowanie założeń oraz modeli dla zintegrowanego systemu, który by wspomagały wytwarzanie oprogramowania. Ważne jest, aby taki system był prosty dla zastosowań w tego typu firmach oraz by uwzględniał stan finansowy takich firm. Zakłada się, że system zintegrowany powinien być rozwiązaniem Intranetowym zbudowanym w oparciu o różne szeroko dostępne narzędzia związane z obszarem zarządzania i wytwarzania oprogramowania.

Wybór narzędzi od rożnych producentów związany jest z koniecznością uzyskania niskich kosztów systemu, możliwością ich dobrania do potrzeb rozważanych firm, koniecznością stopniowego wdrażania wybranych obszarów. Wyzwaniem dla takiego rozwiązania jest opracowania metod integracji poszczególnych narzędzi oraz zasad konstrukcji systemu informatycznego włączającego wybrane narzędzia i uzupełnionego o brakujące funkcjonalności. Wiadomo, że duże zintegrowane systemy wspomagające wytwarzania oprogramowania mają trudności wdrożeniowe na wskutek ich złożoności, braku uwzględnienia specyfiki firm oraz ze względu na wysokie koszty.

Rozpatrując charakterystyki MSPI, wydaje się za celowe opracowanie metod zarządzania wytwarzaniem oprogramowania z uwzględnieniem specyfiki mniejszych firm informatycznych. Podstawą do tworzenia takiego systemu jest wybór dostępnych na rynku narzędzi i włączenie ich do systemu zintegrowanego.

Jednym z niedocenianych, ale bardzo ważnych zagadnień jest wprowadzenie i udokumentowanie pewnych standardów dla firm informatycznych. Dobrze określone i skonfigurowane standardy w firmie porządkują wiele działań.

Standardowe rozwiązania proponowane dla firm są często niedoceniane, a m ogą odegrać znaczącą rolę porządkującą w procesach wytwarzania. Standardy mogą mieć postać:

1. Dokumentów określających sposoby realizacji procesów.

2. Dokumentów opisujących standardowe struktury, produkty, aktywności, itp.

3. Szablonów - standardowych dokumentów przeznaczonych do wypełnienia.

4. Standardowych narzędzi - zbiór standardowych narzędzi, które należy stosować w firmie.

5. List kontrolnych przeznaczonych do weryfikacji procesów lub produktów.

Bazując na przedstawionej metodyce oraz na podanych standardach, zakłada się, że firma informatyczna będzie w stanie samodzielnie na bazie przedstawionych opracowań lub przy pomocy konsultacji sporządzić następujące dokumenty wchodzące w skład księgi jakości, dotyczące poszczególnych, wymienionych niżej obszarów zarządzania.

1. Cel wdrożenia i kierunki rozwoju.

2. Opis procesów proponowanych do wdrożenia.

3. Plan wdrożenia (elementy obowiązkowe i opcjonalne).

4. Lista standardów (dla firmy, działu, grupy projektowej).

5. Lista standardowych narzędzi i sposobów ich wykorzystania.

6. Lista szablonów zapewniających, że informacje będą w sposób jednolity przedstawiane.

7. Listy kontrolne poprawności funkcjonowania procesu, poprawności

produktu.

8. Zasady kontroli procesów i zapewnienia, ze będą utrzymane podane założenia.

9. Wytyczne do ciągłego doskonalenia procesów.

7. Wnioski

W opracowaniu na podstawie dotychczasowych prac [6, 7,8] zawarto pewne przemyślenia związane z budową systemu zintegrowanego wspomagającego wytwarzanie oprogramowania, ważne z punktu widzenia małych i średnich firm informatycznych.

Proponowane rozwiązanie zakłada wybranie odpowiednich narzędzi z dużej liczby dostępnych, dla poszczególnych obszarów zarządzania oraz wykorzystanie ich w budowanym systemie zintegrowanym. Główne zadania będą polegały na określeniu zasad integracji narzędzi oraz podsystemów, które należy zbudować od nowa.

Dla każdego obszaru opracowane zostaną procesy i struktury danych związane z tymi procesami. Zaproponowane procesy powinny być w dokładnie opisane i przedstawione w sposób graficzny. Należy opracować szereg modeli przeznaczonych do opisu procesów związanych z funkcjonowaniem oprogramowania. Istnieje cała szeroka gama modeli do obrazowania funkcjonowania procesów. N a uwagę zasługuje język modelowania UM L oraz jego rozwinięcie o nazwie SPEM (Software Process Engineering M etamodel) [22], Istnieją metodyki, których procesy są opisane w SPEM, przykładowo należy do nich RUP (Rational Unified Process). Na uwagę zasługują modele przepływu pracy, szczególnie ze osiągnięto wysoki poziom standaryzacji i szerokie zastosowanie do modelowania procesów biznesowych [26].

Literatura

1. AHERN D. M., CLOUSE A., TURNER R.: CMMI Distilled, A Practical Introduction to Integrated Process Improvement, SEI Series in Software Engineering, Addison-Wesley, 2003, p. 305.

2. Change Management Learning Center, http://www.change-management- directory.com/software/web-based.html, 2005.

3. Capability Maturity Model Integration (CMMI) Version 1.1,CM M I fo r System Engineering, Software Eng., Integrated Product and Process Developm ent and Supplier Sourcing. Carnegie Mellon SEI, CMMI Product Team, 2002, p. 724.

4. BENKEN G., HAMMERSCHALL U., BROY M., CENGARLE M. V., JURJENS J., RUMPE B., SCHOENMAKERS M.: Componentware — State o f the Art 2003, Understanding Components Workshop, CUE Initiative, Venice, 2003, p. 44

5. Guidelines fo r Successful Acquisition and Management o f Software-Intensive systems. Department o f the Air Force, Software Technology Support Center,

2003.

6. WEREWKA J., PIWOWARCZYK M.: Zagadnienie kontroli pracy w procesie wytwarzania oprogramowania. Problemy i metody inżynierii oprogramowania. W ydawnictwa Naukowo-Techniczne, pp. 567-576.

7. WEREWKA J., SUJDAK M.: Standaryzacja analiz wykonywanych prac w projektach informatycznych, XII Konferencja Sieci i Systemy Informatyczne, Łódź 2004, Politechnika Łódzka, pp. 593-602.

8. SUJDAK M., WEREWKA J.: Zagadnienie tworzenia szablonów w projektach informatycznych, XII Konferencja Sieci i Systemy Informatyczne, Łódź 2004, Politechnika Łódzka, pp. 583-592.

9. KERZNER H.: Project Management. A systems Approach to Planning, Scheduling and Controlling, John Willey & Sons, Inc., 2002, p. 891.

10. Microsoft Solution Framework, version 3.0 Overview, Microsoft Solution Framework, White Paper, 2003, p. 28.

11. M SF Process M odel v. 3.1, Microsoft Solution Framework, White Paper, 2002, p. 47.

12. M SF M anagement Discipline v.13.1, Microsoft Solution Framework, White Paper, 2002, p. 31.

13. Boris Mutafelija, Harvey Stromberg. ISO 9001:2000 CMMI vl . l Mappings, 2003

14. Boris Mutafelija, Harvey Stromberg. Exploring CMMI-ISO 9001:2000 Synergy when Developing a Process Improvement Strategy. SEPG 2003 Conference.

15. NAWROCKI J., PAWŁOWSKI P., POSPIECH K.: System Internetowy wspomagający wytwarzanie oprogramowania metodą PRINCE , ZN Politach.

Gdańskiej, 2003, p. 7.

16. A Guide to the Project Management Body o f Knowledge, Project Management Institute, Pennsylvania USA, 2000, p. 216.

17. Product Data M anagement and Software Configuration Management. The Association o f Swedish Eng. Industries, 2001, p. 181.

18. Internet - Project M anagement References. Project Management Web Sites of Interest, 2003, p. 58.

19. POHJOLAINEN P.: Software Testing Tools , Department o f Computer Sci.

and Applied M athematics, Univ. o f Kuopio, 2002, p. 79.

20. Rational Unified Process, IBM Rational Software, 2003.

21. SKARŻYŃSKA G.: Rozwiązanie informatyczne wspierające strategie motywowania pracowników, Oracle polska, 2005. p. 42.

22. Software Process Engineering Metamodel Specification. Object Management Group, Inc. 2002.

23. TickIT, Guide to Software Quality Management System Construction and Certification Issue 3.O., Department o f Trade and Industry and the British Computer Society, 1997.

24. WHEELWRIGHT S.C., M anaging New Product and Process Development:

Text Cases, Free Press, 1992

25. Volere Requirement resources. Requirements tools,

http://vvww.volere.co.uk/tools.html, 2005.

26. Workflow Process Definition Interface - XM L Process Definition Language, Workflow Management Coalition Workflow Standard, http://www.wfmc.org, 2002.

27. YAO Y., LEE H.: Applying ISO 9001 and CMMI in Quality-Oriented Knowledge Management fo r Software Process Improvement, International Journal o f Electronic Business Management, Vol. 2, No. 2,2004, pp. 140-151.

ROZDZIAŁ V

TYPOWE CZYNNIKI NIEPOWODZENIA W REALIZACJI