Inżynieria Oprogramowania 12. Zarządzanie jakością

1. Inżynieria Oprogramowania12. Zarządzanie jakością Leszek J Chmielewski Wydział Zastosowań Informatyki i MatematykiSGGW www.lchmiel.pl

2. Źródła • Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003 • Ian Sommerville http://www.software-engin.comChapter 24: Quality Managementtekst przetłumaczony i zaadaptowany przez Leszka J Chmielewskiego, WZIM SGGW • Paul Drath, Singleimage Co., UK. Workshops on EC FP Research Programmes, 1999-2002

3. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie

4. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie

5. Wstęp • Jakość jest ważna – trzeba zarządzać jakością • Trzy główne zagadnienia: • Poziom organizacyjny: • ustalenie ram organizacyjnych dla procesów i norm, które wesprą produkcję oprogramowania o wysokiej jakości • Poziom projektu: • zastosowanie procesów i ich kontroli • ustalenie planu jakości – celów jakości i sposobów ich osiągnięcia

6. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie

7. Działania dla zarządzania jakością • Zarządzanie jakością to osobny, niezależny element kontroli procesu produkcji oprogramowania • Sprawdza zgodność z celami i normami • Zespół zarządzania jakością powinien być niezależny od zespołu wytwarzającego, aby mieć obiektywne zdanie, niezależne od zagadnień wytwarzania

8. Zarządzanie jakością a wytwarzanie

9. Planowanie jakości • Plan jakości ustala wymagane aspekty jakościowe, sposoby ich oceny, oraz najważniejsze cechy jakościowe • Plan powinien definiować proces oceny jakości • Plan powinien ustalać, które normy organizacyjne powinny być zastosowane i ewentualnie definiować dodatkowe normy

10. Plany jakości • Struktura • Wprowadzenie o produkcie • Plany związane z produktem • Cele i cechy jakości • Opisy procesów jakości • Ryzyka i zarządzanie ryzykiem • Plany jakości powinny być krótkie i zwięzłe • przeciwnie – nikt ich nie będzie czytał

11. Zakres zarządzania jakością • Ważne szczególnie dla dużych, złożonych systemów • Dokumentacja jest zapisem postępu prac i ułatwia ciągłość produkcji na wypadek zmian w zespole • Dla mniejszych systemów zarządzanie jakością wymaga mniej dokumentacji i powinno skupiać się na tworzeniu kultury jakości • Zasadniczo, celem zarządzania jakością jest właśnie wytworzenie pożądanej kultury jakości

12. Jakość oprogramowania • Prosto: zgodność produktu ze specyfikacją • Dla systemów oprogramowania jest to problematyczne • Napięcie pomiędzy wymaganiami jakości ze strony klienta (wydajność, niezawodność, ...)i producenta (zdatność do pielęgnacji, wielokrotne użycie, ...) • Niektóre wymagania trudno jednoznacznie wyrazić • Specyfikacja jest zwykle niepełna i często niekonsekwentna • Kryterium może być raczej przydatność produktu do celów klienta

13. Przydatność do celów • Czy standardy programowania i dokumentacji były stosowane? • Czy oprogramowanie zostało odpowiednio przetestowane? • Czy oprogramowanie jest wystarczająco niezawodne, aby je wprowadzić do użytkowania? • Czy wydajność oprogramowania jest do przyjęcia dla normalnej eksploatacji? • Czy oprogramowanie jest łatwe w użyciu? • Czy oprogramowanie ma dobrą strukturę i jest zrozumiałe? • Czy oprogramowanie realizuje to, czego po nim oczekiwano? • Obciążenie helpdesku nie jest miarą jakości

14. Atrybuty jakości

15. Atrybuty jakości

16. Konflikty jakości • Nie można zoptymalizować wszystkich atrybutów jednocześnie – na przykład, odporność (na co?; krzepkość) jest zwykle sprzeczna z wydajnością • Plan jakości powinien zatem definiować cechy najważniejsze • Plan powinien także zawierać definicję procesu oceny jakości – uzgodnionego sposobu oceny, czy konkretne atrybuty, takie jak np. zdatność do pielęgnacji lub odporność, są obecne w produkcie

