Czym jest jakość oprogramowania

Wielkość: px
Rozpocząć pokaz od strony:

Download "Czym jest jakość oprogramowania"

Transkrypt

1 Czym jest jakość oprogramowania Radosław Hofman, EUR ING Abstrakt. Niniejszy artykuł przedstawia rozważania na temat definicji jakości oprogramowania odwołując się do historycznych publikacji oraz najnowszego modelu ISO/IEC JTC1/SC7. Dodatkowo w artykule znajdują się rozważania na temat postrzegania jakości przez użytkownika oraz ich ewaluacja. Na zakończenie autor przedstawia podsumowanie prezentujące różne spojrzenia na jakość oprogramowania oraz wstęp do dyskusji o potrzebie definiowania standardów rynkowych dla jakości oprogramowania, oraz cech przyszłych modeli jakości. 1. Wprowadzenie Produkty IT zwane potocznie oprogramowaniem zostały zdefiniowane i wyodrębnione spośród innych produktów w drugiej połowie XXw. Produkty te odróżniają się od większości obiektów wytwarzanych wcześniej przez człowieka z jednej strony są niematerialne, a z drugiej działają jako narzędzia w rzeczywistym i materialnym świecie. Z wytwarzaniem produktów od zawsze związane było pojęcie jakości produktu. Nie można dziś zbadać dokonań człowieka w zakresie porównywania jakości narzędzi i przedmiotów w epokach kamienia łupanego i kolejnych, jednakże pierwsze wzmianki o ocenie jakości płótna lnianego przypisywane są Egipcjanom, a datowane na XXI w.p.n.e.. Z kolei w kodeksie Hammurabiego z XVIII-XVII w.p.n.e. znajdujemy wzmianki o odpowiedzialności szkutnika i budowniczego w przypadku produktu o złej jakości [Kili1979]. W starożytnym Rzymie nazwano zasadę Caveat emptor, która w istocie jest również uregulowaniem problematyki jakości nabywanego produktu. 1 Analizując spojrzenie na jakość panujące już w czasach starożytnych należy wspomnieć o pismach Arystotelesa, który to postrzegał jakość jako jedną z 10 tzw. Kategorii. Jakość wg. tego filozofa to zbiór cech odróżniających rzecz od innych tego samego typu [Aryst1999]. W czasach średniowiecz pojawiła się po raz pierwszy udokumentowana rola zawodowa, którą dziś nazwanoby kontrolerem jakości na przełomie XII i XIII w. Jan, król Anglii zatrudnił niezależnego eksperta Williama Wrotham aby w jego imieniu sprawował kontrolę nad produkowanymi na zamówienia króla statkami. W czasach nowożytnych problematyka jakości i kontroli jakości opisana jest niemalże wyczerpująco. Powstały różne podejścia do zapewnienia i kontroli jakości opisane zarówno w standardach ISO, normach krajowych jak i publikacjach z zakresu SPC (Statistical Process Control), SQC (Statistical Quality Control), TQM (Total Quality Management), Six Sigma itd. Podejścia te opisują metody planowania procesów zapewniających możliwość produkcji wysokiej jakości produktów oraz metody 1 łac. niech kupujący strzeże się

2 Czym jest jakość oprogramowania 2 kontroli jakości procesów i produktów. Metody te są bardzo powszechnie implementowane w przemyśle, a funkcjonujące automatyczne linie produkcyjne wyposażane są w stanowiska automatycznej kontroli jakości. Tematyka jakości jest na tyle dynamiczną dziedziną, że spowodowała powstanie nowej dyscypliny badawczej kwalitologii [HamMan2002]. Kwalitologia jest interdyscyplinarnym obszarem badań pomiędzy teorią jakości a inżynierią jakości obejmującą kwalimetrię, zarządzanie jakością i ekonomikę jakości [Jag2004]. Czym jest jakość w odniesieniu do jakiegoś obiektu? Większość definicji w literaturze odnosi jakość do konkretnego modelu lub obszaru stosowalności obiektu, dla jakiego jakości jest definiowana. Jakość można zatem zdefiniować jako zdolność obiektu do spełnienia zdefiniowanych i dorozumianych potrzeb w określonym kontekście użycia. Definicja ta jest bardzo szeroka, stąd też pozostawia duże pole do analizy znaczeniowej. Takie definicje jakości pojawiają się zarówno w normach ISO [ISO/IEC 9126:2001, ISO/IEC 25000] oraz literaturze [Kili1979]. W przypadku oprogramowania komputerowego, które jak wspomniano powyżej, różni się znacząco od innych produktów wytwarzanych przez człowieka sytuacja z jednej strony jest analogiczna do innych produktów, a z innej perspektywy zupełnie inna. Po pierwsze oprogramowanie jest bytem niematerialnym. Jako taki byt posiada szereg cech statycznych i dynamicznych. W odróżnieniu od innych produktów, w przypadku oprogramowania cechy statyczne są niemalże pomijalne w aspekcie jakości oprogramowania. Z punktu widzenia użytkownika można powiedzieć, że oprogramowanie tak samo jak inne produkty posiada określoną zdolność do zaspokajania potrzeb użytkownika, co czyni je produktem o podobnych właściwościach do innych produktów. Proces wytwarzania oprogramowania w sposób zasadniczy różni się od sposobu wytwarzania produktów materialnych. Co za tym idzie, proces zapewnienia i kontroli jakości oprogramowania różni się istotnie od procesów zapewnienia i kontroli jakości innych produktów. Główna różnica polega na powtarzalności zadań w przypadku wytwarzania oprogramowania mamy do czynienia z fazą analogiczną do wytwarzania prototypu przedmiotu przemysłowego (nowa analiza, nowy projekt, nowe wykonanie), gdy tymczasem przytoczone wcześniej podejścia i normy określają zasady zapewnienia i kontroli jakości w powtarzalnych czynnościach. Pierwsze wzmianki o zapewnianiu jakości pojawiły się w publikacjach dotyczących Inżynierii Oprogramowania pojawiają się w literaturze lat 1960, gdzie IBM oraz Departament Obrony USA zdefiniowały po raz pierwszy takie pojęcie [Voa2003]. Od tamtej pory zdefiniowano wiele modeli

3 Czym jest jakość oprogramowania 3 jakości oprogramowania, a najważniejsze z nich zostaną omówione w rozdziale. W chwili obecnej trwają prace nad modelem SQuaRE, który wyrażany jest w normach ISO/IEC W wielu pozycjach w literaturze jakość oprogramowania jest wiązana z jakością procesu wytwarzania oprogramowania, choć są i takie pozycje które wyraźnie zaznaczają, że jakość procesu nie ma wpływu na jakość produktu [Dromey1996, KitPfle1996]. Trzecim istotnym punktem widzenia jest relacja dojrzałości organizacji i jakości produktów związek taki jest prezentowany w samym modelu CMMI oraz [Eic2003, DiaSli1997]. Wszystko o czym wspomniano do tej pory w tym artykule dotyczy inżynierskich definicji, pojęć i formuł. Czy takie pojęcia pozwalają na ostateczne zdefiniowanie sposobu postrzegania jakości oprogramowania przez Klienta i użytkownika? Czy da się zwymiarować potrzeby odbiorców, w taki sposób aby jednoznacznie obliczyć poziom ich zaspokojenia? A może same potrzeby są niejednorodne i mają wiele niezbadanych cech skazując wszystkie modele na oderwanie od rzeczywistości. W niniejszym artykule, w rozdziale znajduje się zalążek rozważań na ten temat, jednakże należy się spodziewać jego intensywnej eksploracji w najbliższych latach. Abstrahując od sposobu wytwarzania oprogramowania i subiektywizmu wynikającego z odczuć odbiorcy oprogramowania można podjąć próbę zdefiniowania standardów jakości dla oprogramowania prezentując różne punkty widzenia, co zostanie przedstawione w rozdziale. Dodatkową motywacją do zdefiniowania lub odnowienia modelu jest fakt zmiany sposobu korzystania z oprogramowania. Dziś zamiast oprogramowania coraz częściej mówi się o kompozycie usług świadczonych drogą elektroniczną, a co za tym idzie, kryteria jakości takie jak: łatwość instalacji, koszt utrzymania itp. nie mają jakiegokolwiek zastosowania, z kolei pojawiają się nowe obszary definiujące użyteczność, czy jakość takiej usługi. 2. Modele jakości 2.1. Historyczne modele jakości McCall 1977 i Boehm 1978 Jedynymi z pierwszych modeli w literaturze są modele McCall z 1977 roku [McCa1977] i Boehm z 1978 roku [Boe1978, Pfle2001]. Model McCall, postrzegany jako ogólna koncepcja trudna do zastosowania w praktyce, wprowadza zestaw oczekiwanych charakterystyk jakości, oraz pokazuje zestaw atrybutów/metryk, które na ową jakość mają wpływ. Model ten koncentruje się na cechach technicznych produktu.

