1.2. Методы разработки программного обеспечения

Вопросы для рассмотрения: Проект. Состав и структура коллектива разработчиков, их функции. Нисходящий анализ процесса управления проектированием программного изделия. Восходящее проектирование. Метод последовательной модернизации. Блоксхемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы. Использование CASE-средств для создания программных комплексов и их компонентов.

Рекомендуемая литература: 1.

Перечень дополнительных ресурсов: 1, 3, 4, перечень ресурсов в сети Интернет.

Наименование вида самостоятельной работы: изучение ли-

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

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

Существует два основных принципа формирования команды для управления проектом.

Ведущие участники проекта - заказчик и подрядчик (кроме них, могут быть и другие участники) создают собственные группы, которые возглавляют руководители проекта, соответственно, от заказчика и подрядчика. Эти руководители подчиняются единому руководителю проекта.

2.Для управления проектом создается единая команда во главе

сруководителем проекта. В команду входят полномочные представители всех участников проекта для осуществления функций согласно принятому распределению зон ответственности.

Для команды проекта необходимо наличие у ее членов комбинации взаимодополняющих навыков, которые составляют три категории:

1.Технические и/или функциональные, профессиональные,

навыки.

2.Навыки по решению проблем и принятию решений

3.Навыки межличностного общения (принятие риска, полезная критика, активное слушание и т д.).

Выделяют три типа проектных команд:

1.Команда проекта: основная роль данной группы – активная поддержка процесса достижения целей проекта. Участники вовлечены в проект с самого начала и заинтересованы в поиске требуемых для проекта ресурсов.

. Рабочая/процессная команда: роль данной группы – выполнение определенных задач или работ. Совместное решение поставленных задач в ходе выполнения проекта, позволяет создать высокоэффективную группу специалистов, способных включаться в проекты на любом этапе.

3.Команда управления проектом: Роль данной группы – координация, мониторинг и контроль выполнения задач проекта. Результаты исполнения организационных и управленческих функций данной группы позволяют следовать стратегии проекта и реализовывать стратегические решения.

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

−базовые концепции проектирования ПО (Software Design Basic Concepts),

−ключевые вопросы проектирования ПО (Key Issue in Software

Design),

−структура и архитектура ПО (Software Structure and Architecture),

−анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),

−нотации проектирования ПО (Software Design Notations),

−стратегия и методы проектирования ПО (Software Design Strategies and Methods).

На этапе проектирования, команда разработчиков должна следовать одному из типов:

−Если решение задач высоких иерархических уровней предшествует решению задач более низких иерархических уровней,

−Проектирование называют нисходящим (пошаговая

детализация). Если раньше выполняются этапы, связанные с низшими иерархическими уровнями, проектирование называют восходящим.

Методологии проектирования в настоящее время:

1)Нотация BPMN (Business Process Model and Notation - модель бизнес-процессов и нотация) используется для описания процессов нижнего уровня. Диаграмма

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

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

4)Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0.

5)Нотация EPC (Event-Driven Process Chain - событийная цепочка процессов) используется для описания процессов нижнего уровня.

6)SADT (Structured Analysis And Design technique) –

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

7)UML (Unified Modeling Language – унифицированный язык моделирования).

8)Стандарт описания бизнес-процессов DFD – Data Flow Diagram переводится как диаграмма потоков данных.

9)ER-модель (от англ. entity-relationship model, модель

«сущность – связь») – модель данных, позволяющая описывать концептуальные схемыпредметной области.

10)ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных.

1.3. Проектирование программного обеспечения.

Вопросы для рассмотрения: Проектирование программного обеспечения на основе объектно-ориентированного подхода. Конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных. Архитектурное проектирование. Детальное проектирование. Проектирование пользовательского интерфейса. Особенности систем визуального программирования.. Современные программный средства для формирования объемных изображений.

Рекомендуемая литература: 1.

Перечень дополнительных ресурсов: 1, 3, перечень ресурсов в сети Интернет.

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

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

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

Ход процесса проектирования ПО и его результаты будут зависеть не только от состава требований, но и от опыта проектировщика (разработчика) и от выбранной модели процесса проектирования.

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

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

Проектирование состоит из следующих этапов:

−Описания. Данный этап включает в себя совместную работу заказчика (определяет пользу продукта, требования к внешнему виду

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

−Определения архитектуры. На данном этапе утверждают язык программирования, базу данных, фреймворки и серверы.

−Разработки технического задания (ТЗ). ТЗ составляет архитектор в соответствии с описанием и ответами на вопросы заказчика. Затем ТЗ согласовывают с менеджером проекта, далее передают клиенту и производят правки.

−Этапа разработки макетов, которые затем добавляются к ТЗ. На данном этапе разрабатывают макеты принципиальных схем устройства, интерфейсов, диаграмм структуры базы данных, схем взаимодействия компонентов.

−Контроля. В ходе этого этапа архитектором устраняются замечания менеджера проектов.

−Утверждения. На данном этапе заказчиком проверяется и меняется самостоятельно ТЗ, либо сообщается список правок проектменеджеру. После устранения замечаний ТЗ утверждают и прилагают к контракту.

В результате проектирования получается техническое задание с однозначной и понятной как для заказчика, так и для исполнителя (в качестве исполнителя могут выступить руководитель проекта, программисты, тестировщики, дизайнеры и другие участники процесса разработки) иллюстрацией ответов на вопросы:

−Что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?

−Как делать (содержит описание архитектуры)? Как проверить, достигнута ли цель (варианты тестирований, критерии оценки)?