17. Jakość procesu a jakość produktu • Jakość produktu jest pod wpływem jakości procesu produkcyjnego • W tworzeniu oprogramowania jest to istotne, gdyż niektóre atrybuty jakościowe oprogramowania są trudne do oszacowania • Jednakże, relacja pomiędzy procesem produkcyjnym a jakością produktu jest mało zrozumiała i słabo zbadana • W produkcji ważne są indywidualne zdolności i doświadczenie • Czynniki zewnętrzne, jak nowość aplikacji lub wymaganie przyspieszonego dostarczenia mogą źle wpływać na jakość produktu

18. Jakość produktu oparta na procesie Zdefiniujproces Rozwińprodukt Oceń jakośćproduktu Jakośćproduktuodpowiednia? Opracuj standardprocesu Nie Tak Poprawproces

19. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie

20. Standardy oprogramowania • Standardy (normy) definiują wymagane cechy produktu lub procesu. Są ważne w zarządzaniu jakością. • Normy mogą być międzynarodowe, narodowe, firmowe lub projektowe • Normy produktowe definiują cechy, które mają charakteryzować wszystkie komponenty oprogramowania, na przykład • wspólny stylprogramowania • jednolity styl dokumentowania • jednolity styl komunikacji z użytkownikiem • ... • Normy procesowe definiują jak należy realizować proces

21. Ważność standardów • Obudowanie najlepszych praktyk – unikanie powtarzania błędów • Są ramą dla określenia co oznacza jakość w konkretnym przypadku, tzn. jakość z punktu widzenia organizacji • Zapewniają ciągłość – nowi pracownicy rozumieją organizację rozumiejąc używane w niej standardy

22. Standardy produktu i procesu

23. Problemy ze standardami • Mogą być uważanie za nieistotne lub nieaktualne przez inżynierów • Często wymagają biurokratycznego wypełniania formularzy • Jeśli nie są wsparte oprogramowaniem narzędziowym, pielęgnacja dokumentacji jakości często wymaga nudnego wypełniania formularzy • Sposób? Dalej.

24. Rozwój standardów • Zaangażuj praktyków w rozwój standardów • Inżynierowie powinni rozumieć uzasadnienie dla standardu • Regularnie przeglądaj standardy i ich użycie • Standardymogą się szybko starzeć • Obniża to ich wiarygodność wśród praktyków • Szczegółowe standardy powinny mieć wsparcie w postaci wyspecjalizowanych narzędzi • Nadmierna praca urzędnicza powoduje najwięcej narzekań na standardy • Formularze w sieci nie wystarczą

25. Standardy ISO 9001 • Do budowy systemów zarządzania jakością można użyć międzynarodowego zbioru norm • ISO 9001, najbardziej ogólna z norm tego rodzaju, stosuje się do organizacji które projektują, rozwijają i obsługują produkty • w tym oprogramowanie • Norma ISO 9001 jest ramą dla budowy standardów oprogramowania • Ustala ogólne zasady jakości, opisuje procesy jakości w ogólności i przedkłada standardy i procedury organizacyjne, które należy zdefiniować. • Należy je opisać w firmowym podręczniku jakości

26. Główne procesy ISO 9001 • Procesy dostarczania produktu • przyjmowanie zamówienia • projektowanie i rozwój • testowanie • produkcja i dostarczanie • serwis i wsparcie • Procesy wspierające • zarządzanie biznesowe • zarządzanie dostawcami • zarządzanie zasobami • zarządzanie konfiguracjami

27. ISO 9001 i zarządzanie jakością Model jakościISO 9001 jego egzemplarzemjest Firmowypodręcznikjakości Firmowy proces jakości dokumentuje jego egzemplarzemjest jest użytyprzy opracowaniu Plan jakościprojektu 1 Plan jakościprojektu 2 Plan jakościprojektu 3 Zarządzaniejakością projektów wspomaga

28. Certyfikacja ISO 9001 • Standardy jakości i procedury powinny być udokumentowane w firmowym podręczniku jakości • Zewnętrzna instytucja certyfikuje, że formowy podręcznik jakości jest zgodny z normą ISO 9001 • Niektórzy klienci wymagają, by dostawcy mieli certyfikat ISO 9001, jakkolwiek potrzeba elastyczności jest uważana za coraz ważniejszą

29. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie I

30. Podsumowanie • Zarządzanie jakością oprogramowania jest związane z zapewnieniem, że oprogramowanie ma mało defektów i że spełnia wymagane standardy niezawodności, zdatności do pielęgnacji, przenośności itd. • Zarządzanie obejmuje standardy dla procesu i produktu oraz sposoby sprawdzania zgodności z tymi standardami • Standardy oprogramowania są ważne, ponieważ reprezentują najlepsze praktyki • Procedury zarządzania jakością mogą być udokumentowane w firmowym podręczniku jakości • Można skorzystać z ogólnego modelu podręcznika jakości zasugerowanego przez normę ISO 9001

31. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki (UK) • Podsumowanie II

32. Software measurement and metrics Chapter 24 Quality management 32 • Software measurement is concerned with deriving a numeric value for an attribute of a software product or process. • This allows for objective comparisons between techniques and processes. • Although some companies have introduced measurement programmes, most organisations still don’t make systematic use of software measurement. • There are few established standards in this area.

33. Software metric Chapter 24 Quality management 33 • Any type of measurement which relates to a software system, process or related documentation • Lines of code in a program, the Fog index, number of person-days required to develop a component. • Allow the software and the software process tobe quantified. • May be used to predict product attributes or to control the software process. • Product metrics can be used for general predictions or to identify anomalous components.

34. Predictor and control measurements Chapter 24 Quality management 34

35. Use of measurements Chapter 24 Quality management 35 • To assign a value to system quality attributes • By measuring the characteristics of system components, such as their cyclomatic complexity, and then aggregating these measurements, you can assess system quality attributes, such as maintainability. • To identify the system components whose quality is sub-standard • Measurements can identify individual components with characteristics that deviate from the norm. For example, you can measure components to discover those with the highest complexity. These are most likely to contain bugs because the complexity makes them harder to understand.

36. Metrics assumptions Chapter 24 Quality management 36 • A software property can be measured. • The relationship exists between what we can measure and what we want to know. We can only measure internal attributes but are often more interested in external software attributes. • This relationship has been formalised and validated. • It may be difficult to relate what can be measured to desirable external quality attributes.

37. Relationships between internal and external software attributes Chapter 24 Quality management 37

38. Problems with measurement in industry Chapter 24 Quality management 38 • It is impossible to quantify the return on investment of introducing an organizational metrics program. • There are no standards for software metrics or standardized processes for measurement and analysis. • In many companies, software processes are not standardized and are poorly defined and controlled. • Most work on software measurement has focused on code-based metrics and plan-driven development processes. However, more and more software is now developed by configuring the enterprise resource planning systems (ERP) or commercial-off-the-shelf systems (COTS). • Introducing measurement adds additional overhead to processes.

39. Product metrics Chapter 24 Quality management 39 • A quality metric should be a predictor of product quality. • Classes of product metric • Dynamic metrics which are collected by measurements made of a program in execution • Static metrics which are collected by measurements made of the system representations • Dynamic metrics help assess efficiency and reliability • Static metrics help assess complexity, understandability and maintainability.

40. Dynamic and static metrics Chapter 24 Quality management 40 • Dynamic metrics are closely related to software quality attributes • It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute). • Static metrics have an indirect relationship with quality attributes • You need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability.

41. Static software product metrics Chapter 24 Quality management 41

42. Static software product metrics Chapter 24 Quality management 42

43. The CK object-oriented metrics suite Chapter 24 Quality management 43

44. The CK object-oriented metrics suite Chapter 24 Quality management 44

45. Software component analysis Chapter 24 Quality management 45 • System component can be analyzed separately using a range of metrics. • The values of these metrics may then compared for different components and, perhaps, with historical measurement data collected on previous projects. • Anomalous measurements, which deviate significantly from the norm, may imply that there are problems with the quality of these components.

46. Measurement surprises Chapter 24 Quality management 46 • Reducing the number of faults in a program leads to an increased number of help desk calls • The program is now thought of as more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase; • A more reliable system is used in a different way from a system where users work around the faults. This leads to more help desk calls.

47. Plan • Wstęp • Jakość oprogramowania • Standardy • Pomiary oprogramowania i metryki • Podsumowanie II

48. Key points Chapter 24 Quality management 48 • Software measurement can be used to gather data about software and software processes. • Product quality metrics are particularly useful for highlighting anomalous components that may have quality problems.

49. Mapa Mole’a Polska? Komisja Europejska? Rosja Indywidualne Francja Hiszpania USA Niemcy Belgia Przywództwo Portugalia System jakości Włochy Irlandia Holandia Luksemburg UK Dania Grecja Grupowe Organiczna(Biologiczna) Systematyczna Organizacja Zaadaptowano na podstawie: Paul Drath, Singleimage Co., Workshops on EC FP Research Programmes, 1999-2002 (z pamięci)