4 Czym jest jakość oprogramowania 4 Model Boehm zmienia punkt widzenia jakości oprogramowania przenosząc punkt ciężkości na perspektywę użyteczności oprogramowania. Według [Pfle2001] jest to pierwsze wskazanie, że jakość oprogramowania może być postrzegana tylko wtedy, kiedy oprogramowanie jest użyteczne ISO 9126:1991 Standard ten miał definiować charakterystyki jakości oraz być przewodnikiem dotyczącym sposobu ich oceny. Dosyć szybko model opisany w tej normie stał się wyznacznikiem sposobu definiowania jakości oprogramowania [BAJ1993]. Model opisany w normie określał 6 głównych charakterystyk jakości: funkcjonalność (functionality), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintanability), przenośność (portability). Norma nie spełniła pokładanych w niej nadziej [Pfle2001], głównie ze względu na ograniczenie się do perspektywy producenta, brak stanowiska w sprawie całościowej oceny jakości oraz brak dokładnych wytycznych jak należy mierzyć poszczególne parametry jakości Kitchenham & Pfleeger 1996 W swojej publikacji [KitPfle1996] autorzy nie definiowali nowego modelu jakości, ale podsumowali spojrzenia na jakość i ich ewolucję wyróżniając pięć różnych perspektyw: jakość jako pojęcie metafizyczne, nieosiągalny ideał do którego zmierzamy jakość z punktu widzenia użytkownika jako odniesienie cech produktu do interesującego użytkownika kontekstu użycia jakość z punktu widzenia producenta jako zgodność z wymaganiami (analogiczny do spojrzenia ISO 9001:1994 jakość jako atrybut produktu wynikająca z konkretnych wyników pomiaru charakterystyk produktu ostatecznie jakość postrzegana jako wartość różna dla różnych grup interesariuszy Autorzy podkreślali również, że jakość produktu jest zjawiskiem niezależnym od jakości samego procesu wytwórczego ISO/IEC 9126:2001 Norma ISO/IEC 9126 z 2001 roku w sposób istotny zmieniła rozumienie modelu jakości oprogramowania zaprezentowane w jej poprzednim wydaniu. Norma rozróżnia trzy poziomy jakości i co za tym idzie definiuje 3 zbiory charakterystyk: jakość wewnętrzna/statyczna (internal quality) jakość zewnętrzna/dynamiczna (external quality) jakość użyteczna (in use quality)

5 Czym jest jakość oprogramowania 5 Model zdefiniowany w normie pokazuje również różne aspekty jakości dyskutowane we wcześniejszych modelach, czyli jakość produktu, jakość techniczną produktu, a jakość procesu, tak jak to widać na rysunku. Process Software products Effect of software product Influences Influences Influences Process quality Internal quality attributes External quality attributes Depends on Depends on Depends on Quality in use attributes Contexts of use Process measures Internal measures External measures Quality in use measures Rys. Jakość w cyklu życia systemu [ISO/IEC 9126:2001] Każdy z tych obszarów ma odmienne znaczenie i odmiennego interesariusza. Wewnętrzna i zewnętrzna jakość definiowana jest jako suma następujących charakterystyk (analogicznych do poprzedniego wydania normy 9126): funkcjonalność (functionality), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintainability), przenośność (portability). Jakość użyteczna definiowana jest jako suma następujących charakterystyk: przydatność (effectiveness), produktywność (productivity), bezpieczeństwo (safety) i zdolność do zaspokojenia potrzeb (satisfaction) ISO/IEC 25000:2005 Model nazywany Drugą Generacją Standardów Jakości - SQuaRE (Software product Quality Requirements and Evaluation) [SurAbr2003] publikowany w serii norm ISO/IEC Zestaw norm nie tylko porządkuje model oceny jakości oprogramowania opisany w ISO/IEC 9126:2001, model procesu ewaluacji oprogramowania opisany w ISO/IEC 14598, ale w sposób istotny go rozszerza. Na najwyższym poziomie modelu jakości oprogramowania pozostawiono podział na jakość wewnętrzną, zewnętrzną i użyteczną. Jakość wewnętrzna i zewnętrzna oprogramowania zdefiniowana jest analogicznie do definicji w ISO/IEC 9126:2001, z tym że zmieniono charakterystyki wysokiego poziomu zamiast sześciu w nowym modelu jest osiem: funkcjonalność (functionality), poufność

6 Czym jest jakość oprogramowania 6 (security), zgodność techniczna (interoperability), niezawodność (reliability), użyteczność (usability), wydajność (efficiency), łatwość utrzymania (maintainability) i przenośność (portability). Jakość użyteczna oprogramowania, została zdefiniowana na nowo w modelu SQuaRE. Jej główne charakterystyki to: użyteczność (usability in use), zgodność z kontekstem (context in use), bezpieczeństwo (safety in use), poufność (security in use) i łatwość użycia (adaptability in use). Modele jakości SQuaRE opisują zarówno oprogramowanie, jak i dane. Twórcy normy zauważają, że nie są to jedyne modele jakości dla bytu nazywanego systemem, lecz norma odnosi się tylko do wspomnianych modeli. Na rysunkach i pokazano mapowanie modeli jakości SQuaRE na model systemu, oraz cykl życia jakości w ramach rozwoju produktu jakim jest oprogramowanie. QUALITY MODELS Internal software quality External software quality Software impact on system quality in use Software quality model Data quality model Quality in use model System Information system Computer system n Computer system 1 Commun -ication Human business process Mechanical system Computer hardware Other software Target software Other data Target data Users Rys Odniesienie modeli SQuaRE do jakości elementów systemu [ISO/IEC CD]

7 Czym jest jakość oprogramowania 7 REQUIREMENTS PRODUCT Needs User quality needs Quality in use Use and feedback Contribute to specyfying Indicates External quality requirements Contribute to specyfying Validation and verification External quailty Indicates Internal quality requirements Verification Internal quality Implementation Rys. Cykl życia jakości produktu jakim jest oprogramowanie [ISO/IEC CD] 2.2. Literatura w Polsce W literaturze dostępnej w Polsce bardzo często jakość produktu utożsamiana jest z jakością procesu, w którym produkt ten powstaje. W [Beg1999] autorka wręcz stwierdza się, że nie można mówić o jakości produktu, jeżeli nie mówi się o jakości procesów. W innych pozycjach, np. [Jasz1997] autorzy proponują własne charakterystyki jakościowe dla oprogramowania. W wydanych tego samego roku zasadach organizacji projektowania, wdrażania i eksploatacji systemów informatycznych w Resorcie Obrony Narodowej [MON1999] o aspektach jakościowych wymagań dla systemów praktycznie nie ma wzmianki. Autorzy zaznaczają jednakże, że podstawowym wymaganiem dla systemu jest potwierdzenie jego bezpieczeństwa w aspektach poufności, integralności i dostępności danych. Podstawą odbioru i oceny systemu, którą to można rozumieć jako ocenę jakościową, jest całość rozwiązania rozumianego jako aspekty informacyjne, funkcjonalne, organizacyjne, technologiczne i techniczne. Inaczej mówiąc dla systemów realizowanych na potrzeby obronności kluczowym nie jest charakterystyka systemu jako takiego, ale charakterystyka systemu i jego otoczenia umieszczonego w konkretnym środowisku oraz przydatność

8 Czym jest jakość oprogramowania 8 i efektywność tak przygotowanego systemu. Pomimo, że w czasie kiedy dokument powstawał obowiązująca postać normy ISO 9126:1991 koncentrowała się na aspektach technicznych oprogramowania, to ich postrzeganie jakości jest zbieżne z obecnym rozumieniem prezentowanym w ISO/IEC (patrz rys. ). W publikacjach [Beg2003], [Koby2003] i [Koby2005] autorzy opisuje nową wersję normy ISO/IEC 9126:2001, podkreślając jednocześnie rozróżnienie pomiędzy jakością wewnętrzną i zewnętrzną, rozumianą jako jakość techniczną obiektywnie mierzalną, od jakości użytecznej, która jest subiektywnym postrzeganiem przez użytkownika jakości produktu, jednakże główną uwagę poświęcają aspektom technicznym oprogramowania (czyli wynikającym z poprzedniej wersji normy). W pracy doktorskiej z 2000 roku [Dymek2000] autor zauważa rozdźwięk pomiędzy jakością techniczną i marketingową oprogramowania. Jakość techniczna to według autora głównie jakość wykonania, a jakość marketingowa to jakość postrzegana przez klienta (profil sensoryczny). Autor wspomnianej pracy dodatkowo wprowadza kilka klas aktorów zaznaczając, że ich postrzeganie jakości i oczekiwania są różne. W stosunku do proponowanego w niniejszej pracy zestawu autor dzieli użytkowników na 3 grupy: pracowników merytorycznych, pracowników IT, kierowników niższego szczebla. Dodatkowo autor podaje przykład na zmienność postrzegania jakości w czasie argumentując, że w pierwszej fazie eksploatacji dla użytkownika kluczowa jest łatwość uczenia się oprogramowania, a po jego dobrym Poznaniu kluczowa staje się przeciwstawna według autora cecha czyli bogactwo funkcji. W [Koby2005] autor również podkreśla, że spojrzenie na jakość ewoluuje w czasie trwania projektu, który rozpoczyna się zazwyczaj obustronnym spojrzeniem na jakość jako jakość idealną do punktów widzenia jakości ukierunkowanej na użytkownika po stronie odbiorcy oprogramowania oraz jakość ukierunkowaną na wytwórcę po stronie dostawcy. W pracy pojawiają się zatem perspektywy użytkownika, klienta, dostawcy, programisty i osoby odpowiedzialnej za utrzymanie oprogramowania Standardy dla procesu kontroli jakości Jako, że głównym tematem artykułu jest jakość produktu możnaby zupełnie pominąć kwestię standardów dla procesu wytwarzania i kontroli jakości. Niemniej jednak dla kompletności obrazu należy wspomnieć, że takie standardy również istnieją i opisane są w odpowiednich normach. W aspekcie kontroli jakości standardy były opisane zarówno w ISO 9126:1991, następnie w ISO/IEC 14598:1998, a obecnie stały się częścią modelu SQuaRE i są opisane w normie ISO/IEC Norma nakłada na proces ewaluacji następujące wymagania:

9 Czym jest jakość oprogramowania 9 należy określić cele ewaluacji należy określić mierzone charakterystyki i oczekiwane miary należy dobrać metody i narzędzia dające wiarygodny pomiar charakterystyk jakościowych należy wykonać ewaluację zgodnie z planem po wykonaniu ewaluacji należy zagregować wartości pomiarów i zweryfikować z założonymi wcześniej wartościami 2.4. Podsumowanie modeli jakości Jak widać z lektury modeli jakości oprogramowania, modele były ściśle związane z określoną perspektywą patrzenia na jakość. Perspektywy opisane w [KitPfe1996] określają różne wymiary jakości jako wymiar użytkownika, producenta, produktu jako takiego, oraz wartości zmierzonej. Z kolei w normach ISO/IEC 9126:2001 i ISO/IEC rozróżnia się 3 poziomy jakości: wewnętrzną, zewnętrzną i użyteczną. Należy rozważyć, czy modele jakości opisane w poprzednim rozdziale wyczerpują różne perspektywy jakie można przypisać aktorom, czyli osobom mającym związek z oprogramowaniem. Biorąc pod uwagę model zarządzania usługami IT (ITIL) [OGC2000], traktujący oprogramowanie szerzej niż tylko jako produkt, a mianowicie postrzegając oprogramowanie wraz z jego dynamicznym udostępnieniem jakości jako jeden byt zwany usługą, wprowadza pojęcia następujących klas aktorów: 1. Dostawca IT przedstawiciel firmy zajmującej się utrzymaniem usług IT, 2. Klient właściciel biznesowy podejmujący decyzję o potrzebach oraz ograniczeniach ekonomicznych, 3. Użytkownik osoba korzystająca z usługi IT Ten podział nie jest odległy od opisanych wcześniej modeli, jednakże po wprowadzeniu pojęcia usługi IT należy zauważyć, że pod pojęciem Dostawcy IT, kryje się szereg ról, których postrzeganie jakości może być zupełnie inne: 4. Właściciel - klasa przedstawicieli producenta których celem jest maksymalizacja ekonomicznych aspektów związanych z wytwarzaniem/rozwojem/utrzymaniem oprogramowania, 5. Deweloper - przedstawiciele producenta będący osobiście zaangażowani w proces wytwarzania oprogramowania, 6. Operator/Serwisant - przedstawiciel wykonawcy, dostawcy usługi IT lub wewnętrznego IT Klienta będący osobiście zaangażowany w proces utrzymania działającego oprogramowania.

