9. Липаев В.В. Выбор и оценивание характеристик качества программных средств. Методы и стандарты. Серия «Информационные технологии». М.: СИНТЕГ, 2001.-228 с.
10. ГОСТ 28195-99. Оценка качества программных средств. Общие положения.
И. DTR 9126-3:2001. Software Engineering - Product Quality - Part 3:Internal Metrics // ISO/IEC JTC1/SC7 N2416, Software & System Engineering Secretariat, Canada. -2001.- 66 p.
12. DTR 9126-2:2001. Software Engineering - Product Quality - Part 2:External Metrics // ISO/IEC JTC1/SC7 N2419, Software & System Engineering Secretariat, Canada. - 2001.- Ill p.
13. DTR 9126-4:2001. Software Engineering - Software Product Quality - Part 4: Quality In Use Metrics // ISO/IEC JTC1/SC7 N2430, Software & System Engineering Secretariat, Canada. - 2001. - 70 p.
14. ISO/IEC 14598-6:1998. Information Technology - Software product evaluation – Part 6: Documentation of evaluation modules.
15. Стандартизация процессов обеспечения качества программного обеспечения (Учебное пособие) (www.aanet.ru/~web_k46/textbooks/std_pro/index4_l .htm).
16. ISO/IEC TR 15504-1:1998. Information technologies - Software process assessment -Part 1: Concepts and introductory guide.
17. ISO/IEC TR 15504-3:1998. Information technologies - Software process assessment - Part 3: Performing an assessment.
18. Paulk M.C. et al. Capability Maturity Model for Software. Version 1.1. Technical Report CMU/SEI-93-TR-024. - Software Eng.Inst, Pittsburgh, PA 15213, 1993. - 82 p.
19. Paulk M.C. et al. Key Practices of the Capability Maturity Model. Version 1.1. Technical Report CMU/SEI-93-TR-025. - Software Eng.Inst., Pittsburgh, PA 15213, 1993.-479 p.
20. Masters S., Bothwell С. СММ Appraisal Framework. Version 1.0. Technical Report CMU/SEI-95-TR-001. - Software Eng. Inst., Pittsburgh, PA 15213, 1995. - 76 p.
21. Bumes P., Phillips M. Software Capability Evaluation (SCE). Version 3.0. Method Description. Technical Report CMU/SEI-96-TR-002. - Software Eng. Inst., Pitts burgh, PA 15213, 1996. - 192 p.
22. Zubrow D. et al. Maturity Questionnaire. Technical Report CMU/SEI-94-SR-007. - Software Eng. Inst., Pittsburgh, PA 15213, 1994. - 57 p.
23. Whitney R. et al. Interim Profile: Development and Trial of Method to Rapidly Measure Software Engineering maturity Status. Technical Report CMU/SEI-94-TR- 004. - Software Eng. Inst., Pittsburgh, PA 15213, 1994. - 44 p.
24. ДСТУ 2844-94. Програмні засоби ЕОМ. Забезпечення якості. Терміни та визначення.
25. Подборка материалов о построении, внедрении и сертификации систем качества на портале UDC (www.udc.com.ua/dc/).
26. ДСТУ ISO9001-2001. Системи управління якістю. Вимоги.
27. ДСТУ ISO9004-2001. Системи управління якістю. Настанови щодо поліпшення діяльності.
28. ДСТУ ISO9000-3-98. Стандарти з управління якістю та забезпечення якості. Частина 3. Настанови щодо застосування ДСТУ 9001-95 під час розроблення, постачання та супроводження програмних засобів.
29. ДСТУ 3918-99. Інформаційні технології. Процеси життєвого циклу програмного забезпечення.
30. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. Серия «Информационные технологии». М.: СИНТЕГ, 2001. - 380 с.
31. ДСТУ 2462-94. Сертифікація. Основні поняття терміни та визначення.
32. ДСТУ 3419-96. Система сертифікації УкрСЕПРО. Сертифікація систем якості. Порядок проведення.
ЗАКЛЮЧЕНИЕ
В инженерии качества не так уж все сложно и скучно (а может быть и грустно). Главное в ней - это здравый смысл, наблюдательность, усидчивость и немного фантазии. Вот, например, рисунок в стиле авангард, обобщающий наш взгляд на проблему разработки высококачественных ПС в условиях ограниченных ресурсов проекта, а за ним - краткое изложение содержания этой .книги в переложении на человеческий язык менеджера проекта.
Пределы роста качества ПС при ее разработке
в условиях ограниченных ресурсов проекта с учетом рисков
• Проект - монолитный сплав функций будущей ПС, затрат и сроков(классический треугольник).
• Проект находится под
постоянными угрозами срыва и «окружен» риском (большой круг
риска). Нельзя допускать превышения затрат и сроков (две стороны треугольника).
Нет смысла увеличивать функциональность ПС (система не должна делать того, для
чего она не предназначена (фиксированный максимальный размер
основания
треугольника)).
• Объем функциональных возможностей будущей ПС можно «прикинуть» в самом начале проекта, применив для этого методологию FPA.
• Хорошо бы достичь
абсолютного качества ПС и «обеспечить» лучшими характеристиками каждую
«функциональную точку» в основании треугольника. Получился бы круг качества
максимального размера (окружность пунктиром). Жаль, этого нельзя добиться - такой
круг качества частично «выйдет» в области
риска
по факторам затрат и продолжительности (черные сегменты).
• Можно бы вообще не
заботиться о качестве («стянуть» круг качества в точку и забыть). Однако
остается не прикрытым сегмент риска функциональной пригодности ПС (нижний
сегмент круга риска). Это риск разработчика (заказчик откажется от уже
«почти» готовой ПС). И это риск заказчика (риск отказа ПС при
эксплуатации).
• Выход - планомерно повышать качество (от центра круга качества в направлении к его пунктирной границе), постепенно отвоевывая площадь у нижнего сегмента круга риска. Для этого - построить все необходимые процессы и начать их применять.
• Вечный вопрос - где остановиться? Нужно расширять круг качества, пока он не коснется двух сторон треугольника. Можно считать, что оставшиеся не прикрытыми кусочки нижнего сегмента риска, - это риск отказа ПС, но не по ее вине.
Если в ряды разработчиков вашего проекта случайно «затесался» научный сотрудник, да еще и математик - отдайте рисунок ему. А сами займитесь институциализацией процессов ЖЦ. Опять скучно? Вспомните слова Лапидуса -«стукните» по любому сотруднику проекта. Пока он вытянет всю цепочку проблем, у Вас будет время применить целе-ориентированный и процессо-ориентированный подходы.
Всяческих успехов.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.