- •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) Аппаратурные
24. Стадии разработки пс: технический проект.
Стадия – наиболее укрупнённое составляющее процесса разработки, по завершении которой характерно получение программного обеспечения в определённой степени готовности.
Стадия разработки программного средства предусмотрены ГОСТ 19.102-77 ЕСПД. стадия разработки.
1. Стадия технический проект(техническое проетирование).
Разработка технического проекта - на этом этапе выполняются:
- сбора исходных данных
- определения цели разработки, т.е. желаемого набора основных свойств и функций разрабатываемого программного средства
- обоснования и выбора критерий эффективности и качества разработки
- формирование на верхнем уровне состава входной и выходной документации
- выбора принципиальных методов решения задач
- определение требований к комплексу технических средств и операционному окружению
- определение инструментальных средств, используемых для разработки
Утверждение технического проекта - на этом этапе выполняются:
разработка плана мероприятий по разработке и внедрению программы , т.е. разложение процесса на стадии и этапы с установлением сроков их выполнения
разработка пояснительной записки(технического задания);
согласование и утверждение технического проекта.
14. Модульное программирование (МП). Модульное программирование основано на понятии модуля - логически взаимосвязанной совокупности функциональных элементов, оформленных в виде отдельных программных модулей. Модуль характеризуют: - один вход и один выход - на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO (Input - Process - Output) - вход-процесс-выход; - функциональная завершенность - модуль выполняет перечень регламентированных операций для реализации каждой отдельной функции в полном составе, достаточных для завершения начатой обработки; - логическая независимость - результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей; - слабые информационные связи с другими программными модулями - обмен информацией между модулями должен быть по возможности минимизирован; - обозримый по размеру и сложности программный элемент.
Таким образом, модули содержат определение доступных для обработки данных, операции обработки данных, схемы взаимосвязи с другими модулями. Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело - способ реализации процесса обработки. Архитектура МП позволяет:
выделить группы подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули (библиотеки подпрограмм), например, модуль графических ресурсов, модуль подпрограмм вывода на принтер.
осуществлять связи между модулями через специальный интерфейс,
запретить доступ к реализации модуля (телам подпрограмм и некоторым «внутренним» переменным).
Технологию МП поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.
Использование МП упрощает разработку программ несколькими программистами:
внутренняя организация модулей скрыта и потому может изменяться независимо;
взаимодействие модулей осуществляется через специально оговоренные интерфейсы модулей;
модули в дальнейшем могут использоваться в других разработках, что увеличивает производительность труда программистов.
Практика программирования показывает, что структурный подход в сочетании с МП позволяет получать достаточно надежные программы, размер которых не превышает 100000 операторов.
Недостатки МП:
ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы (из-за раздельной компиляции модулей обнаружить эти ошибки раньше невозможно).
при увеличении размера программы свыше 100 000 операторов возрастает сложность межмодульных интерфейсов, и предусмотреть взаимовлияние отдельных частей программы становится практически невозможно.
Стремление уменьшить количество связей между отдельными частями программы приводит к появлению объектно-ориентированного программирования (ООП).