10 Czym jest jakość oprogramowania 10 Twierdzenie, że każda z powyższych klas aktorów postrzega jakość oprogramowania w inny sposób jest oczywistością. W poniższej tabeli nakreślono główne (w sposób nie wyczerpujący) aspekty jakości oprogramowania istotne dla danej klasy aktorów: Aktor Klient (Acquirer) Użytkownik (User) Właściciel IT (Supplier) Deweloper (Developer) Operator/Serwisant (Operator/Maintainer ) Główne cechy jakości Całkowity Koszt Utrzymania, użyteczność Użyteczność, ergonomia Koszt całkowity wytworzenia i utrzymania, przychody związane z oprogramowaniem Prostota technologiczna, przejrzystość części wewnętrznej Niezawodność oprogramowania, łatwość instalacji i odtworzenia Tabela Perspektywy jakości oprogramowania względem aktorów Rozważając czy powyższa tabela jest wyczerpująca i oddaje wszystkie możliwe spojrzenia na jakość oprogramowania należy oczywiście odpowiedzieć, że nie. Niemniej jednak obserwując rozwój rynku IT oraz rosnący poziom organizacji wewnętrznej dostawców, należy spodziewać się, że zmierzanie rynku w stronę rosnącej liczby usług świadczonych w oparciu o infrastrukturę IT, modele jakości będą rozróżniały co najmniej powyższą listę perspektyw. Jakie będą przyszłe spojrzenia na modele jakości ze względu na rodzaje oprogramowania (z półki, na zamówienie, usługi świadczone przez sieć)? Otóż wschodzącą gwiazdą na rynku IT stają się usługi publiczne świadczone drogą elektroniczną. Usługi te różnią się od usług dedykowanych tym samym czym oprogramowanie powielane od oprogramowania dedykowanego. Dostawca i użytkownik stają się anonimowi, nie negocjują SLA (Service Level Agreement), nie rozliczają się w oparciu o przedyskutowane raporty. Niemniej jednak należy definiować i mierzyć jakość oprogramowania bazującego na takich usługach i to uwzględniając wszystkie perspektywy aktorów opisanych w rozdziale. Usługi te zostaną zbudowane w oparciu o oprogramowanie mające swoją jakość wewnętrzną, zewnętrzną i użyteczną. Całościowa jakość z punktu widzenia użytkownika będzie jednak czymś więcej. Autorzy modelu SQuaRE również zauważyli tą tendencję i ten przyszły model jakości nazwali Quality in use odróżniając jakość użyteczną oprogramowania jako Software quality in use.

11 Czym jest jakość oprogramowania Postrzeganie jakości 3.1. Subiektywizm w ocenie oprogramowania Wiele zjawisk obserwowanych przez człowieka daje się obiektywnie zmierzyć. Możemy na przykład porównać masę 2 obiektów, porównać ich długość itd. Możliwość wykonywania obiektywnych pomiarów jest cechą przypisywanym zjawiskom fizycznym. Oprogramowanie, a tym bardziej jego jakość jest bytem niematerialnym i stąd też stosowanie znanych w fizyce miar wydaje się być skazanych na niepowodzenie. Spoglądając na definicję jakości przytaczaną w poprzednim rozdziale: Jakość to zdolność przedmiotu do zaspokojenia zdefiniowanych i dorozumianych potrzeb [ ] [ISO/IEC 9126:2001, ISO/IEC 25000]. W tej definicji zaszyte jest twierdzenie, że kluczem do postrzegania jakości są potrzeby użytkownika zarówno te zdefiniowane, jak również te które są oczywiste i nie definiowane. Jedną z najbardziej znanych prac odnoszących się do analizy potrzeb człowieka jest piramida potrzeb wg Maslowa [Mas1943]. Maslow podzielił potrzeby na potrzeby niższego rzędu (typu D) charakteryzujące się tym, że człowiek nie zdaje sobie sprawy z ich istnienia dopóki są zaspokojone (np. potrzeby fizjologiczne) oraz potrzeby wyższego rzędu (typu B) pojawiające się w sytuacji zaspokojenia potrzeb niższego rzędu, charakteryzujące się nie wygasaniem wraz z ich zaspokajaniem. Podobne zjawisko zaobserwowali filozofowie i ekonomiści zajmujący się pojęciem wartości dziesiątki lat przed Maslowem, a ich prace zaliczane są do tzw. marginalizmu [Sti1972]. W XIX w. Austrii powstał nurt ekonomii nazywany szkołą psychologiczną, którego przedstawiciele dokonali ważnych obserwacji w obszarze potrzeb i ich zaspokajania. Herman Heinrich Gossen sformułował tzw. prawo malejącej użyteczności krańcowej, które sprowadza się do stwierdzenia, iż kolejne jednostki danego dobra mają coraz mniejszą przydatność dla nabywcy [Gos1854]. Klasycznym przykładem jest szklanka wody, której wartość dla człowieka maleje wraz z poziomem zaspokojenia pragnienia, aż do momentu kiedy nabycie kolejnej szklanki wody nie jest warte najmniejszego kosztu. Jak więc zauważyli następcy Gossena siła potrzeby zależy nie tylko od jej rodzaju ale również od bieżącego poziomu zaspokojenia i poziomu jej pilności [Wie1889]. Czy podobnie jest z cechami jakościowymi oprogramowania? Czy, o ile istnieją potrzeby jakości związane z oprogramowaniem, ich zaspakajanie prowadzi do zmniejszenia ich wartości? Jeżeli tak, to oznaczałoby, że dla nabywcy oprogramowania największe znaczenie mają cechy, które dotychczas nie były zaspokojone, a w trakcie długotrwałego użytkowania wady i braki jakościowe przysłaniają zalety oprogramowania. Zastanawiając się nad tym w jaki sposób człowiek postrzega jakość produktu nie sposób nie zauważyć, że większość psychologów i neuro-psychologów rozróżnia trzy poziomy świadomości i układów mózgu [MaKr1973]. Podążając za nazewnictwem Zygmunta Freuda mamy zatem Id obszar odpowiedzialny za prymitywne odruchy, Ego obszar emocji i Superego obszar rozumnego postrzegania świata [Fre1923]. Freud zauważył również, że człowiek postrzega świat głównie warstwą podświadomą, co z kolei potwierdza pewien brak racjonalizmu przy wydawaniu opinii np. o jakości.

12 Czym jest jakość oprogramowania 12 Warto wspomnieć jeszcze o dwóch filozofach: Immanuelu Kancie, który budując teorię postrzegania stwierdził, że człowiek posługuje się apriorycznymi poglądami i wiedzą, która powoduje, że zamiast postrzegać rzeczywistość postrzega tylko swoje poglądy i zamiast poznawać rzeczywistość poznaje samego siebie [Cas1981]. David Hume z kolei prowadził badania na temat źródła pochodzenia poglądów człowieka. W czasie swoich obserwacji zauważył, że ludzie mają naturalną tendencję do odrzucania obserwacji niezgodnych z pozostałymi, lub niezgodnych z tym w co wierzą [Str1977]. Współczesna psychologia potwierdza powyższe obserwacje formułując tezę, że wszystko co postrzega człowiek jest jedynie interpretacją stanu jego umysłu [LSF2000]. Jakie jeszcze cechy ludzkiej psychologii mogą wpływać na percepcję oprogramowania? Wydaje się, że najczęściej spotykanymi w organizacjach są: konformizm i podążanie za autorytetami pracownicy firmy w nielicznych sytuacjach pozwalają sobie na inne poglądy niż reszta zespołu lub niż wybitni eksperci. Co więcej ludzie w naturalny sposób ograniczają swoje chęci poznania przyjmując pierwszą obserwację/hipotezę odpowiadającą ich oczekiwaniom jako wystarczająco dobrą i odrzucając potrzebę jej weryfikacji [Kel1958]. Wniosek z powyższych rozważań pokazuje jak bardzo złożonym pojęciem jest postrzeganie jakości oprogramowania. W kontekście definicji bazującej na zaspokojeniu potrzeb, a idąc dalej w kontekście postrzegania przez odbiorcę, że jego potrzeby zostały zaspokojone niewiele udało się do obecnej chwili zbadać i ustalić. Niniejszy artykuł przedstawia kilka wstępnych obserwacji, które będą badane w przyszłości Charakterystyki i pomiar jakości Charakterystyki jakości jako konsekwencja potrzeb Jakość, jak to zostało opisane w poprzednim rozdziale definiowana jest jako szereg charakterystyk, z których dla każdej określa się pod-charakterystyki i atrybuty, a następnie z nimi wiąże się sposób pomiaru. Ponieważ jednak w tym rozdziale rozważania dotyczą rozszerzonego pojęcia jakości należy zadać pytanie, czy i które atrybuty reprezentują potrzeby użytkowników. Przyjmując model SQuaRE [ISO/IEC 25000:2005]jako ustalony zbiór charakterystyk oraz punkt widzenia jakości użytecznej należy skupić uwagę na następujących sześciu charakterystykach. Zastanówmy się jakie potrzeby mogą być związane z każdym z tych atrybutów: użyteczność (usability in use) przykładem potrzeby może być potrzeba zwiększenia produktywności, obniżenia kosztów pracy, zwiększenia satysfakcji z użytkowania itd. zgodność z kontekstem (context in use) przykładem potrzeby może być zgodność ze specyfiką wykonywanych zadań bezpieczeństwo (safety in use) przykładem potrzeby może być potrzeba ochrony własnych pracowników, ochrony obiektów oraz przeciwdziałanie zagrożeniom dla tychże poufność (security in use) tu potrzeba koncentruje się na przeciwdziałaniu ryzyku ujawnienia wrązliwych danych

