Лекция 8. Технология разработки программных комплексов для управления автоматическими и автоматизированными системами.

Проблемы разработки ПО

Какие проблемы сопровождают реальную разработку ПО:

1. ПО нужно много. Все большее количество людей вовлекается в процесс разработки.

Современный взгляд на эту проблему – повторное использование ранее разработанных программ и программных компонент, так как это делается в электронике. Все новые и новые изделия ЭТ создаются из имеющегося набора БИС. Конечно, это сопровождается развитием этих наборов.

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

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

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

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

3. Проблема надежности ПО.

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

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

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

4. Проблемы изменяемости ПО.

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

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

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

В настоящее время по американской статистике из-за неправильной технологии разработки ПО, низкого уровня планирования и организации работ – хаотического процесса разработки 15% всех программных продуктов так и не достигли своего завершения. А для оставшихся 85% превышение первоначально заявленной стоимости и сроков создания в 2-3 раза является обычным явлением.

Таким образом, разработка ПО требует трех знаний: знаний в предметной области, знаний в области программирования, знаний в области технологии разработки ПО.

 

Качество ПО и технология его производства. Влияние человеческого фактора

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

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

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

Рис. 8.1 - Факторы, влияющие на качество ПО

 

Технология разработки ПО включает в себя методы управления программным проектом, которые включают в себя методы и принципы:

-организации разработки,

-планирования разработки,

-контроля хода разработки,

-мотивации разработчиков ПО.

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

Человеческий фактор влияет на качество ПО двумя сторонами. Во первых людям свойственно ошибаться. Ошибки бывают двух видов:

ü Ошибки-промахи

ü Ошибки-заблуждения

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

Кроме деструктивного влияния человеческого фактора можно отметить и позитивные его стороны. Имеются три грани в квалификации разработчиков ПО:

Уровень знаний и опыт в предметной области,

Уровень знаний и опыт в области программирования.

Уровень знаний и опыт в технологии разработки ПО.

При этом приоритет отдается знаниям в предметной области. Конечно, без программирования в настоящее время ПО не создашь. Но программирование – всего лишь средство выражения идей предметной области.

 

Стандартизация характеристик качества ПО. Управление качеством ПО

Несмотря на огромное разнообразие программных продуктов, производимых в настоящее время и соответственно огромное количество критериев качества для них, удалось выделить некоторое количество базовых критериев качества ПО, которое легло в основу международного стандарта ИСО/МЭК 9126-92 «характеристики качества ПО».

Качество ПО в соответствии с этим стандартом оценивается шестью базовыми характеристиками:

-функциональные возможности,

-надежность,

-эффективность,

-практичность,

-сопровождаемость,

-мобильность или переносимость на другую аппаратную платформу или в другое программное окружение прежде всего ОС.

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

В итоге процесс управления качеством ПО состоит из 5 шагов:

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

2.Определение потребного уровня значений, выбранных критериев качества.

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

4.Обеспечение качества ПО как множества процедур и стандартов и их адаптация для конкретного случая разработки ПО.

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

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

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

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

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

 

Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода. Каскадная модель жизненного цикла ПО

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

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

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

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

В соответствии с международным стандартом ISO/IEC 12207 «информационные технологии – Процессы жизненного цикла ПО» процесс разработки ПО содержит следующие этапы жизненного цикла ПО:

1) анализ системных требований и области применения;

2) проектирование архитектуры системы;

3) анализ требований к ПО(спецификации, внешние интерфейсы,);

4) проектирование архитектуры ПО;

5) детальное проектирование каждой единицы ПО;

6) кодирование ПО (программирование)

7) тестирование единиц ПО;

8) интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9) квалификационные испытания ПО (комплексное тестирование);

10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11) квалификационные испытания системы;

12) установка ПО.

Таким образом, процесс разработки ПО имеет свое начало от системы, где это ПО будет использовано и завершается опять в системе.

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

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

 

Спиральная модель жизненного цикла ПО. «Тяжелые и облегченные» (быстрые) технологии разработки ПО

Рассмотренная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки возможно полно и точно сформулировать все требования к ПО.

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

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

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО.

На каждом витке спирали выполняется создание версии продукта, уточняются требования к ПО и планируются работы следующего витка. Спиральная модель ЖЦ ПО отражает объективно существующий процесс итеративной разработки ПО (рис. 8.2).

Считается, что спиральная схема ЖЦ ПО предназначена не столько для торопливых разработчиков, сколько для ПО, некачественные первые версии которого допустимы по функциональному назначению ПО.

Существует направление «Быстрых технологий» разработки ПО (Agile Software Development), дающее идеологическое обоснование взглядам, связанным с спиральной моделью ЖЦ. Эти технологии базируются на четырех идеях:

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

- работающее ПО важнее наличия документации на него,

- сотрудничество с заказчиком важнее формальных договоров,

- быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

 

проектирование

реализация

АО

КО

анализ

завершение версии 1

Определение требований

завершение версии 2

 

 

Рис. 8.2 - Схема спирального ЖЦ ПО

 

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

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

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

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

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

«Тяжелые и облегченные» технологии разработки ПО. Разработчики многих видов ПО считают каскадную модель жизненного цикла слишком регламентированной, слишком документированной и тяжелой и поэтому нерациональной. Существует направление «Быстрых технологий» (легких технологий) разработки ПО (Agile Software Development), дающее идеологическое обоснование этим взглядам. Эти технологии базируются на четырех идеях:

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

2. работающее ПО важнее наличия документации на него,

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

4. быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

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

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

Примером Agile технологий является «Экстремальное программирование» (ХР). Итерации в ХР очень короткие и состоят из четырех операций: кодирования, тестирования, выслушивание заказчика, проектирование. Принципы ХР – минимальность, простота, участие заказчика, короткий цикл, тесные взаимодействия разработчиков – они должны сидеть в одной комнате, ежедневных оперативных совещаний совместно с заказчиком представляются разумными и давно применяются не только в быстрых технологиях, но в ХР они доведены до экстремальных значений.

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

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

В больших коллективах разработчиков проблема управления – выходит на передний план.

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

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

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