Роли участников процесса проектирования

При проектировании должны быть задействованы определенные люди, которые примут участие в анализе и разработке программного проекта. Участникам проекта принято назначать роли – функции, которые они будутвыполнять в проекте. В зависимости от квалификации и величиныпроектной команды один человек может совмещать различные роли(например, если программу пишет один разработчик, то он можетсовместить их все). Для осуществления процесса проектированиявыделяют следующие основные роли: заказчик; руководитель проекта; системный администратор; администратор базы данных; системный архитектор; архитектор базы данных; бизнес-аналитик, аналитик (системный аналитик); тестировщик.

Заказчиком является лицо, которому нужно разрабатываемое ПО.

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

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

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

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

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

Архитектор базы данных проектирует укрупненную структурубазы данных. Более детальная проработка архитектуры базы данныхпроизводится на этапе конструирования ПО.

Бизнес-аналитик описывает требуемое поведение системы сточки зрения конечных пользователей. Например, с точки зренияпользователя покупка выбранного товара будет заключаться в щелчке левой кнопкой мыши по кнопке «Купить» и заполнении данныхбанковской карты. С точки зрения разработчика данное действиебудет заключаться в получении события щелчка левой кнопкой мышипо кнопке «BTNBUY», вызове формы «FRMBUY», проверки заполненныхполей.

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

Тестировщик производит тестирование ПП. При проектированииего необходимо ознакомить с подготовленной документацией попрограммному продукту для подготовки к процессу тестирования.

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

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

3.Ключевые вопросы проектирования

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

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

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

Основной сложностью при проектировании параллельных программ является обеспечение правильной последовательности взаимодействий между различными вычислительными процессами, атакже координация ресурсов, разделяемых между процессами. Например, для интернет-магазина по продаже сотовых телефонов можно выделить следующие параллельные процессы: 1) формированиеи выдача страниц по запросам пользователей (обеспечивается науровне архитектуры Web-сервера); 2) выдача запросов базой данных(обеспечивается на уровне архитектуры базы данных). С другой стороны, ряд действий нельзя выполнять параллельно. Например, прирегистрации, когда резервируется уникальный код доступа к учетнойзаписи, нельзя одновременно давать регистрироваться двум пользователям, так как это может вызвать конфликт кодов. Функции обработки заказов также нельзя делать параллельно, так как товар наскладе может закончиться при обработке одного из заказов.

Асинхронные агенты. «Тяжелые» (продолжительные) задачи необходимо выделять в отдельные потоки, что позволяет разгрузитьпотоки, обрабатывающие сообщения от графического интерфейса иотделить прорисовку графической информации от вычислений, занимающих большой объем времени. К категории задач, которыенеобходимо выделять на обработку в отдельные потоки, можно отнести следующие: печать, лингвистические проверки, компиляцияи т. д.

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

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

Контроль и обработка событий. Событийно-ориентированнаяархитектура позволяет реализовать механизм работы приложенияне на основе прямого вызова методов классов, а на основе реагирования на те или иные события. Таким образом, можно уменьшитьсвязность в системе. Изначально событийность была присуща графическому интерфейсу, где вся работа основывалась на передачесообщений. Событийность возможна как асинхронное решение дляобмена информацией в многослойных приложениях (когда архитектура делится на несколько слоев), особенно это касается приложенийслои которых разделены по разным серверам, так как в этом случаепрямой вызов методов невозможен.

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

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

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

требования к скорости.

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

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