13 Czym jest jakość oprogramowania 13 łatwość użycia (adaptability in use) potrzebą uzasadniającą ten kontekst jest potrzeba łatwego wdrażania nowych pracowników i realizowania nowych funkcji w systemie Widać zatem, że do każdej charakterystyki daje się dopasować potrzebę, jednakże w większości przypadków są to potrzeby wyższego rzędu (typu B) z punktu widzenia potrzeb człowieka (poza zapewnieniem bezpieczeństwa, które można powiązać z typem D w przypadku zapewniania bezpieczeństwa sobie i osobom najbliższym). Jakie są konsekwencje tej obserwacji? Otóż zgodnie z teorią Maslowa powyższe potrzeby mogą być specyfikowane, rozumiane i właściwie postrzegane może być ich spełnienie jeżeli osoba oceniająca jest w stanie zaspokojenia innych swoich potrzeb, lub, na co wskazują badania, jest na tyle wyedukowana, aby takie potrzeby rozumieć. Kolejną ciekawą obserwacją odnoszącą się do potrzeb jest ich ważność wynikająca z bieżącego doświadczenia osoby oceniającej, specyfikującej wymagania oraz aktualnego poziomu zaspokojenia tych potrzeb [Wie1889]. Jeżeli przykładowo stabilność oprogramowania nigdy nie była problemem dla użytkownika definiującego wymagania nie będzie takiego wymagani wskazywał, a wręcz uważał je za nadmiarowe. Z drugiej strony użytkownik spragniony stabilności może przedkładać to wymaganie ponad wszystkie pozostałe. Siłę niezaspokojonych potrzeb oraz charakterystykę ich nasycania należałoby gruntownie zbadać Manifestowane charakterystyki jakości Interesującym i ważnym podziałem charakterystyk jakości jest podział, ze względu na możliwość obserwacji przez użytkownika. Istnieją cechy, które w sposób oczywisty można obserwować jak choćby zrozumiałość interfejsu, szybkość działania, produktywność etc. Jednakże definicje jakości oprogramowania nie ograniczają jego definicji do takich charakterystyk, które użytkownik może samodzielnie obserwować. Przykładowo poufność danych, niezawodność, odtwarzalność w przypadku awarii pozostają w sferze domniemania użytkownika. Czy takie cechy, choć nie mierzalne mają wpływ na ocenę użytkownika i satysfakcję z posiadanego oprogramowania? Naturalnie. Dobrym przykładem mógłby być użytkownik, który był zadowolony z oprogramowania do czasu, kiedy dowiedział się, że jego działanie jest niezgodne z jakimś mało znanym przepisem, który jednak jest na tyle ważny, że dyskwalifikuje działające rozwiązanie. Badania cech jakości innych niż oprogramowanie produktów wskazują, że cechy domniemane w umiarkowany sposób poprawiają zadowolenie użytkownika z oprogramowania, natomiast nie spełnione potrafią wpływać na niezadowolenie z rozwiązania silniej niż cechy manifestowane [Ste1989]. Czy produkt jakim jest oprogramowanie podlega takim samym zależnościom? Wydaje się, że tak, aczkolwiek wymaga to przeprowadzenia szeregu badań Zmiana percepcji w czasie Postrzeganie jakości w cyklu posiadania oprogramowania podlega ciągłym zmianom. Wcześniej wspomniano, że w początkowej fazie znaczenie ma łatwość nauczenia się i posługiwania się

14 Czym jest jakość oprogramowania 14 systemem, a w kolejnych zaspokajanie innych potrzeb. Na użytek niniejszego artykułu podzielono cykl posiadania oprogramowania na: etap poprzedzający zakup, wdrożenie, eksploatacja, zmiana do oprogramowania oraz wycofanie, z tym że ostatni etap nie jest już opisany, z racji tego że postrzeganie jakości produktu w tym czasie nie ma praktycznego znaczenia, choć oczywiście oprogramowanie wciąż jest oceniane Etap wyboru, zakup i wdrożenie Proces zakupowy zgodnie z większością publikacji w tym obszarze rozpoczyna się od uświadomienia sobie potrzeby po którym następuje zbieranie informacji o możliwościach [KH2007]. Tu pojawiają się dwie istotne grupy wydarzeń w znacznym stopniu determinujące postrzeganie jakości w początkowych fazach użytkowania systemu. Po pierwsze dostawcy oprogramowania starają się uświadamiać użytkownikom ich potrzeby sprawiając, że dotychczas używane rozwiązania tracą wartość w oczach użytkowników. Po drugie rozbudzają nadzieję na wyższy poziom zaspokojenia wszystkich potrzeb użytkowników (czyli powiększenie dotychczasowego poziomu zaspokojenia potrzeb). Procesy powyższe zachodzą w różnym stopniu wśród różnych decydentów. W szczególności można wyróżnić dwie skrajności osoby oczekujące na nowe rozwiązanie jako spełnienie ich wszystkich (również nowo-uświadomionych) potrzeb oraz osoby, które są z założenia niechętne zmianom, ponieważ stopień zaspokojenia ich potrzeb jest na tyle wysoki, że nie są w stanie przeciwstawić wysiłku i ryzyka wkładanego w pozyskanie nowego rozwiązania przeciw potencjalnemu wzrostowi satysfakcji z używania systemu. Co więcej osoby decydujące o ważności cech przyszłego oprogramowania kierują się bieżącym poziomem braku zaspokojenia i bieżącymi potrzebami uznając najpilniejsze za najważniejsze, odkładając przyszłe potrzeby na dalszy plan [Wie1889]. W czasie testów akceptacyjnych następuje pierwsza konfrontacja systemu z oczekiwaniami (nierzadko stymulowanymi w procesie handlowym). Konfrontacja ta odbywa się również w sytuacji, kiedy oprogramowanie (czy to z półki, czy budowane na zamówienie) jest do tego najmniej przygotowane, bo ma najniższy w historii współczynnik zgodności z docelowym kontekstem użycia i nierzadko działa jak torowanie (priming) w świadomości oceniających. W efekcie użytkownik bardzo szybko przyjmuje za obowiązującą opinię, że oprogramowanie jest niezgodne z wymaganiami. Taki sposób rozumowania jest typowy dla sposobu postrzegania i uczenia się świata przez ludzi [KW2003] i dotyczy również poznawania jakości oprogramowania Eksploatacja Niezależnie od problemów w trakcie testów po wdrożeniu i rozpoczęciu eksploatacji oprogramowania pojawia się kolejny rozdźwięk pomiędzy potrzebami, a ich zaspokojeniem. Okazuje się, że potrzeby, na które użytkownik nie zwracał uwagi w trakcie wyboru rozwiązania były i są krytycznie ważne dla prowadzonej działalności, a ponieważ do tej pory były zaspokojone, to zgodnie z pierwszym prawem

15 Czym jest jakość oprogramowania 15 Gossena [Gos1854] zwartościowano je jako mniej istotne. Ich niezaspokojenie pokazuje jednak jak bardzo są ważne Zmiana Naturalnym elementem cyklu posiadania oprogramowania jest podejmowanie decyzji o zmianie, rozszerzeniu posiadanej infrastruktury, funkcjonalności. Proces ten składa się podobnie jak proces zakupu z uświadomienia potrzeby i zebrania informacji. Pojawia się pewna delta w spodziewanej jakości oprogramowania (lepiej zaspokoi potrzeby), oraz koszt jej wykonania. Zakładając, że jest to delta mogąca zmieniać kompozycję nasycenia wszystkich potrzeb należy przyjąć, że zmiana może zarówno poprawiać satysfakcję i zaspokojenie pewnych potrzeb, jak i pogarszać zaspokojenie innych potrzeb. Analogicznie jak to ma miejsce przy zakupie przy wartościowaniu zmiany decydenci ulegają wrażeniu, że zaspokojone potrzeby są mniej istotne, co może prowadzić do akceptacji faktu obniżenia ich zaspokojenia Jakość postrzegana - podsumowanie Podsumowując niniejszy przegląd filozoficznych i psychologicznych spojrzeń na produkt jakim jest oprogramowanie w kontekście zaspokojenia potrzeb użytkownika należy stwierdzić, że obszar ten wymaga badań. Budowa obiektywnych klasyfikatorów jakości, które byłyby w stanie określić jaką ocenę jakości oprogramowania w czasie będzie wydawała konkretna osoba wymaga takich narzędzi jak model potrzeb użytkownika, model zmienności potrzeb użytkownika oprogramowania w czasie itd. Proste podsumowanie rozważań Gossena i Maslowa prowadzi do wniosku, że użytkownik uświadamia sobie głównie niezaspokojone potrzeby i te najpilniejsze stają się najważniejsze, co z kolei prowadzi do niezauważana pozytywnie zaspakajających potrzeby cech oprogramowania, a zatem ocena jakości użytkownika ma tendencję do bycia negatywną, co oczywiście nie oznacza, że oprogramowanie jest obiektywnie wadliwe, a jest bardziej konsekwencją sposobu postrzegania i uczenia się świata przez ludzi. 4. Standardy rynkowe 4.1. Czy są potrzebne Pytanie zawarte w tytule tej sekcji jest raczej pytaniem retorycznym. Brak standardów jakości na rynku oprogramowania to szereg problemów i wątpliwości nie tylko dla Klientów i Użytkowników oprogramowania, ale także dla producentów. W przypadku producentów wątpliwości dotyczą tego co należy zrobić, aby osiągnąć produkt wysokiej jakości, lub inaczej mówiąc aby jakość produktu stała się elementem przewagi konkurencyjnej.

