Практический подход к проектированию компьютерных систем

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

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

На прошлой неделе наш бизнес - аналитик отправился за границу, чтобы встретить нового клиента, который выбрал нас для разработки его системы управления контентом. Официальный документ с требованиями был отправлен заказчику для первоначального одобрения, где он был возвращен с небольшими изменениями. Запрошенные незначительные корректировки были внесены самим бизнес - аналитиком, чтобы получить окончательное одобрение со стороны клиента. Это было хорошее усилие; мы получили фиксированный набор требований через три недели после нашей первой встречи с клиентом. Бизнес - аналитик отправил бизнес - модель системному архитектору. Вскоре документ о нефункциональных требованиях был закончен и утвержден заказчиком без изменений. В качестве следующего непосредственного процесса были определены варианты использования. Системный архитектор завершил проектирование системы вместе с системным аналитиком. Администратор базы данных затем идентифицирует / определяет сущности и их отношения вместе с DDL (Data Definition Language) для системы. Разработчик пользовательского интерфейса (UI) разработал пользовательский интерфейс системы, чтобы завершить начальную разработку. Наконец, модель развертывания была определена, и мы начали стабильно внедрять систему, получив все необходимые разрешения от заказчика.

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

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

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

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

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

В качестве первого шага, дизайнер должен быть мастером проблемной области. Хорошо написанный документ спецификации системных требований (SRS) может быть использован в качестве введения в систему. Разработчик системы должен читать его повторно и тщательно понимать каждую важную функцию, скрытую в нечетных углах документа. Но в большинстве случаев разработчик не получает надлежащего SRS до проектирования системы. (По крайней мере, так обстоит дело с сервисными компаниями.) Вместо этого он вынужден захватывать требования посредством первоначальных деловых встреч и телефонных конференций. Это прискорбное обстоятельство - идеальный случай для дизайнера подумать о выброшенном прототипе или даже двух. Прототип - это лучший и самый дешевый способ определения спецификации продукта, прежде чем отправиться на неизвестную территорию. В случае несогласия с прототипированной системой, разработчик должен стратегически побудить клиента написать спецификацию для него. Традиционный совет - подождать, пока вы не доберетесь до глубины системы, прежде чем начинать проектирование. Но на практике вы можете ускорить работу, обращаясь к онлайн - ресурсам, таким как статьи, проекты с открытым исходным кодом и другие подобные продукты, не в значительной степени завися от документа SRS (примечание: новичкам всегда нужна помощь старших для правильной идентификации пулов ресурсов, поскольку сложные технические требования едва видны новыми техническими глазами). Знания в области, которые вы получите, не только гарантируют хороший дизайн, но также помогут лучше прогнозировать будущее системы и сохранить достаточное пространство для последующих расширений. В дополнение к этому новички должны быть внимательны, чтобы не недооценивать важные бизнес - требования, оценивая их только с технической точки зрения. Это еще одна важная область, где клиент может быть очень жестким и даже принять решение отказаться от системы, жалуясь, что поставщик решения поставил неправильный продукт.

Чтобы оптимизировать пропускную способность, начните пересматривать систему свежим взглядом, забывая всю информацию, которую вы собрали с помощью различных ресурсов. Этот подход поможет вам понять определения продукта, даже если спецификация продукта не очень ясна. Практикуя эту технику, вы будете удивлены, увидев, как она открывает новые области системы. Как вы, возможно, уже знаете, в соответствии с этим методом, интересно, что спрашивающий должен быть ответчиком, и это должен быть вы. Иногда вы не сможете ответить на конкретный вопрос. Но, по крайней мере, у вас будет список вопросов, на которые можно найти ответы. Я видел, как дизайнеры боролись, когда им бросали проект с широко (слабо) определенными требованиями. Они не знают, с чего начать и что спрашивать или не спрашивать. Если вы столкнулись с той же проблемой, попробуйте эту технику и посмотрите, работает ли она.

1. Советы по проектированию компьютерной системы - Батлер В. Лэмпсон

2. Отчет о состоянии дел: методы проектирования программного обеспечения - Роберт Л. Вьено и Рой Сенн

3. HIPO и разработка интегрированной программы - J. F. Stay

© ЭРГАШЕВ Э.М.