- •1. Методы создания программных средств. Основные направления.
- •2. Различия программирования и разработки.
- •3. Виды программ, программной и эксплуатационной документации по еспд.
- •4. Понятие о классификации технологий разработки программного обеспечения.
- •5. Постановка задачи.
- •6. Выбор и обоснование метода решения.
- •7. Понятие и основные модели жизненного цикла программного продукта.
- •Спиральная модель жизненного цикла программного продукта, ее достоинства и недостатки.
- •9. Перечень, содержание и приемы выполнения работ на этапе разработки программного продукта.
- •10. Определение основных понятий программирования: алгоритм, программа, абстракция, операторная схема, оператор языка программирования, оператор перехода, цикл, программный модуль.
- •11. Технологии программирования. Основные понятия.
- •12. Основные этапы развития программирования как науки.
- •13. Понятие case – технологии и ее фундаментальные принципы. Основные составляющие case-технологии.
- •14. Система стандартов iso 9001.
- •15. Управление конфигурацией. Case-системы.
- •16. Понятие технологии программирования
- •17. Этапы решения задачи на эвм
- •18. Основные положения решения задач на эвм
- •19. Разработка технического проекта
- •20. Виды языков программирования (по поколениям используемого исходного кода, по проблемной ориентации языка)
- •21. Структурное программирование
- •22. Нисходящее проектирование
- •23. Восходящее проектирование
- •24. Проектирование, разработка и сопровождение информационных систем
- •25. Системный анализ предметной области
- •26. Подготовка документации на программные средства в соответствии с госТами
- •27. Модульное программирование
- •Прочность по совпадению.
- •28. Организация связей между модулями
- •29. Коллективная работа по созданию программного обеспечения
- •30. Программная инженерия: назначение, основные принципы и понятия
- •31. Метод программной инженерии
- •32. Введение в объектно-ориентированное программирование(ооп).
- •33. Ооп. Структуры
- •35. Основные этапы проектирования программы
- •36. Основные направления в программировании
- •38. Основные этапы технологического процесса разработки программ
- •39. Разработка технического задания на программную систему. Функциональные требования
- •40. Пояснительная записка
- •41. Качество программного изделия
- •42. Стиль программирования
- •43. Тестирование программного обеспечения. Основные принципы разработки тестов для программных продуктов. Особенности тестирования объектно - ориентированных программ.
- •44. Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
- •45. Способы тестирования программ, состоящих из модулей (блоков).
- •46. Два критерия полноты тестирования. Причины появления второго критерия.
- •47. Отладка программы. Программные ошибки. Категории программных ошибок.
- •48. Методы отладки программного обеспечения
- •49. Критерии черного ящика.
- •Методы стратегии чёрного ящика:
- •50. Критерии белого ящика
- •51. Минимально грубое тестирование
- •52. Модели надежности программных систем
- •53. Измерения и оценка качества программного обеспечения
- •54. Динамическая модель Шумана
- •56. Статические модели надежности
- •57. Модель Миллса
- •58. Простая интуитивная модель
- •59. Модель Коркорэна
- •60. Типы пользовательских интерфейсов и этапы их разработки
- •61. Пользовательская и программная модели интерфейсов
- •62. Пользовательские интерфейсы прямого манипулирования и их проектирование
- •63. Классификации диалогов и общие принципы их разработки
- •64. Каскадная модель жизненного цикла программного продукта. Ее достоинства и недостатки.
- •72. Построение концептуальной модели предметной области
28. Организация связей между модулями
Сцепление модулей является мерой зависимости модулей по данным и определяется как способом передачи данных между модулями, так и свойствами передаваемых данных.
Виды сцепления:
Сцепление по содержимому. Модуль ссылается на данные другого модуля и вызывающий модуль, обращаясь к внутренним компонентам вызываемого модуля, не только передаёт управление, но и изменяет внутренние данные вызываемого модуля (содержание вызываемого модуля должно учитываться при разработке вызывающего).
Сцепление по общей области. Модули ссылаются на одну и ту же глобальную структуру данных.
Сцепление по управлению. Один модуль управляет работой другого модуля. При этом в вызываемый модуль передаётся значение управляющей переменной. Предполагается, что вызывающий модуль знает логику работы вызываемого модуля.
Сцепление по формату (образцу). Модули ссылаются на одну и ту же структуру данных.
Сцепление по данным. Передаются параметры из одной программы в другую.
При разработке модульной структуры ПО следует стремиться к усилению связей в модулях и ослаблению их взаимодействия. Оценка приемлемости программного модуля осуществляется по следующим параметрам:
размер модуля (от нескольких десятков до нескольких сотен операторов);
прочность модуля и сцепление с другими модулями;
рутинность модуля.
29. Коллективная работа по созданию программного обеспечения
Коллективное владение кодом позволяет каждому разработчику выдвигать новые идеи в любой части проекта, изменять любую строку программы, добавлять функциональность, фиксировать ошибку и проводить реорганизацию. Один человек просто не в состоянии удержать в голове проект нетривиальной системы. Благодаря коллективному владению кодом снижается риск принятия неверного решения и устраняется нежелательная зависимость проекта от одного человека. Работа начинается с создания тестов модуля, она должна предшествовать программированию модуля. Тесты необходимо помещать в библиотеку кодов вместе с кодом, который они тестируют. Тесты делают возможным коллективное создание кода и защищают код от неожиданных изменений. В случае обнаружения ошибки также создается тест, чтобы предотвратить ее повторное появление. Кроме тестов модулей, создаются тесты приемки, они основываются на пользовательских историях. Эти тесты испытывают систему как «черный ящик» и ориентированы на требуемое поведение системы. На основе результатов тестирования разработчики включают в очередную итерацию работу над ошибками.
Все коды в проекте создаются парами программистов, работающими за одним компьютером. Парное программирование приводит к повышению качества без дополнительных затрат времени. А это, в свою очередь, уменьшает расходы на будущее сопровождение программной системы.
Во время очередной итерации всех сотрудников перемещают на новые участки работы. Такие перемещения помогают устранить изоляцию знаний.
Код нужно постоянно обновлять – удалять лишние части, убирать ненужную функциональность. Этот процесс называют реорганизацией кода. Реорганизация поддерживает прозрачность и целостность кода, обеспечивает его легкое понимание, исправление и расширение. На реорганизацию уходит значительно меньше времени, чем на сопровождение устаревшего кода.
Еще одна составляющая коллективного владения кодом – непрерывная интеграция. Без последовательной и частой интеграции результатов в систему разработчики не могут быть уверены в правильности своих действий. Кроме того, трудно вовремя оценить качество выполненных фрагментов проекта и внести необходимые коррективы. По возможности разработчики должны интегрировать и публично отображать, демонстрировать код каждые несколько часов. Интеграция позволяет объединить усилия отдельных пар и стимулирует повторное использование кода.