Nowa wersja platformy, zawierająca wyłącznie zasoby pełnotekstowe, jest już dostępna.
Przejdź na https://bibliotekanauki.pl
Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 20

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  Jakość produktów informatycznych
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
XX
Artykuł zawiera analizę badań opinii polskich klientów na temat produktów i usług informatycznych. Wyrazili je użytkownicy systemów informatycznych z województw: lubelskiego, małopolskiego, podkarpackiego, śląskiego oraz świętokrzyskiego. Zebrane wypowiedzi zostały odpowiednio uporządkowane i zinterpretowane. (abstrakt oryginalny)
EN
The article discussed the analysis of Polish clients opinion poll concerning the products and services of information technology. The opinion survey was performed among the information systems users in the provinces of southern Poland. The gathered views have been suitably ordered and interpreted. (original abstract)
XX
Proces utrzymania oprogramowania jest ważnym etapem w życiu każdego produktu programowego. Kosztowność tego procesu w znacznym stopniu uzależniona jest od jednego z atrybutów jakościowych zwanego modyfikowalnścią (maintainability). Niniejszy artykuł przedstawia możliwości definiowania, oceny oraz kontrolowania tego atrybutu tak, aby koszty procesu utrzymania oprogramowania mogły być niskie. (abstrakt oryginalny)
EN
One of the most important processes in the software life cycle is the software maintenance process. Its overall cost of the above process for the most part depends on one of the quality attributies maintainability or modifiability. The following article presents possibilities of defining, assessing and controlling this attribute to sustain costs at the low level. (original abstract)
XX
Celem pracy jest identyfikacja źródeł problemów w specyfikacji wymagań. W pracy ukazano objawy błędnie opracowanej specyfikacji wymagań. Przybliżono rolę specyfikacji wymagań w procesie tworzenia systemu informatycznego oraz pożądane cechy dobrze przygotowanej specyfikacji. Scharakteryzowano najważniejsze i najczęściej występujące problemy inżynierii wymagań oraz zaproponowano sposoby uniknięcia tych problemów. (abstrakt oryginalny)
EN
The aim of this article is identification of the sources of problems in requirements specification. The symptoms of bad elaborated requirements specification have been presented in this work. The role of the requirements specification in the process of information system development and the desired features of well prepared specification have been described. The most important and common problems of the requirements engineering have been discussed and the methods of avoiding them have been proposed. (original abstract)
5
Content available remote Wpływ udziału użytkownika na jakość użytkową w projektach informatycznych
100%
XX
Artykuł przedstawia wyniki badań przeprowadzonych wśród 30 uczestników projektów informatycznych, reprezentujących różnorodne przedsiębiorstwa. Uzyskane dane zostały poddane analizie ilościowej z wykorzystaniem metody χ2, której zadaniem było ocena stopnia korelacji występującego pomiędzy udziałem użytkowników końcowych, a jakością użytkową produktu. Wyniki badań skupiają się wokół poszukiwań rozwiązania problemu określanego w literaturze przedmiotowej mianem konfliktu interesów jakościowych. (abstrakt oryginalny)
EN
This article presents the results of research conducted among 30 participants in IT projects representing a variety of companies. The data were quantitative analyzed using χ2 method. Task of this method was to assess the degree correlation existing between the end-user and the usability of the product. The results cluster around finding a solution of the problem known as a conflict of qualitative interest in the literature. (original abstract)
XX
Pojęcie jakości jest trudne do jednoznacznego zdefiniowania. W pracy przedstawiono wiele definicji jakości: idealną, techniczną, marketingową, ukierunkowaną na odbiorcę, producenta i wartość. Każdą z definicji omówiono w kontekście produkcji oprogramowania. Od lat odbiorcy oprogramowania narzekają na niedotrzymywanie przez producentów kosztorysu i harmonogramu, a także kwestionują jakość dostarczonego produktu, natomiast wytwórcy narzekają na trudności w wyspecyfikowaniu wymagań i późniejsze ciągłe zmiany wymagań przez klienta. Wiele nieporozumień dotyczących jakości dostarczanego produktu można uzasadnić odmiennym pojmowaniem jakości przez obie zainteresowane strony (klienta i producenta), ewoluującym w trakcie przebiegu prac rozwojowych. (abstrakt oryginalny)
EN
The concept of quality is difficult to define. The idea of ideal, technical, marketing, user-based, manufacturing-based qualities are presented in the paper. All the definitions can be used in the context of software product. Very often the result of software production is over budget, behind schedule, of poor quality and nonconforming requirements. And contrary developers complain about clients that they have problems to express their requirements in the beginning and change them very often later. The reason of disagreement id difference in quality understanding, evolving during software life cycle. (original abstract)
XX
Nowopowstałe organizacje gospodarcze stają przed problemem wyboru odpowiedniego systemu informatycznego na rynku. Trafność tego wyboru ma ogromny wpływ na jakość i koszty zarządzania organizacją. W artykule przedstawiono kryteria wyboru systemu i ocenę rynkową na podstawie przeprowadzonych badań ankietowych.
EN
Newly established commercial organisations or the ones in which the lifetime of a corporate management IT system currently in operation has come to an end., face the problem of choosing the suitable system on the market. The appropriate selection has a great impact on the quality and costs of the corporate management. The paper presents the major criteria for the selection of a system and the evaluation of market offers based on the questionnaire survey conducted. (original abstract)
8
84%
XX
Artykuł przedstawia uzyskane wyniki badań dotyczące problemu zawodności sprzętu komputerowego w gospodarstwach domowych. Zbadano strukturę wiekową sprzętu, przyczyny i częstość awarii. Na ich podstawie zbudowano przybliżone modele awaryjności. Wyniki te stanowią punkt odniesienia do znacznie trudniejszych badań rzeczywistych systemów bezpośrednio w organizacjach. Uzyskane wyniki przydatne są również w procesie modelowania ryzyka złożonych systemów informatycznych organizacji. (abstrakt oryginalny)
EN
The article presents the results of research concerning on the problem computer equipment failure in the household. Examined the age structure of the equipment, causes and incidence of failure. On the basis of approximate models built failure. These results provide a reference point for a much more difficult research real systems directly in organizations. The results are also useful in the risk modeling of complex information systems in organization. (original abstract)
XX
W Polsce i na świecie wdrażanie systemów informatycznych zarządzania staje się koniecznością; nie tylko w dużych przedsiębiorstwach, w których występowało to od dawna, ale także w małych i średnich. W wiciu przypadkach wdrożenie i zakup oprogramowania nie kończy się sukcesem i powoduje wiele negatywnych skutków, z których najważniejsze to:Wzrost kosztów przetwarzania danych. Wzrost kosztów zakupu oprogramowania nie wykorzystywanego lub wykorzystanego tylko w pewnych obszarach. Wzrost czasu potrzebnego do analizy informacji (w przypadku zarządu firmy są to wielkości znaczące). Brak przydatnych informacji i wzrost kosztów ich dodatkowego pozyskania. Utrata informacji i kosztów jej odzyskania. Wystąpienie błędów w przetwarzaniu informacji, kosztów kontroli i ich usuwania oraz ewentualnych kar z tego powodu. Utrata zaufania klientów z powodu błędów oraz długiego oczekiwania na obsługę. Brak możliwości wykorzystania sprzyjającej sytuacji z powodu braku informacji lub złego jej przetwarzania (utracone szanse).W szczególnych sytuacjach skutki mogą się skumulować i spowodować likwidację firmy.(...) W przypadku zakupu systemów informatycznych przez jednostki budżetowe istotnym problemem jest Ustawa z dnia 10 czerwca 1994 r. o Zamówieniach Publicznych oraz jej późniejsze zmiany. Ustawa narzuca odpowiedni sposób postępowania w przypadku większości zakupów dokonywanych przez jednostki budżetowe. Ten tryb jest obowiązujący przy zamówieniach wszelkiego rodzaju wyrobów materialnych i niematerialnych. Jednym z najważniejszych elementów systemu informatycznego jest oprogramowanie. Stąd największą uwagę należy skupić na ocenie oprogramowania wspomagającego proces zarządzania przedsiębiorstwem. (fragment tekstu)
EN
A review of methods for quality assurance during designing, projecting, implementing and putting into practice information systems in this research has been done. After information systems that aid management in small and medium size enterprises has been analysed and after analysis of the Act of Public Orders requirements the model and the method for evaluating these systems have been done. For the evaluation of information systems quality parameters have been defined. These parameters have been combined into thematic groups called criteria. The following criteria have been separated: manufacturer reliability. the capability to satisfy users' information needs. genuine as regards law and formalities. designer work-shop, methods of assuring security, interface ergonomics, documentation, quality and exploitation unfailiness. economical system efficiency. qualification and the cost of users trainings and service. The aim of the worked out method is to facilitate the choice of information system in the process of company management. The parametrical method of evaluation of informatical system quality rely on: Defying by users needs by subordinating adequate validity grades to each parameter: separating the group - critical criteria that are necessary for correct acting of the company and in case the critical criteria are not fulfilled all system can be declined, The evaluation of each parameter upon proposed grades scale, made by experts, The comparison of the final results,In the method (from products of validity grades and criteria evaluation) we obtain three kinds of final evaluations:The evaluation of every functional area, separated as criterion the ability to satisfy in formation needs of the user, Final evaluation of each criteria, Global evaluation of all criteria.This method has been verified in some enterprises. among others in manufacturing and service companies. (original abstract)
XX
Aby ograniczyć koszty prowadzonej działalności, większość szpitali powinna zdecydować się na wdrożenie zintegrowanych systemów informatycznych dla służby zdrowia. Ważnym punktem odniesienia jest fakt, iż większość wykorzystywanego w szpitalach oprogramowania jest, lub może być częścią oprogramowania i usług służących do wspierania zintegrowanych procesów. Przed podjęciem tak ważnej, nie tylko organizacyjnie, ale i finansowo, decyzji należy pamiętać o ewentualnych konsekwencjach zaprzestania wdrożenia np. "w połowie drogi". Warto zaplanować budżet w taki sposób, aby wdrożenie zapewniło przede wszystkim ciągłość procesów i nie wpływało na obniżenie jakości świadczonych usług medycznych. Wiele szpitali wykorzystuje różne aplikacje i środowiska baz danych do gromadzenia informacji o pacjentach np. system przyjęć, rejestracji i analizy zdjęć RTG, danych z pracowni USG, czy też labolatorium. Wykorzystywanie oprogramowania różnych firm (częściowa informatyzacja szpitala bez pełnej integracji systemów), często wpływa na podjęcie decyzji o zastosowania rozwiązań dających po pełnym wdrożeniu, efektywną pracę w zintegrowanym środowisku informatycznym. Dzięki temu przepływ infromacji pomiędzy systemami (oddziałami i pracowniami) staje się płynny i przebiega bez zakłóceń. (fragment tekstu)
XX
Istnieje kilka czynników, które mogą być receptą na sukces projektu IT. Przede wszystkim jest to pomysł - pomysł na dobry produkt. Należy zatem zawsze rozpocząć pracę od znalezienia niszy na rynku. Dobry pomysł jest sposobem na odróżnienie produktu od innych już istniejących na rynku. Jeśli grupą docelową jest młodzież, konieczne jest przedstawienie innowacyjnych i atrakcyjnych rozwiązań, aby zachęcić ich do korzystania z produktu. My - dając Ministerstwu Edukacji Narodowej propozycję realizacji projektu "e-Doświadczenia w fizyce" - postanowiliśmy "pójść jeszcze dalej", aby się upewnić, że nasz innowacyjny produkt będzie miał rzeczywiste zastosowanie i niósł dużą wartość edukacyjną. Jednak sam pomysł, nawet najlepszy, nie wystarczy. Należy oczywiście na jego podstawie stworzyć odpowiednie oprogramowanie, aby zaspokoić rynek (w tym przypadku rynek edukacyjny) i sprawić, że będzie ono atrakcyjne dla tych, którzy będą go używać. Ważne jest również, aby wybrać odpowiednią technologię. Należy podkreślić, że w dzisiejszym świecie jednymi z najbardziej istotnych cech oprogramowania są mobilność i elastyczność. Nasz produkt należało zatem zaplanować tak, aby był wieloplatformowy, dostępny dla wielu różnych systemów operacyjnych i rodzajów sprzętu komputerowego (komputery stacjonarne, laptopy, tablety itp.) i tablic multimedialnych. Ważne jest również, aby zapewnić możliwość uruchomienia programu bezpośrednio za pomocą przeglądarki internetowej (bez konieczności wcześniejszego instalowania na komputerze). Z kolei gdy komputer nie jest podłączony do Internetu lub dostęp do Internetu jest ograniczony, powinna być udostępniona wersja off-line. Musimy też w pełni zrozumieć wymagania zarówno użytkowników końcowych, jak i odbiorcy naszego produktu. W naszym przypadku odbiorca e-doświadczeń jest nauczycielem, a użytkownik jest uczniem. Aby dostosować program specjalnie do ich potrzeb, zaprosiliśmy ich do współpracy z nami. Ich wsparcie w projekcie jest wyjątkowo pomocne w rozwiązywaniu wszelkich problemów, takich jak np. dostosowanie e-doświadczeń do warunków i realiów panujących w szkole. Produkt (czyli e-doświadczenia) jest przedstawiany nauczycielom z wybranych szkół biorących udział w projekcie i wreszcie podczas testowania produktów otrzymujemy informacje zwrotne od uczniów - użytkowników e-doświadczeń. Wszystkie te opinie będą brane pod uwagę w celu umożliwienia zmiany produktu, aby uczynić go bardziej atrakcyjnym dla użytkownika (dodanie nowych funkcji, uwzględnienie sugestii dotyczące innych ćwiczeń itp.). (abstrakt oryginalny)
EN
The paper describes the process of the e-experiments development paying special attention to stakeholders, user and recipient, participatory design and active participation in information system development. Authors present their own experience and methods for different group of stakeholders involvement and usage of their creativity support. Structure of the paper is as follows: at the beginning we introduce into the subject by explaining the context of the project and its product, and how it fits into the niche of the market. Next, we describe the target groups and process of gathering requirements, due to designing and development of software. Then we describe methods of validation and verification of final product. Paper ends with conclusion remarks. (fragment of text)
PL
Istnieje kilka czynników, które mogą być receptą na sukces projektu IT. Przede wszystkim jest to pomysł - pomysł na dobry produkt. Należy zatem zawsze rozpocząć pracę od znalezienia niszy na rynku. Dobry pomysł jest sposobem na odróżnienie produktu od innych już istniejących na rynku. Jeśli grupą docelową jest młodzież, konieczne jest przedstawienie innowacyjnych i atrakcyjnych rozwiązań, aby zachęcić ich do korzystania z produktu. My - dając Ministerstwu Edukacji Narodowej propozycję realizacji projektu "e-Doświadczenia w fizyce" - postanowiliśmy "pójść jeszcze dalej", aby się upewnić, że nasz innowacyjny produkt będzie miał rzeczywiste zastosowanie i niósł dużą wartość edukacyjną. Jednak sam pomysł, nawet najlepszy, nie wystarczy. Należy oczywiście na jego podstawie stworzyć odpowiednie oprogramowanie, aby zaspokoić rynek (w tym przypadku rynek edukacyjny) i sprawić, że będzie ono atrakcyjne dla tych, którzy będą go używać. Ważne jest również, aby wybrać odpowiednią technologię. Należy podkreślić, że w dzisiejszym świecie jednymi z najbardziej istotnych cech oprogramowania są mobilność i elastyczność. Nasz produkt należało zatem zaplanować tak, aby był wieloplatformowy, dostępny dla wielu różnych systemów operacyjnych i rodzajów sprzętu komputerowego (komputery stacjonarne, laptopy, tablety itp.) i tablic multimedialnych. Ważne jest również, aby zapewnić możliwość uruchomienia programu bezpośrednio za pomocą przeglądarki internetowej (bez konieczności wcześniejszego instalowania na komputerze). Z kolei gdy komputer nie jest podłączony do Internetu lub dostęp do Internetu jest ograniczony, powinna być udostępniona wersja off-line. Musimy też w pełni zrozumieć wymagania zarówno użytkowników końcowych, jak i odbiorcy naszego produktu. W naszym przypadku odbiorca e-doświadczeń jest nauczycielem, a użytkownik jest uczniem. Aby dostosować program specjalnie do ich potrzeb, zaprosiliśmy ich do współpracy z nami. Ich wsparcie w projekcie jest wyjątkowo pomocne w rozwiązywaniu wszelkich problemów, takich jak np. dostosowanie e-doświadczeń do warunków i realiów panujących w szkole. Produkt (czyli e-doświadczenia) jest przedstawiany nauczycielom z wybranych szkół biorących udział w projekcie i wreszcie podczas testowania produktów otrzymujemy informacje zwrotne od uczniów - użytkowników e-doświadczeń. Wszystkie te opinie będą brane pod uwagę w celu umożliwienia zmiany produktu, aby uczynić go bardziej atrakcyjnym dla użytkownika (dodanie nowych funkcji, uwzględnienie sugestii dotyczące innych ćwiczeń itp.).
XX
W artykule przedstawiono i omówiono wybrane aspekty informatyczne umów outsourcingowych mających związek z wprowadzeniem do nich stanowiska aktywnego klienta.
EN
From time to time media and professional papers bring up examples of spectacular failures of IT outsourcing agreements. The multi-million contracts break off and giant international companies are bringing their IT services back home (e.g. General Motors recently). One of the main reasons leading to such disastrous failures are poorly prepared or makeshift contracts, seeking quick and easy cost savings. This paper presents the concept of so called "Active Client" (also known as "intelligent customer"), which, included into outsourcing contract, should prevent most of the common failures found in many agreements of that kind. The concept in question is based on an assumption, that it is the client who should control the execution of the outsourcing contract and should have to his disposal the proper and strong means to perform these controls. Primarily it should be via a contractual body called Contract Agreement Council, chaired by client. The Council in question should decide on strategy, plans and innovations involved in related processes. It is up to that Council to evaluate supplier's performance and its quality of service, and also to recommend future strategy to the upper management of client's organisation. This paper does not insist the concept of Active Client will make every outsourcing contract a success, instead it says the contracts without this concept included are more prone to failure. The paper also says many other numerous requirements are also to be met, to bring the outsourcing contract as a whole to the level desired. The additional effort spent on including Active Client concept into outsourcing contract would bring multiple benefits while executing such a contract, and running it smoothly to the satisfaction of all parties involved. However, should those parties fail to exploit this concept in practice, most of the effort put to include it into the contract in the first place, will simply be wasted. (original abstract)
XX
Artykuł przedstawia propozycję wybranych działań projakościowych w procesie wytwarzania oprogramowania. Prezentowane szkieletowe działania projakościowe wykorzystują podejście GQM i bezpośrednio wywodzą się z wymagań normy PN-EN ISO 9001-2001. Ich uszczegółowienie jest wykonane na podstawie standardów dziedzinowych i doświadczenia autorów. Przedstawiona propozycja zostanie praktycznie zweryfikowana w ramach projektu "Dependable Distributed Systems" 6. Programu Ramowego Unii Europejskiej, w którym reprezentowana przez autorów jednostka uczelniana jest odpowiedzialna m.in. za zarządzanie jakością. (abstrakt oryginalny)
EN
The article presents a proposal of selected pro-quality activities in software development process. The framework for such activities utilises GQM approach and is directly derived from the requirements of PN-EN ISO 9001-2001. It is refined based on domain standards and author's experience. The approach will be verified in practice during the 6 Framework Programme project "Depend-able Distributed Systems", where the authors are responsible for quality management. (original abstract)
|
|
nr nr 2
57-69
XX
Istnieje przekonanie, że potwierdzony certyfikatem system jakości zgodny z ISO serii 9000 automatycznie podnosi konkurencyjność wyrobów wobec innych producentów, chroni przed niepowodzeniami, jest swoistym parasolem ochronnym. Empiria nie potwierdza tej tezy. Okazuje się, że wśród firm, które posiadają certyfikaty, miały miejsce zarówno bankructwa, straty, jak i przejściowe kłopoty finansowe. Dlaczego tak się stało? Co stoi u podstaw efektywnego systemu jakości? Dotychczas problemy jakości rozpatrywano w aspekcie technicznym i organizacyjnym. Tym trzecim czynnikiem, który dotąd nie był rozpatrywany, a wydaje się, że wpływa znacząco na sposób wytwarzania, jest kultura organizacyjna. Kultura organizacyjna zwykle kreowana jest przez najwyższe kierownictwo w firmie lub przez założycieli organizacji. Okazuje się, że najliczniejszą grupą zawodową, pełniącą kierownicze funkcje w firmach lub prowadzącą działalność na własny rachunek, są inżynierowie. Z tego można wnioskować, że wpływ wyznawanych przez inżynierów wartości w sposób istotny kształtuje kulturę organizacyjną danej firmy. Stąd rodzi się pytanie: jakie znaczenie dla powstania i utrzymania jakości ma kultura organizacyjna oparta na etyce inżynierskiej? Czy jakość ufundowana na etyce inżynierskiej przyczynia się do powstania i utrzymania zyskowności firmy? Związek jakości z etyką wydaje się intuicyjnie prawdziwy, bowiem wytwarzanie produktów/usług o wysokiej technicznej jakości i po uczciwie wyliczonych kosztach jest działaniem akceptowanym społecznie. Jeśli tak jest w istocie to: jak silne są to więzy? (...) Na postawione wyżej pytania brakowało odpowiedzi. Zarówno badacze problemów jakości, jak etyki biznesu oraz etyki inżynierskiej nie wykazali związku między jakością a etyką, skupiając uwagę na jakości lub etyce jako dziedzinach oddzielnych. W dotychczasowym piśmiennictwie, zarówno polskim jak i światowym, tylko implicite wskazywało na powyższe związki i wynikający z tych powiązań pożytek w sferze technicznej i ekonomicznej firmy. Ze względu na wagę problemu te nie poparte badaniami, intuicyjne stwierdzenia wymagały szerszego opracowania. Wybrane badania z tego zakresu przedstawiono w niniejszym opracowaniu. (fragment tekstu)
EN
Up to now, the question of quality was based on two factors - technical and organizational. In my work that question has been extended. The third factor is organizational culture based on the engineering ethics. The technical aspects are: safety, reliability and durability. The culture of an organization is made up of the shared beliefs about how business is conducted, how employees are treated and how they behave. Quality appears to be a good business. Quality is also good ethics, because it brings customer's utility and satisfaction. My thesis is: engineer ethics and employees' morale are major factors, except the technical, to built quality and ensure technical quality products and services. If quality is profitable, then the output of the ethics' is a profitable too. Why engineers? Because they are usually managers in a technical organization. Ethical culture in an organization is based on the engineer's value. Their attitudes have influence on the employees' attitudes. Therefore engineering ethics is so important. In ethical culture all actions are based on trust, commitment and teamwork. Quality system, for example ISO 9000 and TQM, requires this support to achieve high effects. I used the outputs of my research in one of IT organization. I made a model of ethical program, which helps quality. Implementing an ethical program means creating a new: mission, vision, training and audit. Concluding the theoretical and empirical part of my work, I can say: the benefits of ethics and its output - quality, are: to increase market share, decrease costs, improve delivery and productivity, and reduce waste. Achieving this, requires a company-wide improvement of engineering ethics. (original abstract)
XX
Artykuł porusza problem doboru kryteriów, które są istotne przy ocenie jakości portali informacyjnych. Za pomocą narzędzi statystycznych wygenerowany został ranking kryteriów uwzględniający stopień, w jakim każde z kryteriów wyjaśnia całkowitą ocenę jakości portali. Następnie usuwano kolejne kryteria i badano wpływ tego działania na poprawność oceny. Poprawność rankingu uzyskanego z wykorzystaniem statystyk porównano z rankingiem kryteriów sformułowanym przez użytkowników. Artykuł kończą wnioski dotyczące przeprowadzonych badań. (abstrakt oryginalny)
EN
The article is dealing with the selection of criteria which are essential at the quality evaluation of information portals. Ranking of criteria was generated with using statistical tools. This ranking is taking into account the degree, in which every of criteria is explaining the complete evaluation to the quality of portals. In next step the criteria were being removed and an influence of this working on the correctness of the evaluation was being examined. The ranking gained with using statistics was compared with the ranking of criteria formulated by users. Conclusions concerning conducted examinations are finishing the article. (original abstract)
XX
Podjęto próbę uporządkowania modeli jakości produktów i procesów programowych, zaproponowano własny model jakości produktu oraz autorski schemat ewaluacji istniejących modeli oceny procesów. Dokonano usystematyzowania różnych definicji jakości, szczególnie w odniesieniu do produktu programowego. Opracowano schemat ewolucji nastawienia wytwórcy i nabywcy wobec jakości oprogramowania. Opisano budowę typowych modeli jakości technicznej oprogramowania. Przedstawiono przykłady modeli jakości oprogramowania. Omówiono problemy i najważniejsze cechy jakości oprogramowania, zarządzanie jakością procesów programowych. Dokonano przeglądu metod oceny i doskonalenia procesów programowych oraz ich konfrontacji przy wykorzystaniu schematu porównawczego MCS. Przedstawiono także relacje między procesami a produktami programowymi.
EN
There is an attempt to set products quality models and software processes in order. In the paper, the author has suggested his own model of product quality and evaluation schema of existing models of software process assessment. The author has presented an examples of product quality models as well as discussed some issues on the quality of software together with management of software processes quality. (AŁ)
XX
Z niedostateczną jakością produktów programowych stykamy się na każdym kroku. Produkty programowe są efektem realizacji procesów programowych. W pracy krótko zaprezentowano sposoby oceny jakości produktów programowych w konfrontacji z metodami oceny procesów programowych. Przedstawione zostały argumenty w dyskusji, co jest ważniejsze - dobra jakość produktów, czy też procesów programowych.(abstrakt oryginalny)
EN
Software products are results of software processes. In the paper shortly presented models of software product assessment (e.g. ISO/IEC 9126) and confronted them with software process assessment and improvement models (ISO 9000, CMM, ISO/IEC 15504 etc.). The discussion what is more important: product quality or process quality has been presented. (original abstract)
XX
Celem artykułu jest zaprezentowanie modelu Kano (jego autorem jest prof. N. Kano) - oryginalnej metodologii badania wymagań i oczekiwań klientów. Cechą charakterystyczną i podstawową zaletą omawianej metody jest badanie sposobu postrzegania jakości produktu z punktu widzenia klienta, a nie producenta. Prof. Kano wprowadził sześć kategorii jakościowych: jakość konieczna, zaskakująca, proporcjonalna, neutralna, odwrotna i wątpliwa. Autor artykułu proponuje wykorzystanie omawianej metodologii w procesie analizy wymagań użytkownika produktów programowych.
EN
The article presents Professor Noriaki Kano methodology of understanding and analyzing customer-defined quality. The quality of the product from customer's point of view influences his satisfaction in six different ways: must-be quality: the customer will be extremely dissatisfied if the requirement is not fulfilled, one-dimensional quality: customer satisfaction is proportional to the level of requirement fulfillment, attractive quality: not expected but if the requirement is fulfilled, it leads to more than proportional satisfaction, indifferent quality: the customer does not really care about fulfillment of the requirement, reverse quality: the customer will be extremely dissatisfied if the requirement is fulfilled in the product, questionable quality: means that the questions stated in the customer survey were phrased incorrectly or the customer made a mistake while completing the questionnaire. It can be also a symptom of misunderstanding user requirements by the producer. The adaptation of Kano model for software user requirements analysis and project management is also discussed in the paper. (original abstract)
20
Content available remote Holacracy as a New Approach to New Product Development in IT Industry - Case Study
67%
|
|
nr z. 145
279-296
EN
Purpose: The main objective of this paper was to identify and determine the potential of holacracy from the point of view of new product development in the IT industry. Design/methodology/approach: The article contains a literature review on the subject of holacracy and a detailed case study analysis conducted in two IT companies which concerned the new product development process. Also, the article presents research results of a quantitative survey and results of interviews with employees that revealed key attributes of teams working in holacracy. Findings: Research results indicate that companies tend to adapt and adjust holacracy in a unique way to meet their development needs, but such approach requires a specific organizational culture and high-tech resources. Holacracy can enhance NPD process and induce self-development among holacratic development teams, which have a dozen of unique attributes in comparison to traditional teams. Agile development with holacracy is faster and more effective than standard agile development or waterfall approach. Research limitations/implications: The research results presented in the paper were based only on two IT companies which use new approaches to new product development. Therefore, more scientific research should be carried out in the future to discuss this topic further. Practical implications: The author of the article recommends that every company should evaluate its capabilities, organizational culture and technical resources before implementing holacracy. Originality/value: This paper presents and discusses a brand new approach to new product development used by modern IT companies. Holacracy is still considered as a new and innovative approach to managing organizations.(original abstract)
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.