Итерационная модель.

Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов (RUP, MSF, XP).

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

Разработка программного обеспечения может быть разделена на несколько разделов. Это:

1. Требования для программного обеспечения: извлечение, анализ, спецификация, и ратификация требований для программного обеспечения.

2. Проектирование программного обеспечения: проектирование программного обеспечения средствами Автоматизированной Разработки Программного Обеспечения (CASE) и стандарты использования для формата, такие как Унифицированный Язык Моделирования (UML).

3. Инженерия программного обеспечения: постройка программного обеспечения с помощью языков программирования.

4. Тестирование программного обеспечения: поиск и исправление ошибок в программе.

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

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

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

8. Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.

9. Инструменты разработки программного обеспечения, см. CASE: методика оценки сложности системы, выбора средств разработки и применения программной системы.

10. Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.

11. Локализация программного обеспечения, ветвь языковой промышленности.

Проектирование программного обеспечения. Автоматизация проектирования программных продуктов.

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

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

Модель предметной области накладывает ограничения на бизнес-логику и структуры данных.

Требования к ПО определяют внешние (видимые) свойства программы, рассматриваемой как чёрный ящик.

Определению внутренних свойств системы и детализации её внешних свойств собственно и посвящено проектирование.

Проектирование ПО является частным случаем Проектирования продуктов и Проектирования систем.

В зависимости от класса создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации — блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат:

- Архитектура ПО

- Устройство компонентов ПО

- Пользовательские интерфейсы

В российской практике результат проектирования представляется в виде комплекса документов под названием «Эскизный проект», «Технический проект», в зарубежной — Software Architecture Document, Software Design Document.

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

Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» {divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых

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

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

1. количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» —Low Coupling);

2. связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления » - High Cohesion).

Более подробно эти принципы будут рассмотрены в рамках объектно-ориентированного анализа.

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

1. каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

2. каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

Инкапсуляция (принцип «черного ящика») позволяет рассматривать структуру каждой подсистемы независимо от других подсистем.

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

Существуют два основных подхода к декомпозиции систем.

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

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

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

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

1. неадекватная спецификация требований;

2. неспособность обнаруживать ошибки в проектных решениях;

3. низкое качество документации, снижающее эксплуатационные

характеристики;

4. затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

2. широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

Computer-Aided System Engineering (CASE)

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

CASE-технология поддерживает коллективную работу над проектом за счет:

- использования возможностей локальной сети;

- экспорта/импорта любых фрагментов проекта;

- организованного управления проектами.

Activity diagram

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

- либо через потоки управления (явно);

- либо через определяемые потоки данных (неявно).

Class diagram

Диаграмма классов - методология объектно-ориентированного проектирования, предназначенная для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

Component diagram

Диаграмма компонентов - метод объектно-ориентированного проектирования, описывающий особенности физического представления системы.

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

Collaboration diagrams

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

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

Sequence diagram

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

Data flow diagram (DFD)

Диаграмма потоков данных - информационная модель, основными компонентами которой являются:

- внешние сущности, представляющее собой источник или приемник информации;

- процессы преобразования входных данных в выходные в соответствии с определенным алгоритмом;

- накопители данных, в которые можно помещать и извлекать информацию;

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

Deployment diagram

Диаграмма развертывания - метод объектно-ориентированного проектирования, отображающий физические взаимосвязи между программными и аппаратными компонентами системы.

Statechart diagram

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

Диаграмма состояний состоит

- из множества состояний объектов;

- из множества событий, сообщающих о перемещении чего-либо в новое состояние;

- из множества правил переходов, определяющих новое состояние объекта при возникновении тех или иных событий;

- из множества действий, которые должны быть выполнены объектом, когда он переходит в новое состояние.

Entity-relation diagram (ERD)

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

Structured analysis and design technique (SADT)

Диаграмма функционального моделирования - инструмент разработки функциональных спецификаций в виде диаграмм, фрагментов текста и глоссария, связанных перекрестными ссылками. В состав диаграммы входят:

- блоки, изображающие активность моделируемой системы; и

- дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между ними.

Место соединения дуги с блоком определяет тип интерфейса:

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

- входная информация, подвергающаяся обработке, показывается с левой стороны блока;

- выходная информация показывается с правой стороны;

- механизм, осуществляющий операцию, представляется дугой, входящей в блок снизу.

Class-responsibility-collaboration

Карты класс-ответственность-кооперация - методология объектно-ориентированного проектирования, предназначенная для описания классов и оперирующая понятиями:

- ответственность - суть - высокоуровневое описание функций, которые выполняет класс;

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

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

Unified Modeling Language (UML)

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

Основными составляющими языка UML являются элементы, связи, механизмы расширения и диаграммы.

Тестирование и отладка ПС. Структурное и функциональное тестирования ПС. Организация процесса тестирования.

Тестирование - процесс выполнения программы с целью обнаружения ошибок.

Шаги процесса задаются тестами (тестовыми вариантами). Каждый тест определяет:

• свой набор исходных данных и условий для запуска программы;

• набор ожидаемых результатов работы программы.

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

• Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки.

• Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Важны ответы на вопросы:

• Что может тестирование? Тестирование обеспечивает:

  • обнаружение ошибок;

  • демонстрацию соответствия функций программы ее назначению;

  • демонстрацию реализации требований к характеристикам программы;

  • отображение надежности как индикатора качества программы.

• Чего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов)*.

• *Важно помнить это при проведении тестирования.

Информационные потоки процесса тестирования.

На входе процесса тестирования три потока:

• текст программы;

• исходные данные для запуска программы;

• ожидаемые результаты.

Выполняются тесты, все полученные результаты оцениваются. Это значит, что реальные результаты тестов сравниваются с ожидаемыми результатами.

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

После сбора и оценивания результатов тестирования начинается анализ качества и надежности ПО.

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

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

• качество и надежность ПО удовлетворительны;

• тесты не способны обнаруживать серьезные ошибки.

В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

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

Существуют 2 принципа тестирования программы:

• функциональное тестирование (тестирование «черного ящика»);

• структурное тестирование (тестирование «белого ящика»).