1. Виды обеспечения ВС. Понятия программы, программной системы (комплекса), программного продукта (средства, изделия), программного обеспечения.

2. Причины сложности разработки ПО.

3. Процессы жизненного цикла программного продукта по стандарту ISO/IEC 12207 (ГОСТ Р ИСО/МЭК 12207).

4. Основные процессы разработки программного продукта.

5. Основные модели и методологии разработки ПО.

6. Задачи и проблемы планирования разработки.

7. Понятие конфигурации и управления конфигурацией, задачи управления конфигурацией.

8. Модель зрелости возможностей CMM.

9. Задачи анализа требований. Основные виды работ при анализе. Назначение технического задания.

10. Варианты использования: определение, роль в жизненном цикле, UML-диаграмма, текстовые спецификации.

11. Цель и объекты проектирования. Архитектурное и детальное проектирование.

12. Виды декомпозиции системы. Основные структурные методы проектирования (по направлению декомпозиции).

13. Понятие модуля. Критерии качества проектирования модулей и классов.

14. Проектирование интерфейса пользователя (определение, классификации)

15. Проектирование интерфейса пользователя (определение, требования).

16. Повышение информативности программ: цели, основные методы.

17. Безопасное программирование.

18. Цели тестирования и отладки. Объекты и особенности процесса тестирования.

19. Виды тестирования.

20. Критерии качества тестирования.

21. Метод ручной инспекции кода; метод эквивалентов и граничных условий.

22. Тесты и тестовые процедуры (определения, принципы создания).

23. Классификация ошибок с точки зрения процесса разработки.

24. Основные программные и эксплуатационные документы (по ГОСТ 19.101-77).

25. Общее и детальное планирование испытаний.

26. Методы оценки свойств программного продукта.

27. Основные факторы качества программного продукта (по ГОСТ Р ИСО/МЭК 912693).

1 ) Виды обеспечения вс. Понятия программы, программной системы (комплекса), программного продукта (средства, изделия), программного обеспечения.

Принято выделять семь видов обеспечения ВС:

1. математическое: методы, алгоритмы;

2. лингвистическое: языки, способы взаимодействия;

3. информационное: данные;

4. программное: программы;

5. техническое: аппаратные средства;

6. методическое: документы, методики;

7. организационное: правила, регламенты, процедуры.

Под исполняемой программой (executable program) будем понимать совокупность машинного кода и данных, пригодных для исполнения процессором.

Программы делят на компоненты и комплексы (системы).

Компонент (component program) — программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса.

Программный комплекс, или программная система (program / software system) — программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.

Прошедшая испытания программа или программная система, полностью готовая для продажи (поставки) и снабженная всей необходимой документацией, называется программным продуктом, изделием или средством (software product, production program).

Программное обеспечение (software) — наиболее общее понятие, под которым понимают совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации. В зависимости от контекста использования под ПО часто понимают конкретные программы или все программы в совокупности.

2 ) Причины сложности разработки по.

1. Сложность предметной области. Область знаний имеет много проблем. Для преодоления трудностей разработчики часто стараются работать всю жизнь с одной и той же предметной областью, то есть иметь узкую специализацию.

2. Внутренняя сложность программ. Программы имеют огромную внутреннюю логическую сложность. Внутри большой программы могут существовать одновременно сотни и тысячи переменных и несколько потоков управления. Полный набор этих переменных, их текущих значений, текущего адреса и стека вызова для каждого процесса описывает состояние прикладной программы в каждый момент времени. Это состояние изменяется миллионами операторов, взаимное влияние которых очень велико: сбой в одном, как правило, приводит к неверной работе остальных.

3. Отсутствие хороших способов представления больших систем. План здания помогает архитектору и заказчику оценить пространство, возможности перемещения, виды. Становятся очевидными противоречия, можно заметить упущения. Масштабные чертежи механических деталей и объёмные модели молекул, будучи абстракциями, служат той же цели. Но программный продукт невидим и непредставим. Как только мы пытаемся графически представить структуру программы, мы обнаруживаем, что требуется не одна, а несколько схем, наложенных одна на другую. Различные схемы могут представлять управляющие потоки, потоки данных, зависимостей, временные последовательности, соотношения пространств имен. В настоящее время одной из попыток унификации «графического языка» представления программных систем является унифицированный язык моделирования UML (Unified Modeling Language).

4. Трудности управления процессом разработки. При росте количества разработчиков возникает множество самостоятельных проблем, причем эти проблемы могут из второстепенных легко перерасти в первостепенные. Чем больше людей привлекается в проект для решения проблем одного рода, тем больше проблем другого рода при этом создаётся.

Управление коллективами требует огромных знаний и ресурсов, а недостатки такого управления могут привести (и часто приводят) к краху самый перспективный проект.

5. Изменение требований к программе в процессе её разработки. Требования корректируются даже из-за того, что осуществление программного проекта часто само изменяет текущее состояние дел. Рассмотрение первых результатов (схем, прототипов) и использование системы после того, как она разработана и установлена, заставляют пользователей лучше понять и отчетливей сформулировать то, что им действительно нужно.

Чем создаваемая система больше, тем больше вероятность того, что требования к ней будут корректироваться.