
- •Oop и типы данных. Основные особенности ооп.
- •Инкапсуляция. Классы и структуры.
- •9.Подходы к выделению объектов, их свойств и методов оперирования.
- •10. Уточнение характеристик объектов и редактирование их определений.
- •11. Образцы и типовые проекты при ооп.
- •12. Именование объектов и методов. Коллекции отлаженных заготовок.
- •14. Компоненты: объекты, субъекты, аспекты.
- •15. Подходы к декомпозиции программ и накоплению компонент программ
- •16. Контекст исполнения многократно используемых компонент.
- •17. Проблема версифицирования программы в процессе разработки
- •18. Перенос компонент в разные системы //возможно предыдущее подойдет
- •19. Факторизация программ и программных компонент
- •20. Жизненный цикл программ (жцп). Фазы, этапы и стадии разработки программ
- •Сопровождение
- •Классические схемы жцп. Последовательная модель жцп
- •Каскадная модель жцп. Условия завершения фаз жцп
- •Табличная модель Хантера совмещения фаз жцп.
- •Uml. Диаграммы объектов и диаграммы размещения
- •Термины и понятия
- •Общие свойства
- •Содержание
- •Uml. Временные диаграммы
- •Технологичные последовательности и техника самодокументирования.
- •Основные идеи экстремального программирования
- •Многократность и рефакторинг при разработке программ. Многократность
- •Рефакторинг
- •«Парный» эффект и обе5спечение устойчивости разработки.
- •Коллективное владение
- •2. Ссылки, указатели и переменные – отличия при использовании
- •4. Зачем нужны описатели public и private?
- •5. Перегрузка операций. Пример.
- •6. Роль ссылок в борьбе за эффективность. Пример.
- •7. Инициализация объектов. Варианты конструкторов. Пример
- •8. Указатели и вектора. Сравнение стиля доступа к компонентам
- •9. Что дает использование inline?
- •10. Производные классы. Наследование.
- •11. Деструкторы. Зачем они нужны?
- •12. Друзья
- •13. Левосторонние значения (lvalue)
- •14. Описатель const. Его влияние на присваивание значений. Пример
- •15. Объединение типов данных. Пример полезного применения
- •16. Управление видимостью членов класса и доступам к элементам объекта.
- •17. Ссылка на себя //this
- •18. Освобождение памяти от лишних объектов
- •19. Порядок выполнения конструкторов и деструкторов
Сопровождение
Устранение замеченных в ходе эксплуатации ошибок. Внесение непринципиальных усовершенствований. Накопление предложений для разработки следующей версии.
Разработка
Пре-альфа
Начальная стадия разработки — Период времени со старта разработки до выхода стадии Альфа (или до любой другой, если стадии Альфа нет). Также так называются программы, не вышедшие еще в стадию альфа или бета, но прошедшие стадию разработки, для первичной оценки функциональных возможностей в действии. В отличие от альфа и бета версий, пре-альфа может включать в себя не весь спектр функциональных возможностей программы. В этом случае, подразумеваются все действия выполняемые во время проектирования и разработки программы вплоть до тестирования. К таким действиям относятся — разработка дизайна, анализ требований, собственно разработка приложения, а также отладка отдельных модулей.
Альфа
Внутреннее тестирование — Стадия начала тестирования программы в целом специалистами-тестерами, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт. Также это может быть стадия добавления новых функциональных возможностей. Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.
Бета
Публичное тестирование — Стадия активного бета-тестирования и отладки, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости. Тем не менее программы этого этапа могут содержать достаточно большое количество ошибок.
Поскольку бета-продукт не является финальной версией, и публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. Таким образом, многие производители уходят от ответственности, предоставляя пользователям только бета-версии продукта. Так, ICQ в версии 2003 года использовала этот трюк, выпустив 2003b (b означает бета) версию этого интернет-мессенджера. Финальной версии ICQ 2003 так и не появилось, вместо этого два года спустя вышли версии ICQ 4 и ICQ 5.
Релиз–кандидат
Релиз–кандидат или RC (англ. release candidate), Пре–реализ или Pre — стадия–кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексное тестирование, благодаря чему были исправлены все найденные критические ошибки. Но в то же время существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.
Релиз
Релиз или RTM (англ. release to manufacturing, обычно не обозначается) — стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, и готовая к применению.
Классические схемы жцп. Последовательная модель жцп
Каскадная, Спиральная, Итерационная
Каскадная модель жцп. Условия завершения фаз жцп
Каскадная модель:
для каждого этапа ставится цель,затем ...и если цель этапа не достигнута, то возвращаются либо к началу этапа, либо на предыдущие
возникает проблема ... качества(особенно на предварительных этапах)
иногда из-зи несоответствия ... требований вся задача может стать бесполезной.
вики:
Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.