ТРПО-лекции

Скачано с сайта http://ivc.clan.su

Таблица 7-11. Роли и задачи проектной группы в ходе итерации

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

нениями

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

8. ОРГАНИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

8.1. Группа проекта и роли участников группы

Проектная группа (development team) – сообщество работающих над проектом людей, объединѐнных с целью создания качественного программного продукта в ограниченные сроки в рамках отведѐнного бюджета.

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

8.1.1. Руководитель проекта – Program manager

Software development manager, Project manager, Producer

Руководитель проекта отвечает за разработку качественного продукта в срок и в рамках установленного бюджета.

Основные виды деятельности:

−планирование работы и составление бюджета;

−принятие критичных для хода проекта решений;

−ведение графика проекта и обеспечение соблюдения сроков;

−координирование работ (управление взаимоотношениями) в группе;

−управление функциональными спецификациями (техническими заданиями).

8.1.2. Менеджер по маркетингу – Product manager

Product marketing manager

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Разработчиков, как правило, бывает несколько.

Разработчики отвечают за удовлетворѐнность заказчика.

8.1.3.1. Разработчик архитектуры – Architect

Архитектор отвечает за архитектуру продукта, которая понятна, проста, эффективна, надѐжна и поддаѐтся модификации.

Архитектура – это описание структуры ПС. При проектировании архитектуры определяют подсистемы, а также управление подсистемами и их взаимодействие.

Задачи архитектора:

−определение общей архитектуры системы (кода и данных);

−определение принципов обмена данными между связанными компонентами;

−определение стратегии разработки повторно используемых компонент;

−составление плана тестирования чѐрного ящика на самом верхнем уровне;

−разработка тестов, проверяющих соответствие кода техническому заданию.

8.1.3.2. Аналитик предметной области – Software analyst

Subject matter

Аналитик отвечает за правильность понимания решаемых задач.

Задачи аналитика:

−обеспечение связи между заказчиком и проектной группой;

−понимание того, что хотят пользователи;

−понимание того, как выразить желания пользователя в терминах, понятных участникам проектной группы;

−разработка логики работы программного продукта;

−составление рабочих спецификаций (детальных технических заданий).

8.1.3.3. Специалист по интерфейсу – User interface designer

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

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

8.1.3.4. Программист – Programmer

Программист отвечает за надѐжный и полный продукт.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

−создание продукта, удовлетворяющего техническому заданию;

−тестирование белого ящика (обеспечение качества кода);

−обеспечение срока разработки кода;

−обеспечение установки программного продукта.

8.1.4. Тестер – Tester

Тестер отвечает за согласованный и надѐжный продукт.

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

Задачи тестера:

−разработка стратегии и плана тестирования каждого этапа жизненного цикла;

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

−комплексное тестирование проекта;

−документирование результатов тестирования.

8.1.5. Технический писатель – Writer

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

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

−разработка документации (всевозможные инструкции и руководства), которая помогает сделать ПС понятным для пользователей и всех разработчиков;

−ведение глоссария (определение единой терминологии);

−обучение пользователей.

8.1.6. Представитель группы технической поддержки – Logistic

Technical support

Логистик отвечает за гладкое внедрение продукта.

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

Задачи представителя группы технической поддержки:

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

−администрирование локальной сети (если необходимо);

−отслеживание запросов на расширение функциональных возможностей.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

8.2. Модель проектной группы

Модель проектной группы – структура, позволяющая контролировать постоянно меняющиеся требования в проекте, который ведѐт группа проекта.

Модель группы проекта:

−вводит понятие роли для всех участников группы;

−даѐт чѐткое определение зон ответственности каждой роли;

−определяет активность роли в течение всего жизненного цикла.

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

Рис. 8-1. Модель группы проекта

В модели определены шесть ролей:

1.Менеджер по маркетингу – Product manager.

2.Руководитель проекта – Program manager.

3.Разработчик – Developer.

4.Тестер – Tester.

5.Технический писатель – Writer.

6.Логистик – Logistic.

Характеристики группы проекта:

1.Общение каждого с каждым, причѐм каждый делает реальную работу.

2.Общие для всех членов группы цели и планы.

3.Каждый понимает как проблемы пользователя, так и проблемы разработчика.

4.Каждый несѐт ответственность за свою работу перед группой.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 127

В этой модели отсутствует иерархия участников группы, потому что вопрос кто кому подчинѐн? теряет смысл. Однако существует несколько моментов, на которые также следует обращать внимание:

