SYSTEMOWE UJĘCIE ZADANIA PROJEKTOWEGO

Transkrypt

1 3/12 ARCHIWUM ODLEWNICTWA Rok 2004, Rocznik 4, Nr 12 Archives of Foundry Year 2004, Volume 4, Book 12 PAN Katowice PL ISSN SYSTEMOWE UJĘCIE ZADANIA PROJEKTOWEGO R. WRONA 1 Wydział Odlewnictwa, Akademia Górniczo-Hutnicza, Kraków, ul. Reymonta 32 A. MACIOŁ 2, A. STAWOWY 3 Wydział Zarządzania, Akademia Górniczo-Hutnicza, Kraków, ul. Gramatyka 10 STESZCZENIE W pracy przedstawiono systemową procedurę formułowania zadania projekt o- wego. Procedura składa się z etapów obejmujących: badanie potrzeb, t ransformację potrzeb w problem projektowy i problemu - w zadanie projektowe. Wskazano, że istnieje przestrzeń swobody projektowej i obszar koncepcji projektowych. Podano również zasady oceny rozwiązania zadania projektowego. Key words: project task, requirements analysis 1. WPROWADZENIE Doskonalenie procesu projektowania jest problemem, któremu poświęca się obecnie wiele uwagi. Przedmiotem podejmowanych działań są głównie te etapy procesu projektowania, które obejmują prace zrutynizowane w zakresie tworzenia dokumentacji projektowej. Wprowadzane są nowe techniki i metody oraz urządzenia ułatwiające prace obliczeniowe, graficzne, organizacyjne itp. Znacznie mniejszą uwagę poświęca się tej części projektowania, która jest procesem twórczym, dotyczącym pracy myślowej i umiejętności projektanta. Panuje przekonanie, że projektowanie jest efektem intuicji, talentu i doświadczenia czyli właściwości umysłu ludzkiego, trudno dostępnego dla badań. Usprawnienie pracy twórczej pod względem wprowadzenia usystematyzowanych metod działania jest problemem złożonym co nie znaczy, że nie należy go objąć badaniami. 1 prof. dr hab. inż., rwrona@agh.edu.pl 2 dr inż., amacioł@zarz.agh.edu.pl 3 dr inż., astawowy@zarz.agh.edu.pl

2 Projektowanie jako wieloetapowy proces gromadzenia i przetwarzania informacji [1], wymaga określenia pewnych niezbędnych warunków początkowych, umożliwiających rozpoczęcie prac, jak również gwarantujących z możliwie największym prawd o- podobieństwem ich zakończenie. Postępowanie zmierzające do stworzenia takich warunków stanowi istotę systemowego ujęcia projektowania. Szczególnie należy uściślić znaczenie szeregu pojęć, do których zalicza się: badanie potrzeb, sformułowanie problemu i sformułowanie zadania projektowego. Identyfikacja potrzeb i przekształcenie ich w zadania projektowe jest koniecznym warunkiem procesu projektowania. 2. PROBLEMY IDENTYFIKACJI POTRZEB Postępowanie zmierzające do opracowania odpowiedniego opisu potrzeby polega na zabiegach sekwencyjno-iteracyjnych polegających na stopniowym uszczegółowieniu jej ujęcia [2]. Rozróżnienie rodzaju potrzeb można sprowadzić do następującego rozumowania: istnieje pewien zbiór P, którego elementami są potrzeby w najbardziej ogólnym znaczeniu, w zbiorze P istnieją dwa rozłączne podzbiory potrzeb zawierające: potrzeby uświadomione P u, potrzeby nieuświadomione P n. Zapis matematyczny zbioru potrzeb ma następującą postać: P = P u P n i P u P n = zbiór pusty (1) Dalszego podziału można dokonać tylko w podzbiorze potrzeb uświadomionych, które w interpretacji projektowej określa się jako zidentyfikowane P uz i niezidentyfikowane P un. Analogicznie do zapisu (1) podzbiór ma postać: P = P uz P un i P uz P un = zbiór pusty (2) Obszar potrzeb uświadomionych zidentyfikowanych jest obszarem najmniejszym wśród innych potrzeb. Rozszerzanie się obszarów potrzeb zależy od tempa rozwoju n a- uki i techniki. Rozpoznanie potrzeb jest procesem niekończącym się. Ze względów operacy j- nych przyjmuje się okresowe podsumowanie potrzeb uświadomionych, co równoznac z- ne jest z zakończeniem badań nad identyfikacją potrzeb. Błędem jest przedwczesne uznanie, że potrzeba jest dostatecznie zidentyfikowana. Od projektantów wymaga się otwartości na odbiór napływających danych oraz umiejętności selekcji informacji z tych danych, mających znaczenie jako istotny element opisu potrzeby. Przyjęcie ograniczonych horyzontów analizy jest zwykle przyczyną braków w identyfikacji potrzeby. Problem rozpoznawania jak i zaspakajania potrzeb jest funkcją zmian zachodzących w ot a- czającej rzeczywistości. 36

