Вопросы

1. Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

2. Жизненный цикл программного обеспечения. Стандарты, регламентирующие жизненный цикл

3. Общие принципы проектирования систем. Модели программного обеспечения и их место в процессе проектирования

4. Объектная модель

5. Определение и история создания языка UML. Состав диаграмм UML

6. Назначение диаграммы вариантов использования. Основные обозначения. Отношения на диаграмме вариантов использования

7. Диаграмма классов. Разновидности классов. Атрибут класса. Операции класса. Отношения на диаграмме классов

8. Назначение диаграммы последовательности. Объекты, их графическое представление. Линия жизни и фокус управления. Особенности изображения моментов создания и уничтожения объектов

9. Проектирование классов. Проектирование баз данных

10. Технология создания программного обеспечения. Rational Unified Process (RUP)

1 Определение проекта и проектирования. Основные особенности и проблемы современных программных проектов

Основой проектирования программного обеспечения является системный подход. Системный подход – это методология исследования объекта любой природы как системы. Система – это совокупность взаимосвязанных частей, работающих совместно для достижения некоторого результата. Определяющий признак системы – поведение системы в целом не сводимо к совокупности поведения частей системы.

Программное обеспечение (ПО) – это система, включающая в себя: компьютерные программы; документацию; данные, необходимые для корректной работы программ.

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

При создании программных систем выделяется ряд причин неудачных проектов:

1. недостаточно адекватное управление требованиями;

2. несогласованность требований, проектных решений и реализации;

3. жесткая архитектура ПО;

4. нарастающая сложность ПО;

5. неточная и противоречивая коммуникация;

6. недостаточное тестирование;

7. субъективное отношение к приоритетам отдельных артефактов¹ проекта;

8. игнорирование рисков и отсутствие процедур управления рисками;

9. бесконтрольное внесение изменений в артефакты проекта;

10. недостаточное использование CASE-средств и средств поддержки отдельных этапов проекта.

К причинам создания неудачных проектов относится и отсутствие моделей при разработке ПО:

1. не позволяет справиться с растущей сложностью разрабатываемых программных систем;

2. не позволяет эффективно управлять разработкой в условиях изменяющихся требований;

3. создает барьеры непонимания: аналитик не понимает руководителя проекта, разработчик – аналитика, тестировщик – разработчика и пр.;

4. не позволяет обеспечить контроль изменений в процессе выполнения работ;

5. не позволяет избежать субъективности в оценке качества разрабатываемых продуктов.

Модель (model) — абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме.

В ходе создания программных систем возникает необходимость разработки визуальных моделей.

Лучшие практики разработки ПО:

1. использование визуальных моделей при разработке ПО;

2. итеративная² разработка ПО;

3. управление требованиями;

4. управление изменениями и конфигурацией артефактов ПО;

5. использование компонентных архитектур;

6. непрерывное тестирование и верификация³ качества ПО;

7. использование паттернов⁴ проектирования;

8. использование CASE-средств и RAD-средств⁵;

9. управление рисками:

• технологическими рисками;

• связанными с требованиями;

• связанными с квалификацией персонала проекта;

• политическими рисками.

Визуальное моделирование есть моделирование с использованием некоторой графической нотации.

На входе моделей неструктурированная информация. Информация может быть описана в любом виде (текстовом документе, интервьирование⁶ сотрудников).

На выходе – модели ПО и бизнес-процессов. Модели должны адекватно отражать характер соответствующей предметной области. Необходима фиксация определенной нотации.