Существует основных способа проектирования программных систем

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

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

За 13 лет опыта компании «Эдисон» в аутсорс-разработке для средних и крупных компаний из России, США, Европы и Австралии мы выработали собственную схему проектирования ПО, о которой в этом посте и расскажем.

Зачем нужно проектирование программного обеспечения

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

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

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

Подготовительный этап

В зависимости от особенностей проекта порядок разработки программного обеспечения может отличаться, но в общем виде он такой:

При подготовке к проектированию решаются организационные вопросы:

• что клиент может предоставить (ТЗ, макеты, дизайн), насколько достаточны исходники и какие этапы закрывают — таким образом определяется состав работ,
• бюджет и сроки: на основе имеющихся материалов утверждается примерная стоимость, срок всего проекта, а также срок и точная стоимость ближайшего этапа.

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

Этапы и результаты проектирования

1. Описание: совместная работа заказчика (говорит о пользе продукта, требованиях к работоспособности и внешнему виду) и EDISON (предлагает технические и алгоритмические решения).
2. Архитектура: утверждается язык программирования, база данных, серверы и фреймворки.
3. Техническое задание: составляется архитектором на основании описания и ответов заказчика на вопросы, согласовывается с менеджером проекта, затем передается клиенту, производятся правки.
4. Макеты (добавляются к техзаданию): интерфейсов, принципиальные схемы устройства, диаграммы структуры базы данных, схемы взаимодействия компонентов.
5. Контроль: архитектор устраняет замечания менеджера проектов.
6. Утверждение: заказчик проверяет и меняет ТЗ самостоятельно или сообщает список правок проект-менеджеру, замечания устраняются, ТЗ утверждается и прилагается к контракту.

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

1. Что делаем (описание продукта, функционала, пользователей)?
2. Как делаем (архитектура)?
3. Как проверить, что цель достигнута (тестирование, критерии оценки)?

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

Требования к техническому заданию на разработку программного обеспечения

Минимально достаточное ТЗ должно:

• полностью, чётко (инструкционно, без воды, возможности разночтения) и структурировано описывать будущий программный продукт (как должен выглядеть, как и с чем работать, каким требованиям отвечать) и процесс его разработки, чтобы у архитектора не возникало вопросов по реализации,
• исключать противоречивые сведения,
• быть юридически точным (следовать ГОСТ 34.602-89), поскольку вместе с контрактом и прочими документами ТЗ приобретает юридическую силу.

Техническое задание должно содержать:

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

В составе ТЗ необходимо уделить внимание описанию:

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

Примеры техзаданий на разработку ПО

Естественно, чем сложнее проект, тем дольше и дороже подготовка к нему. Проектирование небольших проектов занимает от недели до месяца. Чтобы процесс шёл быстрее и стоил меньше, мы предоставляем заказчикам по запросу инструкцию по составлению ТЗ и примеры готовых технических заданий. Приведем примеры и тут.

ТЗ на программное обеспечение Protector

Объект ТЗ: разработка и интеграция с существующей системой модульного ПО для мониторинга удаленных устройств охраны
Заказчик: ООО «ВТИМБ»

Сценарии использования образовательной системы

Объект ТЗ: создание образовательной системы

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

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

Проектирование — для больших парней

За годы работы нами написаны сотни техзаданий на разработку программного обеспечения различной степени сложности, и мы понимаем, что роль разработки подробного ТЗ сложно переоценить. Бывало, работали с ТЗ на более чем 1000 страниц, и для крупных проектов — это оправдано и необходимо. Тем не менее не стоит забывать о принципе целесообразности — нет смысла писать ТЗ на 20 страниц для двухдневной разработки продукта.

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

Источник

МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ

В последние годы наибольшее развитие и использование получил объектно–ориентированный, компонентный, сервисно–ориентированный подходы. Для их поддержки Были разработаны и инструментальные средства (Rational Rose, Rational Software, RUP, Demral , OОram и др.). Инструменты рассматриваются в теме 10.

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

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

Методы систематического программирования

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

– моделирование в UML,

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

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

Структурный подход

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

В основу структурного подхода положены такие общие принципы:

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

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

В основе этих принципов лежат операции:

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

– формализации, т.е строгое методологическое решение проблемы;

– непротиворечивости, состоящей в обосновании и согласовании элементов системы;

– структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:

SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы [1];

SSADM (Structured Systems Analysis and Design Method) – метод структурного анализа и проектирования [2];

IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 – информационной модели, IDEF2 ­ – динамической модели и др. [3].

На стадии проектирования эти модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Метод функционального моделирования SADT. На основе метода SADT, предложенного Д. Россом, разработана методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этого метода основываются на следующих концепциях:

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

– строгость и точность. Правила SADT строги и имеют ограничения на количество блоков на каждом уровне декомпозиции (от 3 до 6 блоков) и связность диаграмм через номера блоков;

– уникальность меток и наименований;

– разделение входов и управлений ( определение роли данных).

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

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

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), осуществляющий операцию, представляется дугой, входящей в блок снизу (рис.5.1).

Рис. 5.1. Структура модели

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

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

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

– моделирование взаимосвязей событий и сущностей;

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

– логическое проектирование БД;

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

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

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

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

– спецификацию функций и схемы реализации компонентов функций,

– описание процедурных и непроцедурных компонентов и интерфейсов,

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

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

Проект системы представляется структурной моделью, задающей работы и взаимосвязи между этими работами в виде потоков проектных документов, отображенных в сетевом графике, а также модули, стадии и шаги проектирования, которые соответствуют ЖЦ.

Источник