16 Czym jest jakość oprogramowania 16 Powszechne wdrażanie normy ISO 9001 oraz entuzjastyczne przyjęcie pierwszej wersji ISO 9126:1991, jak również adaptowanie praktyk CMMI pokazują, że producenci nie obawiają się inwestycji i nakładów na szeroko rozumiane zapewnianie jakości. Pomimo tego, że na rynku pojawiają się bardziej szczegółowe wytyczne odnośnie wymogów dla oprogramowania niż w ISO/IEC 9126:2001 lub ISO/IEC (na przykład w ISO 9241) to brakuje mechanizmów i standardów, które pozwoliłyby materializować wysiłki producentów i byłyby rozpoznawalne dla użytkowników Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne W dniu dzisiejszym obowiązują następujące akty prawne: Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2005 r. Nr 64, poz. 565) Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz.U. z 2005 Nr 217, poz. 1836) Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej (Dz.U. z 2005 Nr 214, poz. 1781) Rozporządzenie Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2005 Nr 212, poz. 1766) Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu i zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. z 2005 Nr 205, poz. 1692) Pomimo mogącej toczyć się dyskusji o ich przydatności lub nie, o tym co wnoszą, a co mogłyby wnosić (główny zarzut dotyczy tego, że są zbyt pobieżne), zaskakujący jest fakt, że prawo to jest praktycznie martwe. Zgodnie z przepisami podmioty realizujące zadania publiczne i udostępniające interfejsy elektroniczne powinny publikować testy akceptacyjne nie są publikowane. Producenci systemów komunikujących się z tymi rozwiązaniami powinni przesyłać podmiotom realizującym zadania publiczne informacje o nowych wersjach oprogramowania wypuszczanego na rynek nie przesyłają, a nawet gdyby przesłali to urzędnicy, z którymi autorzy omawiali sposób procesowania wynikający z ustawy nie mieliby pojęcia co z takimi informacjami zrobić. Ustawa stosowana może być wyłącznie przez podmioty realizujące zadania publiczne, a tymczasem cały rynek IT wymaga wsparcia dla użytkowników w określaniu jakości oprogramowania Podjęta inicjatywa Należy rozważyć jakie cechy powinny mieć standardy jakości dla oprogramowania aby ich pojawienie się wniosło realną wartość dla producentów i użytkowników. Autor tej publikacji wymienia kilka

17 Czym jest jakość oprogramowania 17 cech, które zostały zidentyfikowane w ramach prac nad stworzeniem standardów jakości oprogramowania [SASO2007] Perspektywa klienta i użytkownika Przyjęto, że standardy rynkowe mają dostarczać informacji o produkcie użytkownikom i klientom branży IT. Wynika z tego, że zarówno w obszarze definiowania standardu główny głos powinni zabierać użytkownicy i klienci jak również, że to właśnie perspektywa użytkownika powinna być dominującym zestawem cech jakościowych. Warto zauważyć, że choć drugi z wyżej wymienionych postulatów zauważono już w modelu Boehm [Boe1979], o tyle dotychczas budowane modele powstawały głównie na podstawie analiz naukowych lub prac organizacji wywodzących się z branży IT Oparcie merytoryczne o osiągnięcia dziedzinowe Postulat ten jest raczej oczywisty i w pewnym sensie dobrze uzupełnia opisany powyżej. Celem jaki mają do osiągnięcia standardy jest stworzenie porozumienia pomiędzy społecznością odbiorców i producentów oprogramowania. Jednym z podstawowych wymagań dla takiego porozumienia jest jednoznaczna komunikacja, stąd też oparcie się o dotychczasowe dokonania w obszarze modelowania jakości oprogramowani i korzystanie z bieżących i przyszłych prac w tej dziedzinie wydaje się być nieodzowne Obiektywizm i własność standardu Standard jakości oprogramowania nie może preferować producentów oprogramowania, konkretnych technologii czy platform. Wynika z tego, ze właścicielem standardu powinna być organizacja nonprofit skupiająca użytkowników i przedstawicieli IT. Quality in use Usability in use Adaptability In use Safety in use Security In use Context in use Effectiveness in use Productivity in use Satisfaction in use Usability in use compliance Learnability in use Flexibility in use Accessibility in use Adaptability in use compliance Risks to the operator in use Risks to the public in use Commercial risks in use Risk of software corruption in use Safety in use compliance TO BE DEFINED Security in use compliance User types in use Tasks in use Environments in use Context in use compliance Usability & Adaptability cert. Safety & Security cert.

18 Czym jest jakość oprogramowania 18 Rys. Trzy rodzaje certyfikatów mapowane na model SQuaRE w ISO/IEC CD 4.7. Porównywalność Kolejnym wymogiem dla standardu jest możliwość odniesienia go do różnych produktów i wyciągnięcie wniosków o ich jakości z możliwością wprowadzenia relacji porządku. Patrząc na model SQuaRE można zauważyć, że część charakterystyk dotyczy kontekstu użycia aplikacji, który ze swojej natury nie nadaje się na obiektywny element standardu (mógłby powstać szereg standardów dla konkretnych dziedzin zastosowania). W modelu wybrano zatem te charakterystyki, które zapewniają możliwość stworzenia obiektywnych i porównywalnych miar, a ich odniesienie do SQuaRE prezentuje rysunek Dostęp do dokumentacji i możliwości ewaluacji Standard może upowszechnić się jedynie wtedy, kiedy jego dokumentacja będzie powszechnie dostępna (najlepiej nieodpłatnie) oraz będzie istniało wiele podmiotów na rynku, które będą doradzały producentom w zakresie stosowania standardu lub dokonywały ewaluacji oprogramowania (nadania odpowiedniego znaku jakości). Audits And Notifies Orders Evaluation Evaluator Developer Registers Certificate for software Rys. Proces wydawania certyfikatu zgodności: SASO notyfikuje firmy wykonujące badania (Evaluatorów) producent zwraca się do firmy wykonującej badania firma potwierdza zgodność z wymogami i przyznaje znak jakości (oraz informuje SASO) SASO prowadzi nadzór nad systemem

19 Czym jest jakość oprogramowania Podsumowanie Niezależnie od liczby zdefiniowanych do tej pory modeli jakości oprogramowania na rynku brakuje standardów, które pozwoliłyby producentom dyskontować swoje inwestycje w jakość produktów IT. Standardy odnoszące się do obecnych modeli zastosowania oprogramowania oraz przyszłych wyzwań, takich jak SOA mogą stać się istotnym elementem uwagi producentów, oraz dać im możliwość stosowania rozwiązań, których oczekuje społeczność użytkowników. Przygotowywane standardy powinny bazować na dotychczasowych dokonaniach naukowych w obszarze modelowania jakości oprogramowania oraz rozszerzać te modele o konkretne decyzje o włączaniu, wyłączaniu i wadze poszczególnych charakterystyk. Jedna z pierwszych tego typu inicjatyw bazująca na modelu SQuaRE i nie opublikowanych jeszcze normach ISO/IEC i innych z serii ISO/IEC powstała w Polsce [SASO2007]. Inicjatywa ta nie jest skazana na sukces, ale z pewnością może wpłynąć zarówno na wewnętrzny rynek IT w Polsce jak również wizerunek polskiego IT na zewnątrz. 6. Bibliografia Aryst1999 Arystoteles, Kategorie, w Dzieła Wszystkie, Wydawnictwo Naukowe PWN, 1990 Bach Bach J., Good Enough Quality: Beyond the Buzzword, IEEE Computer Society, August 1997 (Vol. 30, No. 8) pp BAJ1993 Bazzana G., Anderson O., Jokela T., ISO 9126 and ISO 9000: friends or foes?, Software Engineering Standards Symposium BasWei1984 Basili V., Weiss D., A methodology for collecting valid software engineering data, IEEE Transactions on Software Engineering, Vol SE-10, 1984 Beg Begier B., Inżynieria Oprogramowania - Problematyka Jakości, WPP 1999 Beg2003 Begier B., Ocena jakości wyrobu programowego przez użytkowników, w: Z.Huzar, Z. Mazur (ed.): Problemy i metody inżynierii oprogramowania, pp , WNT, Warszawa 2003 (http://www.e-informatyka.pl/article/showbw/489) Boe1978 Boehm B., Brown J., Lipow M., MacCleod G, Characteristics of software quality, NY, American Elsevier, 1978 BowWig1985 Bowen T., Wigle G., Tsai J., Specification of Software Quality Attributes, RADC-TR-83-37, Vol 1-3, Boeing Aerospace Company, 1985 Cas1981 Cassirer E., Kant's Life and Thought. Translation of Kants Leben und Lehre. Trans., Jame S. Haden, intr. Stephan Körner., New Haven, Yale University Press, 1981 CotSur2006 Côté M-A, Suryn W., Georgiadou E., "Software Quality Model Requirements for Software Quality Engineering", Software Quality Management & INSPIRE Conference (BSI) 2006 DiaSli1997 Diaz M., Sligo J., How Software Process Improvement Helped Motorola, IEEE Software 17(5), 1997 Dro Dromey R., A Model For Software Product Quality, Australian Software Quality Research Institute Dro1998 Dromey R., Software Product Quality: Theory, Model and Practises, Australian Software Quality Research Institute Dromey1996 Dromey R., Cornering the Chimera, IEEE Software 13(1), 1996 Dymek Dymek D., Zarządzanie jakością oprogramowania komputerowego, Akademia Ekonomiczna w Krakowie 2000 Eic2003 Eickelman N., An Insider s View of CMM Level 5, IEEE Software 20(4), 2003

20 Czym jest jakość oprogramowania 20 Fre1923 Freud S., Das Ich und das Es (The Ego and the Id), 1923 Gasik2004 Gasik S., Jakość w projektach informatycznych, Gos1854 Gossen H., Die Entwicklung der Gesetze des menschlichen Verkehrs und der daraus fließenden Regeln für menschliches Handel (The Development of the Laws of Human Intercourse and the Consequent Rules of Human Action), 1854 HamMan Hamrol A., Mantra W., Zarządzanie jakością, PWN 2002 HamMay Hamlet D., Maybee J., Inżynieria Oprogramowania WNT 2003 IEEE1998 Standard for a Software Quality Metrics Methodology, IEEE 1061, 1998 ISO14598:1999 JTC1/SC7, Information technology - Software product evaluation, International Standardization Organization, 1999 ISO15504:1998 SPICE, JTC1/SC7, International Standardization Organization, 1998 ISO/IEC 25000:2005 JTC1/SC7, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE), International Standardization Organization, 2005 ISO/IEC CD JTC1/SC7, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE), Dokument wewnętrzny ISO/IEC JTC1/SC7, Obecnie w stadium CD Commision Draft, 2007 ISO 9001: TC176/SC2, Quality management systems Requirements, International Standardization Organization, 1994 ISO 9001:2000 TC176/SC2, Quality management systems Requirements, International Standardization Organization, 2000 ISO 9126:1991 JTC1/SC7, Information Technology Software Product Quality, International Standardization Organization, 1991 ISO/IEC 9126: JTC1/SC7, Software engineering - Product quality, International Standardization Organization, 2001 ISO/IEC :1998 TC159/SC4, Ergonomic requirements for office work with visual display terminals (VDTs), International Standardization Organization, 1999 Jag Jagielski J., Kwantytatywna ocena jakości przyrządu pomiarowego, Pomiary Automatyka Robotyka 7-8/2004 Jasz Jaszkiewicz A., Inżynieria Oprogramowania, Helion 1997 Kan2003 Kan S., Metrics and Models in Software Quality Engineering (second edition), Addison Wesley, 2003 Kan2006 Kan S., Metryki i modele w inżynierii jakości oprogramowania, Wydawnictwo Naukowe PWN, 2006 KH Katsioloudes M., Hadjidakis S., International Business: A Globar Perspective, Butterworth-Heinemann, 2007 Kel Kelman H., Compliance, identification, and internalization: three processes of attitude change, Journal of Conflict Resolution, 1958 KobPol2003 Kobyliński A., Polak P., Analiza polskojęzycznej literatury z zakresu "Inżynierii oprogramowania", w: Problemy i metody inżynierii oprogramowania, Z. Huzar, Z. Mazur [red.], WNT, 10, Koby Kobyliński A., ISO/IEC analiza modelu jakości produktów programowych, w: Systemy Wspomagania Organizacji 2003, T. Porębska-Miąc, H. Sroka [red.], Prace Naukowe AE w Katowicach, 10, Koby2005 Kobyliński A., Modele jakości produktów i procesów programowych, Oficyna Wydawnicza Szkoły Głównej Handlowej, 2005 KW2003 Kolb B., Whishaw I., Fundamentals of Human Neuropsychology, 2003 KitPfle1996 Kitchenham S., Pfleeger, Software Quality: The Elisive Target, IEEE Software 13(1) 1996 Kili Kiliński A., Jakość, WNT 1979 LSF2000 Libet B., Sutherland K., Freeman A.,The Volitional Brain: Towards a Neuroscience of Free Will, 2000 MaKr1973 MacLean P., Kral V., A Triune Concept of the Brain and Behaviour, Ontario Mental Health Foundation, 1973 Mas1943 Maslow A., A Theory of Human Motivation, Psychological Review 50, 1943 McCa1977 McCall J., Richards P., Walters G., Factors In software quality, Griffiths Air Force Base, NY, Rome Air Development Center Air Force Systems Command, 1977

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska , e-mail: zabinska@agh.edu.pl Katedra Informatyki AGH, D17/ 2.27 [ISO 9000] Jakość jest określana jako ogół cech i właściwości wyrobu lub usługi wymaganych do zaspokojenia stwierdzonych lub przewidywanych

