Файл: Особенности технологии разработки ПО.pdf

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

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

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

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

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

CASE-технологию создания ПО. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.

CASE-технология представляет собой совокупность методов проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. [2]

2.2 Методы анализа и проектирования ПО

Структурные методы являются строгой дисциплиной системного анализа и проектирования. Методы структурного анализа и проектирования1 стремятся преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков». Выгода в использовании «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают, необходимо знать лишь их входы и выходы, а также назначение (т.е. функции, которые они выполняет). [9]

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

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

• каждый «черный ящик» должен реализовывать единственную функцию

системы;

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

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

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

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

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

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

1. функциональную структуру системы;
2. последовательность выполняемых действий;
3. передачу информации между функциональными процессами;
4. отношения между данными. [10]

Наиболее распространенными моделями первых трех групп являются:

• функциональная модель SADT (Structured Analysis and Design Technique);
• модель IDEF3;
• DFD (Data Flow Diagrams) — диаграммы потоков данных. Модель «сущность — связь» (ERM — Entity-Relationship Model), описывающая отношения между данными, традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. [2]

В этом разделе были рассмотрены общие вопросы проектирования систем. Жизненный цикл ПО и непосредственно сами этапы будут изучены в следующем разделе.

3. Этапы создания программных продуктов

3.1 Этапы создания

Модели жизненного цикла программного обеспечения описывают фазы программного цикла и порядок их выполнения. Каждый этап дает результаты, необходимые для следующего этапа жизненного цикла. Требования переведены в дизайн. Код создается в соответствии с дизайном, который называется фазой разработки. После кодирования и разработки тестирование проверяет соответствие этапа реализации требованиям. Команда тестирования следует жизненному циклу тестирования программного обеспечения (STLC), который подобен циклу разработки, который следует за командой разработчиков. [9, 10]

В каждой модели жизненного цикла разработки ПО есть шесть следующих этапов:

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

1. Сбор и анализ требований: бизнес-требования собираются на этом этапе. Этот этап является основным направлением работы руководителей проектов и заинтересованных сторон. Встречи с менеджерами, заинтересованными сторонами и пользователями проводятся с целью определения таких требований.

1. Кто будет использовать систему?
2. Как они будут использовать систему?
3. Какие данные должны быть введены в систему?
4. Какие данные должны выводиться системой?

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

Наконец, создается документ спецификации требований, который служит целью руководства для следующего этапа модели. Команда тестирования следует жизненному циклу тестирования программного обеспечения и начинает этап планирования тестирования после завершения анализа требований. [8, 9]

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

На этом этапе тестеры придумывают стратегию тестирования, в которой упоминается, что тестировать, как тестировать.

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

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

5. Развертывание: после успешного тестирования продукт доставляется/развертывается заказчику для его использования.

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

6. Техническое обслуживание. Когда клиенты начинают использовать разработанную систему, возникают реальные проблемы, которые время от времени требуют решения. Этот процесс, где заботятся о разработанном продукте, известен как техническое обслуживание. [11]

3.2 Жизненный цикл программного продукта

Модель водопада — это линейный последовательный поток. В которых прогресс рассматривается как непрерывно нисходящий (как водопад) через фазы реализации программного обеспечения. Это означает, что любая фаза в процессе разработки начинается, только если предыдущая фаза завершена. Водопадный подход не определяет процесс возврата к предыдущему этапу для обработки изменений в требованиях. Водопадный подход — самый ранний и наиболее широко известный подход, который использовался для разработки программного обеспечения. [2, 5, 9]

Преимущества:

1. Легко объяснить пользователям.
2. Структурный подход.
3. Этапы и мероприятия четко определены.
4. Помогает планировать и планировать проект.
5. Проверка на каждом этапе обеспечивает раннее обнаружение ошибок и недоразумений.
6. Каждый этап имеет конкретные результаты.