3 ARCHIWUM ODLEWNICTWA Bardzo ważne znaczenie ma identyfikacja potrzeb technicznych. Tego rodzaju potrzeby można sprowadzić do rozważenia następujących przypadków: istnieje potrzeba zmiany systemu polegającej na zmianie relacji pomiędzy środkami technicznymi lub też wymagane jest wprowadzenie zupełnie innych środków tec h- nicznych umożliwiających działanie na podstawie nowych relacji przekształceń wejść w wyjścia, potrzebne są uzupełnienia środków technicznych bez istotnej zmiany systemu. Tworzenie systemów wymaga identyfikacji potrzeb w funkcji czasu. Aktualność potrzeb w zidentyfikowanym czasie jest hipotezą, którą należy przyjąć, przystępując do projektowania. Generowane, w wyniku odpowiednich badań, potrzeby zidentyfikowane mogą stać się, po ich formalnym ujęciu, problemami projektowymi. W związku z tym można sformułować tezę, że identyfikacja potrzeb jest koniecznym warunkiem rozpoczęcia procesu projektowego. 3. FORMUŁOWANIE PROBLEMU PROJEKTOWEGO Ze zbioru potrzeb zidentyfikowanych należy wydzielić potrzebę p jako element zbioru, z której wynika problem projektowy PP do rozwiązania. Zapis jest następujący: p P uz ; p PP (3) przy czym znak reprezentuje zwrot ma zawsze następstwo. Procedura formułowania problemu projektowego polega na określeniu stanu p o- czątkowego (SWEJ), stanu końcowego (SWYJ) oraz funkcji F(SWEJ, SWYJ) systemu Z, który ma być przedmiotem projektowania. Funkcja F określa istotę działania systemu lub przeznaczenie tego działania, nie narzucając sposobu rozwiązania. Ogólne sformułowanie problemu podaje zależność: PP = {SWEJ, SWYJ, F(SWEJ, SWYJ)} (4) Znajomość funkcji F jest niezbędna, ale niewystarczająca do jednoznacznego określenia systemu Z, który zaspokoi potrzebę p. W rzeczywistości funkcję F(SWEJ, SWYJ) może spełnić wiele możliwych projektów R i, które tworzą zbiór realizacji nazywany przestrzenią swobody projektowania RF [4]. RF = {R 1, R 2,...,R V } (5) przy czym zawsze R i F(SWEJ, SWYJ) (6) 37