Bardziej szczegółowo

Usługowy model zarządzania w oparciu o ITIL v3. wprowadzenie do biblioteki ITIL na prostym przykładzie

Usługowy model zarządzania w oparciu o ITIL v3. wprowadzenie do biblioteki ITIL na prostym przykładzie Usługowy model zarządzania w oparciu o ITIL v3 wprowadzenie do biblioteki ITIL na prostym przykładzie Plan prezentacji Krótka definicja ITIL i kilka pojęć Umowy i kontrakty SLA, OLA, UC Podstawowe publikacje

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy Wykład 5 (1) Jakość w projekcie informatycznym - normy ISO: Ogólne dot. jakości: ISO 8402 - terminologia ISO 9000 - wytyczne dotyczące wyboru modelu ISO 9001/3 - modele systemu jakości Dot. oprogramowania:

Bardziej szczegółowo

Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny?

Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny? Jakość wymagań a wymagania jakości Czy możliwa jest obiektywizacja oceny? 14:45 15:15 Bogdan Bereza @ victo.eu @ I Konferencja SASO - Inżynieria Jakości Oprogramowania Poznań, 25 września 2014 1(20) Automated

Bardziej szczegółowo

Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej

Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej Wiesław Paluszyński Prezes zarządu TI Consulting Plan prezentacji Zdefiniujmy

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011 Architektura informacji w ochronie zdrowia Warszawa, 29 listopada 2011 Potrzeba Pomiędzy 17 a 19 kwietnia 2011 roku zostały wykradzione dane z 77 milionów kont Sony PlayStation Network. 2 tygodnie 25 milionów

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM SZKOŁA GŁÓWNA HANDLOWA w Warszawie STUDIUM MAGISTERSKIE Kierunek: Metody ilościowe w ekonomii i systemy informacyjne Karol Walędzik Nr albumu: 26353 Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem

Bardziej szczegółowo

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

BAKER TILLY POLAND CONSULTING

BAKER TILLY POLAND CONSULTING BAKER TILLY POLAND CONSULTING Wytyczne KNF dla firm ubezpieczeniowych i towarzystw reasekuracyjnych w obszarze bezpieczeństwa informatycznego An independent member of Baker Tilly International Objaśnienie

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Katalog rozwiązań informatycznych dla firm produkcyjnych

Katalog rozwiązań informatycznych dla firm produkcyjnych Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000

Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Charakterystyka systemu zarządzania jakością zgodnego z wymaganiami normy ISO serii 9000 Normy ISO serii 9000 Zostały uznane za podstawę wyznaczania standardów zarządzania jakością Opublikowane po raz

Bardziej szczegółowo

Wprowadzenie... 3 Charakterystyka grupy docelowej... 4 Podział grupy docelowej... 4. Podział grupy docelowej wg stanowisk pracy respondentów...

Wprowadzenie... 3 Charakterystyka grupy docelowej... 4 Podział grupy docelowej... 4. Podział grupy docelowej wg stanowisk pracy respondentów... Spis treści Wprowadzenie... 3 Charakterystyka grupy docelowej... 4 Podział grupy docelowej.... 4 Podział grupy docelowej wg stanowisk pracy respondentów.... 4 Wyniki badania... 6 Rozliczanie produkcji

Bardziej szczegółowo

Matryca efektów kształcenia dla programu studiów podyplomowych ZARZĄDZANIE I SYSTEMY ZARZĄDZANIA JAKOŚCIĄ

Matryca efektów kształcenia dla programu studiów podyplomowych ZARZĄDZANIE I SYSTEMY ZARZĄDZANIA JAKOŚCIĄ Podstawy firmą Marketingowe aspekty jakością Podstawy prawa gospodarczego w SZJ Zarządzanie Jakością (TQM) Zarządzanie logistyczne w SZJ Wymagania norm ISO serii 9000 Dokumentacja w SZJ Metody i Techniki

Bardziej szczegółowo

I Konferencja SASO. Inżynieria Jakości Oprogramowania. Poznań, 2014-09-25

I Konferencja SASO. Inżynieria Jakości Oprogramowania. Poznań, 2014-09-25 I Konferencja SASO Inżynieria Jakości Oprogramowania Poznań, 2014-09-25 Witamy 9:30-10:00 Powitanie (W. Suryn, R. Hofman, E. Hołodnik-Matysek) 10:00-11:00 Inżynieria Jakości Oprogramowania (W. Suryn) 15

Bardziej szczegółowo

Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11

Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11 Spis treści Przedmowa... 7 1. System zarządzania jakością w przygotowaniu projektów informatycznych...11 1.1. Wprowadzenie...11 1.2. System zarządzania jakością...11 1.3. Standardy jakości w projekcie

Bardziej szczegółowo

Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy

Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy współfinansowany ze środków Mechanizmu Finansowego Europejskiego Obszaru Gospodarczego. Marek

Bardziej szczegółowo

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE

ŚcieŜki Certyfikacji Testera. Karol Mioduszewski - CORRSE ŚcieŜki Certyfikacji Testera Karol Mioduszewski - CORRSE Kierunki rozwoju W dół, w górę czy w bok? Rozwój w dół Specjalizacja Zagłębianie się w wybrany wycinek wiedzy, np. testy wydajnościowe lub konkretne

Bardziej szczegółowo

Z-ZIP2-119z Inżynieria Jakości Quality Engineering

Z-ZIP2-119z Inżynieria Jakości Quality Engineering KARTA MODUŁU / KARTA PRZEDMIOTU Z-ZIP2-119z Inżynieria Jakości Quality Engineering Kod modułu Nazwa modułu Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 2012/2013 A. USYTUOWANIE MODUŁU

Bardziej szczegółowo

Darmowy fragment www.bezkartek.pl

Darmowy fragment www.bezkartek.pl Wszelkie prawa zastrzeżone. Rozpowszechnianie całości lub fragmentów niniejszej publikacji w jakiejkolwiek postaci bez zgody wydawcy zabronione. Autor oraz wydawca dołożyli wszelkich starań aby zawarte

Bardziej szczegółowo

Katalog szkoleń certyfikowanych Testowanie Oprogramowania

Katalog szkoleń certyfikowanych Testowanie Oprogramowania Katalog szkoleń certyfikowanych Testowanie Oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

e-administracja: nowe technologie w służbie obywatelowi

e-administracja: nowe technologie w służbie obywatelowi e-administracja: nowe technologie w służbie obywatelowi Co niesie administracji chmura obliczeniowa? dr inż. Dariusz Bogucki Centrum Projektów Informatycznych Wrocław, 3 października 2012 r. Paradoks wykorzystania

Bardziej szczegółowo

Generacja Y o mediach społecznościowych w miejscu pracy

Generacja Y o mediach społecznościowych w miejscu pracy Generacja Y o mediach społecznościowych w miejscu pracy Raport z badania Szymon Góralski Wrocław, 2013 ul. Więzienna 21c/8, 50-118 Wrocław, tel. 71 343 70 15, fax: 71 343 70 13, e-mail: biuro@rrcc.pl,

Bardziej szczegółowo

Inżynieria Jakości Quality Engineering. Zarządzanie i Inżynieria Produkcji II stopień Ogólnoakademicki

Inżynieria Jakości Quality Engineering. Zarządzanie i Inżynieria Produkcji II stopień Ogólnoakademicki KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 2013/2014 Inżynieria Jakości Quality Engineering A. USYTUOWANIE MODUŁU W SYSTEMIE

Bardziej szczegółowo

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

ISO/IEC 20000 OD USŁUG POPRZEZ SYSTEM DO CERTYFIKACJI

