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

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

• Динамическое планирование – быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими.
• Частые выпуски – самая первая упрощенная версия быстро сдается заказчику, после чего через относительно короткие промежутки времени (неделя–две недели) происходит выпуск новых версий.
• Архитектурная метафора – простая и понятная заказчику концепция системы.
• Простое проектирование – в каждый момент времени система должна быть спроектирована просто, так как заказчик может изменить ее функциональность.
• Опережающее тестирование – для любой программы должны существовать автоматические тесты.
• Рефакторинг – постоянное улучшение качества кода с сохранением функциональности.
• Парное программирование – весь код пишется двумя программистами, работающими на одном компьютере.
• Коллективное владение кодом – любой разработчик может улучшать любой код системы в любое время.
• Непрерывная интеграция – как только код написан и протестирован, он интегрируется в общую систему.
• 40-часовая рабочая неделя – внеурочная работа способствует ухудшению психологического климата в команде.
• Доступный заказчик – в команде все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы.
• Стандарты кодирования – весь код должен быть написан в едином стиле.

 

10.     Жизненный цикл  программы. Выявление  и анализ требований. Архитектурное и  детальное проектирование 

Жизненный цикл программы – это совокупность и последовательность изменений формы программы за все время ее существования.

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

Существенные  моменты этой схемы:

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

Особенности жизненного цикла  программы:

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

Выявление и анализ требований

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

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

Стандарты IEEE используют следующее определение требований.

1. Функциональность, необходимая пользователю для  решения проблемы или достижения  цели.

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

компонентами  для соответствия контракту, стандарту, спецификации или другим формальным документам.

3. Документальное  представление пп. 1 – 2.

В соответствии со стандартом ГОСТ 12207 на стадии «Анализ требований» должен быть

выполнен анализ требований к программным средствам. Эта работа состоит из следующих  задач:

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

Схема разработки требований

Разработка  требований – это первая из основных фаз процесса создания программных систем.

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

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

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

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

Детализация требований. Разработчики детализируют требования пользователей,

формируя более  точные подробные системные требования.

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

Управление  требованиями

Управление  требованиями - все действия, направленные на поддержание

целостности, точности и актуальности спецификации требований в процессе разработки

программной системы.

К действиям  по управлению требованиями относятся:

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

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

Архитектурное и детальное проектирование

Существуют  такие типы проектов по разработке программного обеспечения, которые  не

нуждаются в  фазе проектирования: после того, как  требования определены, можно сразу

приступать  к реализации и кодированию. Это  возможно в двух случаях:

• чрезвычайно простой («учебный») проект
• имеется высоко квалифицированная команда разработчиков, которая прежде выполняла аналогичные проекты многократно.

В настоящее  время всю фазу проектирования обычно подразделяют на две части: архитектурное  проектирование и детальное проектирование.

Архитектурное проектирование

Архитектура программного обеспечения – это представление системы программного

обеспечения, дающее информацию о компонентах составляющих систему, о взаимосвязях

между этими  компонентами и правилах, регламентирующих эти взаимосвязи, которое

предназначено для эффективной разработки проекта  такой системы.

Шоу и Гарлан классифицировали архитектуры программного обеспечения с точки зрения практики (собрали вместе образцы ПО для  различных архитектур).

Детальное проектирование

Фаза детального проектирования обычно предусматривает  применение большого числа

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

 

11.      Жизненный цикл  программы. Реализация  и кодирование.  Тестирование и  верификация. Сопровождение  и продолжающаяся  разработка. 

Реализация  и кодирование

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

Цель  реализации - удовлетворение требований способом, определенным в детальном проектировании.

Инженерный  анализ программы - исследование и обработка текста программ с целью восстановления модели этой программы.

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

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

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

Стандарт  кодирования – сборник корпоративных или проектных правил и рекомендаций по составлению и оформлению текстов программ.

Тестирование  и верификация

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

Цель  тестирования: обнаружение как можно большего числа дефектов, как можно более серьезных и как можно раньше.

Процесс контроля качества: каждая часть работы, выполненная инженером, должна быть детально проверена по крайней мере одним человеком, желательно независимым от автора работы.