- •9. Использование itil для обеспечения качества при проектировании пс.
- •Стандарты iso, используемые при обеспечении качества процессов создания пс.
- •10 . Методология «6 сигма» и качество пс.
- •11. Cmmi и iso/iec 15504 – сходства и различия.
- •32. Документ "Программа-методика испытания программного средства". Содержание и сфера применения
- •34. Понятие метода и технологии проектирования программных средств
- •Требования к технологии
- •7 Стандартизация пс.
- •13. Достоинства и недостатки cmm/cmmi
- •24. Стадии разработки пс: технический проект.
- •19. Интеграция и установка пс.
- •23. Стадии разработки пс: рабочий проект.
- •18 Приёмка и сопровождение пс.
- •21. Подготовительные работы, анализ требований к системе, проектирование архитектуры системы на высоком уровне
- •17. Жизненный цикл пс (общие сведения).
- •20. Детальное проектирование, кодирование и тестирование пс.
- •25 . Стадии разработки пс: эскизный проект.
- •26. Стадии разработки пс: стадия разработки тз.
- •29. Основы качества пс.
- •31 . Структурное программирование
- •33. Программная инженерия. Понятие модели архитектуры по.
- •35. Основные понятия связанные с управлением требованиями
- •1) Финансовые
- •2) Временные
- •3) Кадровые
- •4) Аппаратурные
- •36. Характеристики качественных требований. По-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными:
- •40. Виды испытаний пс.
- •22. Стадии разработки пс: внедрение.
- •37 Виды ресурсов жизненного цикла программных средств
- •1) Финансовые
- •2) Временные
- •3) Кадровые
- •4) Аппаратурные
1) Финансовые
При этом необходимо учитывать затраты на разработку, закупку и эксплуатацию системы качества, на технологию и комплекс автоматизации проектирования программ и баз данных, которые могут составлять существенную часть совокупной стоимости и трудоемкости разработки и всего ЖЦ ПС.
2) Временные
Время или допустимая длительность разработки определенных версий ПС является "невосполнимым ограниченным ресурсом реальных проектов. Этот ресурс все больше определяет достижимое качество комплексов программ в процессе их разработки и сопровождения. Высокие требования заказчиков к сжатым срокам реализации проектов, естественно, ограничивают разработчиков и испытателей в продолжительности и объеме возможного системного анализа и проектирования, разработки и, особенно, тестирования программ.
3) Кадровые
Кадры специалистов можно оценивать численностью, а также тематической и технологической квалификацией, которые всегда ограничены. Определяющими являются совокупная численность и структура коллектива, а также его подготовленность к коллективной разработке конкретного типа ПС и к применению им системы обеспечения качества функционирования.
4) Аппаратурные
Доступные разработчикам ПС вычислительные ресурсы объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС. В процессе проектирования целесообразно выделять определенные ресурсы ЭВМ на оперативное обеспечение качества, повышение защищенности и надежности функционирования. Допустимая величина и рациональное распределение ресурсов ЭВМ на отдельные методы улучшения определенных конструктивных характеристик качества ПС, оказывают существенное влияние на достигаемые их значения.
36. Характеристики качественных требований. По-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными:
Характеристика |
Объяснение |
Единичность |
Требование описывает одну и только одну вещь. |
Завершённость |
Требование полностью определено в одном месте и вся необходимая информация присутствует. |
Последовательность |
Требование не противоречит другим требованиям и полностью соответствует внешней документации. |
Атомарность |
Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости. |
Отслеживаемость |
Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано. |
Актуальность |
Требование не стало устаревшим с течением времени. |
Выполнимость |
Требование может быть реализовано в пределах проекта. |
Недвусмысленность |
Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировка. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено. |
Обязательность |
Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования. |
Проверяемость |
Реализованость требования может быть определена через |