ISO/IEC 20000 OD USŁUG POPRZEZ SYSTEM DO CERTYFIKACJI ISO/IEC 20000 OD USŁUG POPRZEZ SYSTEM DO CERTYFIKACJI GRZEGORZ KULISZ Bydgoszcz, 1 kwietnia 2011 r. 1. ISO/IEC 20000 o co w tym wszystkim chodzi 2. Droga do certyfikacji 3. W czym możemy pomóc? 4. A jeżeli

Bardziej szczegółowo

Podstawowe zasady użyteczności i ich wpływ na biznes

Podstawowe zasady użyteczności i ich wpływ na biznes Podstawowe zasady użyteczności i ich wpływ na biznes Agenda: 1. Kim są Użyteczni.pl i czym się zajmują? 2. Składowe User Experience 3. Architektura informacji 4. Czym jest użyteczność 5. Podstawowe zasady

Bardziej szczegółowo

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd

Bardziej szczegółowo

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych Jak teoria pomaga w codziennej praktyce zapewniania i kontroli jakości Piotr Ślęzak Stowarzyszenie Jakości Systemów Informatycznych

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

Bardziej szczegółowo

Egzamin ITIL Foundation

Egzamin ITIL Foundation Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.

Bardziej szczegółowo

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends

WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji dr inż. Bolesław Szomański Wydział Zarządzania Politechnika Warszawska b.szomański@wz.pw.edu.pl Plan Prezentacji

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Załącznik Nr 3 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Spis treści Słownik pojęć... 1 Wprowadzenie... 2 Kroki zarządzania ryzykiem

Bardziej szczegółowo

Zwrot z inwestycji w IT: prawda czy mity

Zwrot z inwestycji w IT: prawda czy mity Zwrot z inwestycji w IT: prawda czy mity Inwestycje w technologie IT 1 muszą podlegać takim samym regułom oceny, jak wszystkie inne: muszą mieć ekonomiczne uzasadnienie. Stanowią one koszty i jako takie

Bardziej szczegółowo

Jakość przed jakością

Jakość przed jakością Jakość przed jakością Oprogramowanie naprawdę przydatne (2) Robert Ganowski II Krajowa Konferencja Jakości Systemów Informatycznych, Warszawa, 21-22 czerwca 2005 r. 1 Teoria prawdy*

Bardziej szczegółowo

Wydanie 3 Warszawa, 20.06.2007 r.

Wydanie 3 Warszawa, 20.06.2007 r. . POLSKIE CENTRUM AKREDYTACJI POLITYKA POLSKIEGO CENTRUM AKREDYTACJI DOTYCZĄCA ZAPEWNIENIA SPÓJNOŚCI POMIAROWEJ Wydanie 3 Warszawa, 20.06.2007 r. 1. Wstęp Niniejsza Polityka jest zgodna z dokumentem ILAC-P10:2002

Bardziej szczegółowo

Szkolenie Stowarzyszenia Polskie Forum ISO 14000 Zmiany w normie ISO 14001 i ich konsekwencje dla organizacji Warszawa, 16.04.2015

Szkolenie Stowarzyszenia Polskie Forum ISO 14000 Zmiany w normie ISO 14001 i ich konsekwencje dla organizacji Warszawa, 16.04.2015 Wykorzystanie elementów systemu EMAS w SZŚ według ISO 14001:2015 dr hab. inż. Alina Matuszak-Flejszman, prof. nadzw. UEP Agenda Elementy SZŚ według EMAS (Rozporządzenie UE 1221/2009) i odpowiadające im

Bardziej szczegółowo

STANDARDY I SYSTEMY ZARZĄDZANIA PORTAMI LOTNICZYMI 2013

STANDARDY I SYSTEMY ZARZĄDZANIA PORTAMI LOTNICZYMI 2013 Wersja Jednostka realizująca Typ Poziom Program Profil Blok Grupa Kod Semestr nominalny Język prowadzenia zajęć Liczba punktów ECTS Liczba godzin pracy studenta związanych z osiągnięciem efektów Liczba

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe ZARZĄDZANIE SERWISEM IT PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe ZARZĄDZANIE SERWISEM IT Semestr 1 Moduły

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

KLIENCI KIENCI. Wprowadzenie normy ZADOWOLE NIE WYRÓB. Pomiary analiza i doskonalenie. Odpowiedzialnoś ć kierownictwa. Zarządzanie zasobami

KLIENCI KIENCI. Wprowadzenie normy ZADOWOLE NIE WYRÓB. Pomiary analiza i doskonalenie. Odpowiedzialnoś ć kierownictwa. Zarządzanie zasobami SYSTEM ZARZĄDZANIA JAKOŚCIĄ ISO Jakość samą w sobie trudno jest zdefiniować, tak naprawdę pod tym pojęciem kryje się wszystko to co ma związek z pewnymi cechami - wyrobu lub usługi - mającymi wpływ na

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS. Krok po kroku

Monitoring procesów z wykorzystaniem systemu ADONIS. Krok po kroku z wykorzystaniem systemu ADONIS Krok po kroku BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

poprawy konkurencyjności

poprawy konkurencyjności Wdrażanie anie i doskonalenie systemów w zarządzania szansą poprawy konkurencyjności ci organizacji Andrzej Borcz "Przy istniejącej konkurencji firmy, które nie potrafią tworzyć i wcielać w życie doskonałej

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt 0-618 Lublin tel. (+8 81) 58 7 1/ fax (+8 81) 58 5 80 Przedmiot: Rok: INF I Inżynieria Semestr: V Rodzaj zajęć i liczba godzin: Studia stacjonarne Studia niestacjonarne Wykład 0 1 Ćwiczenia Laboratorium

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk

Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk dr T Bartosz Kalinowski 17 19 września 2008, Wisła IV Sympozjum Klubu Paragraf 34 1 Informacja a system zarządzania Informacja

Bardziej szczegółowo

ZASTOSOWANIE TECHNOLOGII WIRTUALNEJ RZECZYWISTOŚCI W PROJEKTOWANIU MASZYN

ZASTOSOWANIE TECHNOLOGII WIRTUALNEJ RZECZYWISTOŚCI W PROJEKTOWANIU MASZYN MODELOWANIE INŻYNIERSKIE ISSN 1896-771X 37, s. 141-146, Gliwice 2009 ZASTOSOWANIE TECHNOLOGII WIRTUALNEJ RZECZYWISTOŚCI W PROJEKTOWANIU MASZYN KRZYSZTOF HERBUŚ, JERZY ŚWIDER Instytut Automatyzacji Procesów

Bardziej szczegółowo

Normy ISO serii 9000. www.greber.com.pl. Normy ISO serii 9000. Tomasz Greber (www.greber.com.pl) dr inż. Tomasz Greber. www.greber.com.

Normy ISO serii 9000. www.greber.com.pl. Normy ISO serii 9000. Tomasz Greber (www.greber.com.pl) dr inż. Tomasz Greber. www.greber.com. Normy ISO serii 9000 dr inż. Tomasz Greber www.greber.com.pl www.greber.com.pl 1 Droga do jakości ISO 9001 Organizacja tradycyjna TQM/PNJ KAIZEN Organizacja jakościowa SIX SIGMA Ewolucja systemów jakości

Bardziej szczegółowo

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ

PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ Wykład 4. PRZEGLĄD KONCEPCJI ZARZĄDZANIA JAKOŚCIĄ 1 1.Ogólna charakterystyka koncepcji zarządzania jakością i kierunki ich zmian w czasie: W historycznym podejściu do zarządzania jako- ścią można wyróżnić

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Wprowadzenie do zarządzania projektami

Wprowadzenie do zarządzania projektami Wprowadzenie do zarządzania projektami Project Management dr Marek Wąsowicz Katedra Projektowania Systemów Zarządzania, UE Wrocław Wrocław, 23 października 2012 r. Zawartość modułu (4h): wskazanie możliwości

Bardziej szczegółowo

Użyteczność stron internetowych

Użyteczność stron internetowych Użyteczność stron internetowych Użyteczność Użyteczność (ang. usability) jest to dziedzina wiedzy dotycząca interaktywnych urządzeń i aplikacji, która określa stopień, w jakim ludzie są w stanie wykonać

Bardziej szczegółowo

AUDYT BEZPIECZEŃSTWA INFORMACJI Podstawy

AUDYT BEZPIECZEŃSTWA INFORMACJI Podstawy AUDYT BEZPIECZEŃSTWA INFORMACJI Podstawy ROZPORZĄDZENIE RADY MINISTRÓW z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji

Bardziej szczegółowo

DOSKONALENIE PROCESÓW

DOSKONALENIE PROCESÓW KATALOG SZKOLEŃ DOSKONALENIE PROCESÓW - Tworzenie projektów ciągłego doskonalenia - Konsultacje z ekspertami - Poprawa jakości oraz produktywności - Eliminacja marnotrawstwa - Redukcja kosztów - Metody

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Asseco Omnichannel Banking Solution.

Asseco Omnichannel Banking Solution. Asseco Omnichannel Asseco Omnichannel 94% dyrektorów dużych banków uważa, że omnichannel jest ważnym narzędziem do utrzymania lojalności klientów.* Według prognoz Forrester Research bankowość wchodzi w

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Norma to dokument przyjęty na zasadzie konsensu i zatwierdzony do powszechnego stosowania przez

Norma to dokument przyjęty na zasadzie konsensu i zatwierdzony do powszechnego stosowania przez KONCEPCJA SYSTEMU JAKOŚCI zgodnie z wymaganiami norm ISO serii 9000 dr Lesław Lisak Co to jest norma? Norma to dokument przyjęty na zasadzie konsensu i zatwierdzony do powszechnego stosowania przez upoważnioną

Bardziej szczegółowo

Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej.

Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej. Wyznaczanie minimalnej odważki jako element kwalifikacji operacyjnej procesu walidacji dla wagi analitycznej. Andrzej Hantz Dyrektor Centrum Metrologii RADWAG Wagi Elektroniczne Pomiary w laboratorium

Bardziej szczegółowo

M. Dąbrowska. K. Grabowska. Wroclaw University of Economics

M. Dąbrowska. K. Grabowska. Wroclaw University of Economics M. Dąbrowska K. Grabowska Wroclaw University of Economics Zarządzanie wartością przedsiębiorstwa na przykładzie przedsiębiorstw z branży produkującej napoje JEL Classification: A 10 Słowa kluczowe: Zarządzanie

Bardziej szczegółowo

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing

ZARZĄDZANIE MARKĄ. Doradztwo i outsourcing ZARZĄDZANIE MARKĄ Doradztwo i outsourcing Pomagamy zwiększać wartość marek i maksymalizować zysk. Prowadzimy projekty w zakresie szeroko rozumianego doskonalenia organizacji i wzmacniania wartości marki:

Bardziej szczegółowo

Co się zmieni w nowej wersji normy ISO 9001

Co się zmieni w nowej wersji normy ISO 9001 TÜV Rheinland Polska Co się zmieni w nowej wersji normy ISO 9001 Podsumowanie zmian www.tuv.pl Aktualizacja normy ISO 9001:2015 Publikacja nowej wersji normy ISO 9001:2015 jest oczekiwana we wrześniu 2015

Bardziej szczegółowo

2. Opis zajęć dydaktycznych i pracy studenta

2. Opis zajęć dydaktycznych i pracy studenta Uniwersytet Śląski w Katowicach str. 1 Kierunek i poziom studiów: Informacja naukowa i bibliotekoznawstwo. Poziom II Sylabus modułu: Jakość w bibliotece (02-BN-NB-S2-JB01, 02-BN-NB-N2-JB01) 1. Informacje

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

Zasady auditowania procesów zarządzania infrastrukturą przez jednostki certyfikujące systemy zarządzania

Zasady auditowania procesów zarządzania infrastrukturą przez jednostki certyfikujące systemy zarządzania Monika Stoma 1 Agnieszka Dudziak 2 Paweł Krzaczek 3 Uniwersytet Przyrodniczy w Lublinie Zasady auditowania procesów zarządzania infrastrukturą przez jednostki certyfikujące systemy zarządzania Wprowadzenie

Bardziej szczegółowo

Audyt systemów informatycznych w świetle standardów ISACA

Audyt systemów informatycznych w świetle standardów ISACA Audyt systemów informatycznych w świetle standardów ISACA Radosław Kaczorek, CISSP, CISA, CIA Warszawa, 7 września 2010 r. 1 Zawartość prezentacji Wstęp Ryzyko i strategia postępowania z ryzykiem Mechanizmy

Bardziej szczegółowo

Rozwój Modelu Pomorskiej Nagrody Jakości

Rozwój Modelu Pomorskiej Nagrody Jakości Rozwój Modelu Pomorskiej Nagrody Jakości Prof. ndzw. UG dr hab. Małgorzata Wiśniewska Przewodnicząca Kapituły Konkursu o Pomorską Nagrodę Jakości Gdańsk, 27.02.2015 Korzenie Pomorska Nagroda Jakości ma

Bardziej szczegółowo

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

Bardziej szczegółowo

STUDIA PODYPLOMOWE Rekomendacje UZP na systemy nabiurkowe, czyli jak zamówić komputer do urzędu

STUDIA PODYPLOMOWE Rekomendacje UZP na systemy nabiurkowe, czyli jak zamówić komputer do urzędu Rekomendacje UZP na systemy nabiurkowe, czyli jak zamówić komputer do urzędu Andrzej Zalewski Rekomendacje UZP na zestawy nabiurkowe, czyli jak zamówić komputer do urzędu Dr inż. Andrzej Zalewski Politechnika

Bardziej szczegółowo

Spis treści. Wstęp... 9 KOMUNIKACJA MARKETINGOWA UCZELNI WYŻSZEJ... 11 ZNACZENIE MARKI W KOMUNIKACJI MARKETINGOWEJ UCZELNI WYŻSZEJ...

Spis treści. Wstęp... 9 KOMUNIKACJA MARKETINGOWA UCZELNI WYŻSZEJ... 11 ZNACZENIE MARKI W KOMUNIKACJI MARKETINGOWEJ UCZELNI WYŻSZEJ... Spis treści Wstęp... 9 Rozdział I KOMUNIKACJA MARKETINGOWA UCZELNI WYŻSZEJ... 11 Rozdział II ZNACZENIE MARKI W KOMUNIKACJI MARKETINGOWEJ UCZELNI WYŻSZEJ... 33 Rozdział III ROLA SERWISU INTERNETOWEGO UCZELNI

Bardziej szczegółowo

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki: Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne

Bardziej szczegółowo

Stacjonarne Wszystkie Katedra Informatyki Stosowanej Dr inż. Marcin Detka. Podstawowy Obowiązkowy Polski Semestr pierwszy. Semestr letni Brak Nie

Stacjonarne Wszystkie Katedra Informatyki Stosowanej Dr inż. Marcin Detka. Podstawowy Obowiązkowy Polski Semestr pierwszy. Semestr letni Brak Nie KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Nazwa modułu w języku angielskim Obowiązuje od roku akademickiego 202/203 Z-ZIP2-0452 Informatyczne Systemy Zarządzania Produkcją Manufacturing Management

Bardziej szczegółowo

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka Zmiany w standardzie ISO 9001 dr inż. Ilona Błaszczyk Politechnika Łódzka 1 W prezentacji przedstawiono zmiany w normie ISO 9001 w oparciu o projekt komitetu. 2 3 4 5 6 Zmiany w zakresie terminów używanych

Bardziej szczegółowo

Nowe narzędzia pozycjonowania uczelni założenia U-Map i U-Multirank. Szansa, czy zagrożenie dla polskich uczelni?

Nowe narzędzia pozycjonowania uczelni założenia U-Map i U-Multirank. Szansa, czy zagrożenie dla polskich uczelni? Nowe narzędzia pozycjonowania uczelni założenia U-Map i U-Multirank. Szansa, czy zagrożenie dla polskich uczelni? Gliwice, 30.11.2012 Jakub Brdulak Ekspert Boloński U-Map i U-Multirank Jakub Brdulak 1

Bardziej szczegółowo

Budowanie polityki bezpieczeństwa zgodnie z wymogami PN ISO/IEC 17799 przy wykorzystaniu metodologii OCTAVE

Budowanie polityki bezpieczeństwa zgodnie z wymogami PN ISO/IEC 17799 przy wykorzystaniu metodologii OCTAVE Budowanie polityki bezpieczeństwa zgodnie z wymogami PN ISO/IEC 17799 przy wykorzystaniu metodologii OCTAVE AGENDA: Plan prezentacji Wstęp Charakterystyka zagrożeń, zasobów i zabezpieczeń Założenia bezpieczeństwa

Bardziej szczegółowo

Wykorzystanie opcji w zarządzaniu ryzykiem finansowym

Wykorzystanie opcji w zarządzaniu ryzykiem finansowym Prof. UJ dr hab. Andrzej Szopa Instytut Spraw Publicznych Uniwersytet Jagielloński Wykorzystanie opcji w zarządzaniu ryzykiem finansowym Ryzyko finansowe rozumiane jest na ogół jako zjawisko rozmijania

Bardziej szczegółowo

ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH

ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH ISO/IEC 9126 ANALIZA MODELU JAKOŚCI PRODUKTÓW PROGRAMOWYCH Streszczenie Andrzej Kobyliński Katedra Informatyki Gospodarczej Szkoła Główna Handlowa w Warszawie andrzej.kobylinski@sgh.waw.pl W minionym ćwierćwieczu

Bardziej szczegółowo

MARKETING USŁUG ZDROWOTNYCH

MARKETING USŁUG ZDROWOTNYCH MARKETING USŁUG ZDROWOTNYCH Beata Nowotarska-Romaniak wydanie 3. zmienione Warszawa 2013 SPIS TREŚCI Wstęp... 7 Rozdział 1. Istota marketingu usług zdrowotnych... 11 1.1. System marketingu usług... 11

Bardziej szczegółowo

Dynamiczna zdolność przedsiębiorstwa do tworzenia wartości wspólnej jako nowego podejścia do społecznej odpowiedzialności biznesu

Dynamiczna zdolność przedsiębiorstwa do tworzenia wartości wspólnej jako nowego podejścia do społecznej odpowiedzialności biznesu Dynamiczna zdolność przedsiębiorstwa do tworzenia wartości wspólnej jako nowego podejścia do społecznej odpowiedzialności biznesu Rozprawa doktorska napisana pod kierunkiem naukowym prof. dr hab. Tomasz

Bardziej szczegółowo

SCENARIUSZ LEKCJI. TEMAT LEKCJI: Zastosowanie średnich w statystyce i matematyce. Podstawowe pojęcia statystyczne. Streszczenie.

SCENARIUSZ LEKCJI. TEMAT LEKCJI: Zastosowanie średnich w statystyce i matematyce. Podstawowe pojęcia statystyczne. Streszczenie. SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH Autorzy scenariusza:

Bardziej szczegółowo

METODY SZACOWANIA KORZYŚCI I STRAT W DZIEDZINIE OCHRONY ŚRODOWISKA I ZDROWIA

METODY SZACOWANIA KORZYŚCI I STRAT W DZIEDZINIE OCHRONY ŚRODOWISKA I ZDROWIA METODY SZACOWANIA KORZYŚCI I STRAT W DZIEDZINIE OCHRONY ŚRODOWISKA I ZDROWIA Autor: red. Piotr Jeżowski, Wstęp Jedną z najważniejszych kwestii współczesności jest zagrożenie środowiska przyrodniczego i

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Zarządzanie jakością, środowiskiem oraz bezpieczeństwem w praktyce gospodarczej. Maciej Urbaniak.

Zarządzanie jakością, środowiskiem oraz bezpieczeństwem w praktyce gospodarczej. Maciej Urbaniak. Zarządzanie jakością, środowiskiem oraz bezpieczeństwem w praktyce gospodarczej. Maciej Urbaniak. Książka stanowi szerokie kompendium wiedzy z zakresu systemów zarządzania. Stanowić ona może cenną pomoc

Bardziej szczegółowo

Specyfika i zasady przyznawania punktów w ramach kryteriów merytorycznych fakultatywnych

Specyfika i zasady przyznawania punktów w ramach kryteriów merytorycznych fakultatywnych Program Operacyjny Innowacyjna Gospodarka Działanie 8.1 Wspieranie działalności gospodarczej w dziedzinie gospodarki elektronicznej Specyfika i zasady przyznawania punktów w ramach kryteriów merytorycznych

Bardziej szczegółowo

O czym będziemy. się uczyć

O czym będziemy. się uczyć 1-1 O czym będziemy się uczyć Rachunkowość zarządcza spełnia dwie role: dostarcza informacji do podejmowania decyzji i kontroli Projektowanie i wykorzystywanie rachunku kosztów Rola specjalisty z zakresu

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo