Ваш персональный интернет обозреватель

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

Под началом проектирования подразумевается рассмотрение технического задания (ТЗ), предоставляемого заказчиком и дальнейшее составление, на базе полученного задания, модели бизнес-логики приложения, структуры данных и их отображения. В основном, главными вопросами разбора ТЗ являются выборы моделей предметных областей, в которых будет работать запрошенных функционал. Данный вопрос о функциональных возможностях упирается, непосредственно, в требования к ПО. Они определяются внешними характеристиками программы, которые являются «видимыми» для конечного пользователя. К примеру, это структурированное отображение некоторых текстовых документов. Здесь для пользователя будут показаны лишь структуры каталогов документов, в то время как способ реализации данной возможности будет для него скрыт в исходном коде. Собственно, проектирование этого исходного кода и есть одна из задач архитектора ПО.

Если рассматривать структуру ТЗ подробнее, то можно выявить следующие ключевые пункты:

1. Функциональные назначения (либо область применения).
2. Функциональные требования к самой программе.
3. Необходимые требования к составу и параметрам внутренней среды, а так же их надёжность и безопасность.
4. Необходимые требования к совместимости.
5. Документация.

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

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

Под третьим пунктом подразумевается наличие определённых составляющих всего ПО и то, каким они должны удовлетворять нормам безопасности и надёжности. Пусть то, к примеру, метал или пластик, операционная система Linux или Windows, язык программирования Java или PHP. Ну и так далее.

Четвёртый пункт указывает на учёт необходимых совместимостей ПО с другими сферами работы. Данные параметры должны быть учтены при этапе проектирования и разработки.

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

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

После разбора ТЗ, происходит этап учёта анализа всех затрат на выполнение необходимых требований. Рассматриваются все подходящие инструменты и платформы для реализации пунктов из ТЗ. После принятия решения о том или ином выборе, даётся задание архитектору на планирование организации построения архитектуры всего исходного кода ПО. Здесь можно выделить понятие «чёрного ящика», которое подразумевает под собой анализ внешних характеристик программы, без вмешательства в её структуру. Далее начинается подробное рассмотрение внутренней начинки проектируемой системы с детализация всех её внешних свойств.

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

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

Запись опубликована 03.03.2010 в 9:22 пп и размещена в рубрике Кодинг. Вы можете следить за обсуждением этой записи с помощью ленты RSS 2.0. Можно оставить комментарий или сделать обратную ссылку с вашего сайта.