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

Каскадная и спиральная модели жизненного цикла ПО. Преимущества, недостатки, применимость.

Каскадная модель (водопад - waterfall) включает выполнение следующих фаз:

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

• определение требований — определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы.

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

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

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

• сопровождение — устранение программных ошибок, неисправностей, сбоев, модернизация и внесение изменений. Состоит из итераций разработки.

Основными принципами каскадной модели являются:

•Строго последовательное выполнение фаз:

•Каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы

•Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.

•Каждая фаза полностью документируется

•Переход от одной фазы к другой осуществляется посредством формального обзора с участием заказчика

•Основа модели – сформулированные требования (ТЗ), которые меняться не должны

•Критерий качества результата – соответствие продукта установленным требованиям.

Каскадная модель имеет следующие преимущества:

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

•Проста и удобна в применении:

- процесс разработки выполняется поэтапно.

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

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

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

•Позволяет достаточно точно планировать сроки и затраты

При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:

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

•Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;

•Запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат

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

•Требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи типа:

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

- операционные системы и компиляторы

- системы реального времени управления конкретными объектами

Кроме того, каскадная модель применима в условиях:

•Повторная разработка типового продукта (автоматизированного бухгалтерского учета, начисления зарплаты, …)

•Выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (перенос уже существующего продукта на новую платформу)

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

Спиральная модель. Принципы

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

1.Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования.

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