4 W projektowaniu technicznym można przyjąć, że SWEJ i SWYJ oraz dodatkowy zbiór ograniczeń C, które muszą być uwzględnione przy ocenie dopuszczalności ko n- cepcji projektowych określone są w skończonej przestrzeni identyfikatorów W = (w 1, w 2, w n ) (7) Identyfikatorem problemu jest dowolna wielkość wyrażona ilościowo lub jakościowo, oznaczająca warunek lub wymaganie. Uwzględniając identyfikatory, problem sformułowany szczegółowo, przyjmuje zapis w postaci: PP = {SWEJ, SWYJ, C, F(SWEJ, SWYJ)} (8) Tak sformułowany problem projektowy staje się zadaniem projektowym d o rozwiązania. 4. OBSZAR KONCEPCJI PROJEKTOWYCH Procedura rozwiązania zadania projektowego spełniającego potrzebę p prowadzi do wyznaczenia możliwych projektów realizujących funkcję F(SWEJ, SWYJ) systemu Z spełniających jednocześnie ograniczenia C. Zbiory potencjalnych projektów (koncepcji projektowych) określone są w innym niż stany wejścia i wyjścia oraz ograniczenia środowisku będącym skończoną przestrzenią dostępnych środków technicznych X, co można zapisać: X = (x 1,x 2,..., x m ) (9) W przestrzeni tej wyróżnić można niekoniecznie rozłączne podzbiory X i, stanowiące konkretne rozwiązania techniczne: X = (X 1,X 2,..., X m ) (10) Założyć należy, że istnieje szereg koncepcji projektowych zawartych w przestrzeni swobody projektowej RF, które stanowią swoiste odwzorowanie zbioru W w przestrzeń X. Zbiór tych rozwiązań nazywamy obszarem koncepcji projektowych OKP: OKP = (R 1, R 2,...R n ) (11) przy czym dla każdego i R i : W X i...(12) 38

5 ARCHIWUM ODLEWNICTWA Sprecyzowanie obszaru OKP jest równoznaczne z wyodrębnieniem projektowanego systemu z otoczenia. Działanie to ma charakter projektowania części w całości ze względu na całość, co w pełni odpowiada projektowaniu systemowemu w ujęciu zintegrowanym. 5. OCENA ROZWIĄZANIA PROJEKTOWEGO Wynikiem rozwiązania zadania projektowego jest wieloelementowy zbiór ro z- wiązań dopuszczalnych RD: RD OKP = {RD 1, RD 2,...RD N } (13) Z kolei, aby z tego zbioru wybrać rozwiązanie optymalne, konieczne jest określenie zbioru kryteriów cząstkowych oceny rozwiązania: przy czym V = {V 1, V 2,...,V m } (14) V i = f(rd) (15) które posłużą do określenia kryterium globalnego G: G = f(v 1, V 2,...,V m ) (16) Zbiór kryteriów tworzy system wartości J projektowanego systemu. J = {V, G} (17) Kryteria mają ścisły związek logiczny z jakością środka technicznego. Są fo r- malnym opisem potrzeby, wymagań i ograniczeń oraz są podstawą oceny wyników działania technicznego. 6. PODSUMOWANIE Formułowanie zadania projektowego powinno być niezbędnym etapem dowo l- nego procesu projektowania technicznego. Zadanie projektowe obejmuje zespół danych niezbędnych do prawidłowego i efektywnego projektowania, na które składają się: funkcja F, zbiór identyfikatorów W, obszar koncepcji projektowych OKP oraz system wartości J, co można zapisać: 39

6 PP = {F, W, OKP, J} (18) Przedstawione informacje dotyczące procesu formułowania i definicji zadania projektowego pozwalają wnioskować, że postępowanie takie ma na celu określenie projektowanego systemu w przestrzeni swobody projektowej (zbiór koncepcji), stworzenie prawidłowych podstaw dla poszukiwania rozwiązań dopuszczalnych i wyborze rozwiązania optymalnego. LITERATURA 1. R. L. Ackoff: Decyzje optymalne w badaniach stosowanych. PWN, Warszawa (1969). 2. D. Hall: Podstawy techniki systemów. PWN, Warszawa (1968). 3. K. M. Jaworski: Metodologia projektowania realizacji budowy. PWN, Warszawa (1999). 4. R. Wrona: Projektoznawstwo projektowanie odlewni. Wyd. AGH, Kraków (1996). SUMMARY SYSTEM FORMULATION OF THE PROJECT TASK The system procedure of the formulation of the project task was presented in this paper. The procedure consists of stages including: the investigation of requirements, the transformation of requirements into a project problem and problem into a project task. It was presented that there is a space of the project freedom and an area of the projects conceptions. Also the principles of evaluation of the solution of the project task were given. Praca naukowa finansowana ze środków KBN w latach jako projekt badawczy Recenzował: prof. dr hab. inż. Marcin Perzyk 40