−большая численность группы проекта может требовать много времени на общение, чтобы реализовать первую характеристику;

−высшее руководство имеет ограниченный контроль над процессами внутри группы;

−участники группы должны полностью понимать и принимать свои роли.

Для небольших проектов некоторые роли могут быть совмещены (рис. 8-2), и могут выполняться одним человеком.

Рис. 8-2. Совмещение ролей

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

Рис. 8-3. Основной состав группы

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

Количество участников определяется как сложностью проекта, так и масштабами организации. Естественно, что каждая организация-разработчик имеет свою модель группы проекта, и свою методологию создания программных продуктов, которые в конечном итоге и определяют корпоративную культуру организации.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 128

Подгруппы могут быть функциональными, или, в свою очередь, тоже могут быть разбиты на ещѐ меньшие подгруппы. Это даѐт возможность организовать параллельную работу над проектом. Каждая группа от самого высокого до самого низкого уровня состоит не более чем из трѐх-семи человек (рис. 8-4). Группы работают в тесном контакте друг с другом и обеспечивают процессы жизненного цикла.

Рис. 8-4. Подгруппы группы проекта

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

9. АВТОМАТИЗАЦИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

−Организация взаимодействия разработчиков.

−Осуществление контроля над версиями.

−Организация безопасного хранения компонент.

−Организация повторного использования компонент.

−Обеспечение интеграции инструментов, используемых разработчиками.

9.1.Визуальное моделирование

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

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

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

−стандарта для описания моделей;

−инструмента, поддерживающего такой стандарт и позволяющего визуально отображать модели.

Множество компаний занялись разработкой подобного стандарта и инструментов. В результате появился на свет Unified Modeling Language. В настоящее время имеется целый ряд инструментальных средств, производители которых заявляют о

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 129

поддержке UML. Среди этих средств можно выделить Rational Rose, ArgoUML, Magic draw, Select Enterprise, JUDE.

Средства визуального моделирования позволяют:

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

−Описать систему в наглядной для человека графической форме с применением стандартной нотации (например, UML).

−Показать различные аспекты ПС при помощи моделей (например, функционирование – Use case View, логическую организацию – Logical View, физиче-

скую структуру – Component View, Deployment View).

−Найти необходимые решения, относящиеся к программной реализации (например, сценарии взаимодействия Sequence Diagrams, параллельные потоки

Activity Diagrams, потоки данных Collaboration Diagrams).

−На основе моделей создавать проект в виде исходных текстов на различных языках программирования (например, С++, JAVA, Ada, Visual Basic).

−Спроектировать базу данных и получить еѐ логическую модель из объектной модели ПС.

−Выявить повторно используемые программные компоненты, что даѐт возможность сократить объѐм кодирования.

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

Всѐ это необходимо для того, чтобы полностью поддерживать принцип итерационного проектирования при разработке ПС.

Однако, создание ПС – это не только построение модели. Чем сложнее и шире проект, тем в большей степени он требует инструментальной поддержки всех этапов жизненного цикла.

9.2. CASE-средства

CASE (Computer-Aided Software Engineering) – система автоматизированной разра-

ботки программ, или CASE-средство.

К CASE-средствам относятся инструментальные средства для автоматизации процессов жизненного цикла программного обеспечения.

Современные CASE-средства имеют следующие отличительные черты:

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

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 130

Интегрированное средство автоматизированной разработки поддерживает полный жизненный цикл и содержит следующие основные компоненты:

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

2.Графические средства анализа и проектирования. Обеспечивают создание и ре-

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

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

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

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

6.Средства тестирования. Обеспечивают автоматизированную проверку программного обеспечения на соответствие требованиям и критериям качества.

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

Основными компонентами CASE-средств являются средства для поддержки ана-

лиза, проектирования и документирования.

9.3. Среда JUDE Community

JUDE – инструментальное средство моделирования программных систем японской компании Change Vision.

Название JUDE является аббревиатурой от Java and UML Developers Environment.

В1996 году, нынешний CEO (chief executive officer) компании Кенджи Хиранабе

пришѐл к выводу, что в недалѐком будущем будет востребована среда для объект- но-ориентированного проектирования. Он собрал несколько добровольцев, и они создали JOMT, впоследствии переименованный в JUDE.

В1999 году JUDE стал распространяться бесплатно. Однако в 2004 году проект был разделен на два: JUDE Community и JUDE Professional. Продукт JUDE Professional

обладает большей функциональностью по сравнению с бесплатной версией.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011