Циклический характер разработки ПО отражен в спиральной модели ЖЦ, описанной Б. Боэмом в 1988 году (Barry Boehm, " A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No.5, pp. 61-72, 1988. www.computer.org/computer/homepage/misc/Boehm/r5061.pdf). Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки ПО. Основные принципы спиральной модели можно сформулировать следующим образом:

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

○ Создание прототипов ПО как средства общения с заказчиком для уточнения и выявления требований

○ Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту

○ Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок.

○ Использование каскадной модели как схемы разработки очередного варианта

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

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

○ определение целей, альтернативных вариантов и ограничений.

○ оценка альтернативных вариантов, идентификация и разрешение рисков.

○ разработка продукта следующего уровня.

○ планирование следующей фазы.

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

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

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

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

Отметим некоторые особенности спиральной модели:

a До начала разработки ПО есть несколько полных циклов анализа требований и проектирования.

b Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи

c В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.

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

-Более тщательное проектирование

-Поэтапное уточнение требований

-Участие заказчика в выполнении проекта с использованием прототипов программы.

-Планирование и управление рисками

-Возможность разработки ПО «по частям»

Недостатки – сложность:

-Анализа и оценки рисков при выборе вариантов.

-Поддержания версий продукта

-Оценки точки перехода на следующий цикл

-Бесконечность модели

Применимость:

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

-Достижение успеха не гарантировано и необходима оценка рисков продолжения проекта

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

-Применение новы х технологий

-Выполнение очень больших проектов по частям

Характеристики проекта

–Конкретная цель проекта

–Уникальность

–Ограниченность во времени

–Ограниченность ресурсов (финансовых, людских, материальных)

–Сложность

–Неопределенность

–Предсказуемость

Проект:

–То, чем сложно управлять - неопределенность

–Предсказуемый проект:

1 Во время завершенный (успешно)

2 Во время прекращенный (неуспешно)

Управление проектом (Project Management - PM) – это наука и искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта путем применения современных методов и техники управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта (PMBOK, PMI)

Основные принципы:

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

–Навыки – опыт в области управления – применение умения для достижения целей в конкретных условиях

Административная модель

Теория X: Люди делают только то, что вы контролируете

Характерные черты модели:

–Властная пирамида – решения принимаются сверху-вниз

–Четкое распределение ролей, обязанностей и ответственности

–Следование инструкциям, процедурам, технологиям

–Роль менеджера: планирование, контроль, принятие основных решений.

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

–Ясность, простота, прогнозируемость

–Сочетание с каскадной моделью жизненного цикла

–Эффективна в случае установившегося процесса.

Недостатки модели:

–невосприимчивость к изменению ситуации

–плохо уживаются индивидуалисты и генераторы идей

Административная модель - тяжелый паровоз «промышленного программирования»

Модель хаоса

Теория Y: работа — естественная и приятная деятельность и люди не увиливают от работы

Характерные черты модели:

–Отсутствие явно выраженных признаков власти

–Роль менеджера – поставить задачу, обеспечить ресурсами и не мешать

–Отсутствие инструкций и регламентированных процедур

–Индивидуальная инициатива - решения принимается там, где проблема обнаружена

–Творческая игра участников на основе дружеской соревновательности

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

–творческая инициатива участников ничем не связана

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

Недостаток - переход в команду провала:

–Конкуренция сначала идей, а потом - личностей

–Процесс преобладает над целью проекта

–Генераторы идей редко обладают терпением для их реализации

Дополняет и соседствует с административной моделью

Открытая архитектура

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

Работаем спокойно. Работаем вместе

Особенности модели:

–Адаптация к условиям работы – если надо – работаем по отдельности, если надо – работаем вместе

–Коллективное обсуждение проблем, выработка консенсуса и принятие решения

–Распределенная ответственность

Еще особенности модели:

–Динамика состава рабочих групп в зависимости от задач.

–Частая смена ролей и функций участников

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

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

–Гибкость, адаптируемость, настраиваемость на ситуацию

–Проявить себя могут все участники (и индивидуалисты и коллективисты)

–Коллективное обсуждение идей - только прагматичные идеи

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

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

Программная инженерия – это:

1 установление и использование обоснованных инженерных принципов (методов) для экономного получения ПО, которое надежно и работает на реальных машинах. [Bauer 1972].

2 та форма инженерии, которая применяет принципы информатики (computer science) и математики для рентабельного решения проблем ПО. [CMU/SEI-90-TR-003]

3 применение систематического, дисциплинированного, измеряемого подхода к разработке, использованию и сопровождению ПО [IEEE 1990].

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

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

Инженерная дисциплина:

–Ориентация на практический результат

–Применение теорий, методов и способов для достижения результата

–Лучшие практики (best practices)

–При ограниченном ресурсе времени, бюджета, оборудования, людей

Все аспекты производства ПО:

–Управление программными проектами

–Разработка средств, методов и теорий

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

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

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

Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов:

○ Почему доля провальных проектов в программной инженерии так велика по сравнению с другими инженериями?

○ Можно ли в программной инженерии применять опыт других инженерий?

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

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

Компьютерная программа – это (в отличие от объектов других инженерий) не материальный объект (просьба не путать с носителем программы – устройством памяти любого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копировании образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком)

Отсюда следуют следующие выводы:

○ Стоимость программы – это стоимость только ее проектирования

○ Стоимость проектирования коробочных продуктов «размазывается» по копиям

○ Стоимость заказных продуктов (массово не копируемых) остается высокой

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

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

Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207). Взгляд на ПО как только на программу, сидящую в компьютере слишком узок. Дело в том, что продается (поставляется) не только программа, но еще и документация, в которой можно прочитать как установить программу и как ей пользоваться и данные для установки программы в различных условиях (конфигурационные файлы). Поэтому ПО иногда называют программным продуктом. Т.е. программный продукт (программное обеспечение) – это не только программы, а также вся связанная с ними документация и конфигурационные данные, необходимые для корректной работы программы. А специалисты по программному обеспечению разрабатывают программные продукты, т.е. такое ПО, которое может быть продано потребителю.

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

○ коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО)

○ заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик и при этом рискует, что разработчик не сможет реально выполнить все требования в срок и при выделенном бюджете.

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

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

○ Наследование ранее созданного ПО (legacy systems). Существует достаточно много систем, созданных много лет назад, морально устаревших, но продолжающих работать. Проблема наследования таких систем состоит в их сопровождении – поддержке и развитии.

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

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

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

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

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

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

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

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

○ Злоупотребление компьютером – программный специалист не должны злоупотреблять компьютерными ресурсами работодателя или заказчика; под злоупотреблениями мы здесь понимаем широкий спектр — от игр в компьютерные игрушки на рабочем месте до распространения вирусов и т.п.

12 3 4 Следующая ⇒