Этапы разработки программы: от идеи до реализации

Системное проектирование

Архитектура оказывает влияние на структуру коллектива

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

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

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

Структура процесса проектирования

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

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

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

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

· микроуровень, на котором проектируют отдельные детали и элементы машин и приборов.

Стадии проектирования — наиболее крупные части проектирования как процесса, развивающегося во времени. В общем случае выделяют стадии научно — исследовательских работ (НИР), эскизного проекта или опытно-конструкторских работ, технического, рабочего проектов, испытаний опытных образцов или опытных партий. Стадию НИР иногда называют предпроектными исследованиями или стадией технического предложения. Очевидно, что по мере перехода от стадии к стадии степень подробности и тщательность проработки проекта возрастают, и рабочий проект должен быть вполне достаточным для изготовления опытных или серийных образцов. Близким к определению стадий, но менее четко определенным понятием является понятие этапа проектирования.

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

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

«V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели

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

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

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

Когда использовать V-модель?

  • Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
  • Для малых и средних проектов, где требования четко определены и фиксированы.
  • В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

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

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

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

1. Стратегия «снизу вверх»

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

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

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

2. Нисходящая стратегия

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

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

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

Метод «сверху вниз» типичен для очень высокого качества, поскольку процесс проектирования продолжает определять подсистемы и компоненты по мере их соответствия системе, в результате чего получается высокоэффективная, отзывчивая и действенная система.

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

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

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

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