практическая. 2 Технология разработки программного обеспечения. Основные определения 1 Особенности создания программного продукта
 Скачать 266.23 Kb.
|
|
2 Технология разработки программного обеспечения. Основные определения 2.1 Особенности создания программного продукта Принципы работы с требованиями к программному обеспечению. Проблематика проектирования Согласно статистическим исследованиям группы Стендиша (Standish Group), в США ежегодно тратится более 250 млрд долларов на разработку приложений информационных технологий в рамках примерно 175 000 проектов. Причем 31 % проектов будет прекращен до завершения. Затраты на 52,7 % проектов составят 189 % от первоначальной оценки. В таком случае американские компании и правительственные учреждения потратят 81 млрд долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 млрд долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время [11]. Первым шагом на пути решения любой проблемы является осознание основных причин се возникновения. В отчете группы Стендиша указано три наиболее часто встречающихся ключевых фактора, создающих проблемы при проектировании программного обеспечения: недостаток исходной информации от клиента — 13 % всех проектов; неполные требования и спецификации — 12 % проектов; изменение требований и спецификаций — 12 % всех проектов. В остальном данные сильно расходятся. Конечно, проект может потерпеть неудачу из-за нереалистично составленного графика или неправильно распределенного времени (4 % проектов), нерационального подбора персонала и выделения ресурсов (6 %), несоответствия технологических навыков (7 %), а также по другим причинам. Тем не менее, если считать, что приведенные цифры представляют реальное положение дел в отрасли, то, по крайней мере, неудачи третьей части проектов объясняются причинами, непосредственно связанными со сбором и документированием требований, а также с управлением ими. Несмотря на то что большинство проектов действительно превышает отведенное время и бюджет, оказалось, что около 9 % проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успеха удалось достигнуть в 16 % проектов мелких компаний. Возникает очевидный вопрос: «Каковы главные "факторы успеха" в этих проектах?» Согласно проведенному исследованию тремя наиболее важными факторами были следующие: подключение к разработке пользователя —16% всех успешных проектов; поддержка со стороны исполнительного руководства — 14 % всех успешных проектов; четкая постановка требований — 12 % всех успешных проектов. Двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались: спецификации требований; управление требованиями клиента. Оценка стоимости ошибок Некоторое время назад ряд компаний провел исследование оценки стоимости ошибок, возникающих на разных этапах создания программ. Каждая фирма действовала независимо, тем не менее результаты получены примерно одинаковые: если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5—10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения — в 20 раз больше (рисунок 2.1).  Рисунок 2.1 – Оценка стоимости ошибок на разных этапах создания ПО Откуда берется такая высокая стоимость ошибки? Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть. Истинная природа ошибки может быть замаскирована; при проведении тестирования и проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и значительное время и усилия могут быть потрачены впустую. В зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может разниться в 50—100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) нижеперечисленные действия. 1. Повторная спецификация. 2. Повторное проектирование. 3. Повторное кодирование. 4. Повторное тестирование. 5. Замена заказа — сообщить клиентам и операторам о необходимости заменить дефектную версию исправленной. 6. Внесение исправлений — выявить и устранить все неточности, вызванные неправильным функционированием ошибочно специфицированной системы, что может потребовать выплаты определенных сумм возмущенным клиентам, повторного выполнения определенных вычислительных задач на ЭВМ и т. п. 7. Списание той части работы (кода, части проектов и т. п.), которая выполнялась с наилучшими побуждениями, но оказалась ненужной, когда обнаружилось, что все это создавалось на основе неверных требований. 8. Отозвание дефектных версий встроенного программного обеспечения и соответствующих руководств. Если принять во внимание, что программное обеспечение сегодня встраивается в различные изделия — от наручных часов и микроволновых печей до автомобилей, — такая замена может коснуться как этих изделий, так и встроенного в них программного обеспечения. 9. Выплаты по гарантийным обязательствам. 10. Ответственность за изделие, если клиент через суд требует возмещение убытка, причиненного некачественным программным продуктом. 11. Затраты на обслуживание представитель компании должен посетить клиента, чтобы установить новую версию программного обеспечения. 12. Создание документации. 2.2 Управление требованиями Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. Поэтому имеет смысл узнать, что собой представляют требования, записать их, упорядочить и отслеживать их изменения. Определение управления требованиями выглядит следующим образом [3]. Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Учитывая, что системе будут предъявлены сотни, если не тысячи требований, то очень важно организовать их. Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Кроме того, очень важными факторами являются размер проекта и его сложность. Управление требованиями наиболее важно в больших проектах, в которых участвует множество людей и число требований к проекту велико. Допустим, таких требований 1000. Тогда придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих требований. Последовательность работы с требованиями. Анализ проблемы У пользователя есть технические или бизнес-задачи, для решения которых им нужны программисты. Задача последних состоит в том, чтобы понять проблемы пользователей в их собственной проблемной плоскости и на их языке и построить системы, удовлетворяющие их требованиям. Для понимания проблемы пользователей существует ряд профессиональных приемов, о которых пойдет речь ниже [3|. Программисты должны понять потребности пользователей и других заинтересованных лиц, на чью жизнь повлияет создание программы. Следующим шагом осуществляется переход в область решения — непосредственно к программированию. Однако для начала будет полезно сформулировать знания о предметной области. На данном этапе составляется список функций, которые должна реализовывать система. Для того чтобы провести анализ, полезно определить, что же собственно представляет собой проблема. По определению Гаусса и Вайнберга [И], проблема — это разница между желаемым и воспринимаемым. Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Как всегда, начинать следует с определения цели. Цель анализа состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов. Достигнуть соглашения об определении проблемы. Выделить основные причины — вопросы, стоящие за проблемой. Выявить заинтересованных лиц и пользователей. Определить границу системы решения. Выявить ограничения, которые необходимо наложить на решение. Этап 1. Достижение соглашения об определении проблемы. Первый шаг состоит в достижении соглашения об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой. В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая эти преимущества с точки зрения клиента, программисты также достигают лучшего понимания их взгляда на проблему в целом. Часто бывает полезно записать проблему в стандартной форме (таблица 2.1). Создание подобной таблицы является простым, но действенным средством, чтобы удостовериться в том, что все участники проекта работают вместе над осуществлением общей цели. Таблица 2.1- Структурирование проблемы
Этап 2. Выявление основных причин — вопросов, стоящих за проблемой. На данном этапе важно понять корневые причины, лежащие в основе проблемы, и ее проявления. Например, электронный магазин решил бороться с проблемой недостаточной прибыльности. Для этого был проведен анализ причин плохих продаж. Получено, что следующие причины ведут к слишком большим остаткам продукции на складе: устаревшие готовые изделия; неправильные заказы на покупку; повреждения при доставке; производственные дефекты; возвраты клиентами; прочее. Однако нужно ли устранять все эти причины? Зачастую нет. Некоторые корневые причины просто не стоят того, чтобы их устранять. Нужно определить влияние каждой корневой причины и устранять только тс, которые наиболее серьезно влияют на саму проблему. В примере, допустим, наибольшее влияние оказывает корневая причина «Неправильные заказы на покупку». Этап 3. Выявление заинтересованных лиц и пользователей. В этом процессе могут помочь ответы на следующие вопросы: Кто является пользователем системы? Кто является заказчиком (экономическим покупателем) системы? На кого еще окажут влияние результаты работы системы? Кто будет оценивать и принимать систему, когда она будет представлена и развернута? Существуют ли другие внешние или внутренние пользователи системы, чьи потребности следует учесть? Кто будет заниматься сопровождением новой системы? Не забыли ли мы кого-нибудь? Этап 4. Определение границ системы. Мир делится на две части (рисунок 2.2): создаваемая система; то, что взаимодействует с системой, — фактор.  Рисунок 2.2 – Границы системы Очень важно правильно определить факторы. Для этого следует ответить на приводимые ниже вопросы. Кто будет управлять системой? Кто будет осуществлять сопровождение системы? Откуда система получает информацию? Какие внешние системы будут взаимодействовать с системой? Этап 5. Выявление ограничений, налагаемых на решение. Ограничения уменьшают степень свободы, которой располагают разработчики при реализации решения. Каждое ограничение может существенно сузить возможность создания предполагаемого решения. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения (таблица 2.2). Таблица 2.2 - Возможные источники ограничений системы  Преграды на пути выявления требований Синдром «да. но... Одну из самых неприятных проблем, с которыми сталкиваются разработчики, можно назвать синдромом «да, но...» [3]. Это первичная наблюдаемая реакция пользователя на каждый разработанный фрагмент программного обеспечения, которая могла бы быть выражена следующими словами: «О, это действительно здорово! Можем реально использовать это, классная работа, молодцы, мальчики!» и т. д. «Да, но как насчет?.. Нельзя ли было?.. А что, если?.. Причина синдрома «да, но...» кроется глубоко в природе проектирования программного обеспечения как интеллектуального неосязаемого процесса. Проблема усугубляется тем, что команда разработчиков крайне редко предоставляет что-либо пользователям для обсуждения до окончания разработки (создания программного кода). Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что программисты подразумевают, когда описывают ее. И вот теперь она перед ними — впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали! Как это ни грустно, но нужно принять факт существования синдрома «да, но...» в качестве объективной реальности и сделать некоторые выводы, которые помогут членам команды смягчить влияние этого синдрома в будущих проектах: синдром «да, но...» является следствием человеческой природы и неотъемлемой частью разработки любого приложения; разработчики могут существенно уменьшить воздействие этого синдрома путем применения методов, которые выявят эти «но» как можно раньше. Выявив их на более ранних этапах, можно направить большую часть усилий на разработку программ, которые уже прошли тест на «да, но...Синдром "пользователь и разработчик». Синдром «пользователь и разработчик» является следствием расхождения взглядов пользователей и разработчиков. Пользователи и разработчики, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Предлагаются рекомендации по смягчению данной ситуации (таблица 2.3). Таблица 2.3 - Рекомендации решения проблемы  Функции Использование функций — удобный способ описания возможностей без лишних подробностей. Такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Тем не менее это высокий уровень абстракции, удобный для описания возможностей системы. Рекомендуемое количество функций, которое дает полное представление о разрабатываемой системе, — 25—99, однако желательно, чтобы их число не превышало 50. После того как все функции перечислены, можно приступить к принятию решения вида «отложить до следующей версии», «реализовать немедленно», «полностью отвергнуть» или «исследовать дополнительно». Это процесс корректировки маештаба лучше проводить на уровне функций, а не на уровне требований, иначе можно увязнуть в деталях. Чтобы лучше работать с этой информацией, введем понятие атрибутов функций — элементов данных, которые обеспечат дополнительную информацию о каждой функции (табл. 2.4). Таблица 2.4 - Атрибуты функций  Методы выявления требований: интервьюирование и анкетирование; совещания, посвященные требованиям; мозговой штурм и отбор идей; раскадровки; прецеденты; обыгрывание ролей; создание прототипов. Интервьюирование и анкетирование. Интервью помогает понять проблему, не оказывая влияния на ответы пользователя. Ниже приведены примеры контекстно-свободных вопросов: почему существует проблема? как она решается в настоящее время? как заказчик хотел бы ее решать? кто такие пользователи? каковы их навыки в компьютерной области? После этого интервьюер перечисляет основные пункты, чтобы проверить, все ли было правильно понято: «Итак, вы сказали мне...» (перечисляются описанные заказчиком проблемы своими словами). «Какие еще проблемы вы испытываете?» Правила подготовки интервью: Все вопросы должны быть составлены заранее. Перед интервью необходимо познакомиться с информацией о клиенте. Кратко записывайте ответы. Совещания. Хорошо проведенное совещание по вопросам требований имеет множество преимуществ: помогает создать команду, подчиненную одной цели — успеху данного проекта; все заинтересованные лица получают возможность высказать свое мнение, никто не остается в стороне; формирует соглашение между заинтересованными лицами и командой разработчиков по поводу того, что должно делать приложение; может высветить и разрешить политические вопросы, которые влияют на успех проекта; результат, предварительное определение системы на уровне функций, немедленно становится известным. Все материалы к совещанию должны быть предоставлены участникам заранее. Мозговой штурм. Все основные участники собираются в одной комнате, им раздаются материалы для заметок — не менее 25 листов формата от 7 х 12 до 12 х 17. Правила проведения мозгового штурма: Не допускается критика или дебаты. Дайте свободу фантазии. Генерируйте как можно больше идей. Переделывайте и комбинируйте идеи. Идеи каждый записывает на листок; позже они оглашаются. Критиковать их нельзя, дискутировать тоже не стоит, чтобы никого не обидеть. Идею надо попробовать развить или скомбинировать с какой-либо другой; если ничего не получится, то се просто изымут из рассмотрения. Идеи обязательно записывают на бумагу по следующим причинам: Сохраняется авторская формулировка. Существует гарантия, что они не будут утрачены. Есть перспектива развития идеи в дальнейшем. Обеспечивается непрерывный творческий процесс — не надо ждать, пока секретарь запишет мысль участника. Раскадровка. Цель раскадровки в раннем выявлении реакции типа «да, но... Существует три типа раскадровок. Пассивные. Пользователю излагают некую историю с применением рисунков, схем, картинок с экрана. Активные. Пользователю показывают «еще не созданный фильм» с применением анимации или слайдов. Интерактивные. Пользователь приобретает реальный опыт взаимодействия с системой (почти так же, как и на практике). Применение прецедентов. Рисуются схемы с факторами; в овале пишется вид выполняемого ими действия (рисунок 2.3).  Рисунок 2.3 - Схема применения прецедентов Обыгрывание ролей. Этот способ позволяет разработчику прочувствовать проблемы пользователя. Разработчик на время становится на место клиента, причем можно заранее написать сценарий для программистов, по которому они попытаются выполнить действия пользователей. Также очень эффективным способом является составление сценариев на основе CRC-карточек. Карточки описывают объект, его повеление и взаимодействие с другими объектами системы. Участники делят карточки между собой и используют их для ролевой игры, выполняя действия согласно предписаниям. Эффективный способ для выявления проблем проектирования системы. Прототипы требований. Прототип требований к ПО — это частичная реализация системы, созданная для того, чтобы помочь разработчикам, пользователям и клиентам точнее определить требования к системе. Этот метод также помогает решить проблему «да, но...» [3]. Таким образом, на базе знаний по составлению требований к ПО и при их корректном постоянном применении разработчик лучше поймет проблемы клиента, как следствие, создаст качественный программный продукт, отвечающий потребностям пользователей, и снизит риск краха проекта из-за функционального несоответствия приложения. Оценка качества процессов создания программного обеспечения Переход от штучной разработки программных продуктов к промышленному программированию обусловил повышение требований к качеству создаваемого ПО. В настоящее время существует несколько стандартов, связанных с оценкой качества этих процессов, которое обеспечивает компания-разработчик. К наиболее интересным для рассмотрения относятся: международные стандарты серии ISO 9000 (ISO 9000 — ISO 9004); СММ — Capability Maturity Model — модель зрелости (совершенствования) процессов создания программного обеспечения, предложенная SEI (Software Engineering Institute —институт программирования при университете Карнеги — Меллон); процесс сертификации программ на базе информации об их использовании. Серия стандартов ISO 9000 Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования» наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Основой регламентирования показателей качества программных средств ранее являлся международный стандарт ISO 9126:1991 (ГОСТ Р ИСО/МЭК 9126—93) «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». Завершается разработка и формализован последний проект состоящего из четырех частей стандарта ISO 9I26-1—ISO 9126-4 для замены небольшой редакции 1991 г. Проект состоит из следующих частей пол общим заголовком «Информационная технология — характеристики и метрики качества программного обеспечения»: «Часть 1. Характеристики и субхарактеристики качества; Часть 2. Внешние метрики качества»; «Часть 3. Внутренние метрики качества»; «Часть 4. Метрики качества в использовании». В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется группа устаревших ГОСТов, которые отстают от мирового уровня на 5—10 лет. 2.3 Жизненный цикл программы Понятие технологии разработки программы В современном мире всеобщей компьютеризации и информатизации требования, предъявляемые к программному обеспечению (ПО) вообще и к программным продуктам (ПП), программным средствам (ПС) и программам в частности, весьма высоки. В связи с этим обеспечение удовлетворяющих пользователя потребительских качеств программы, таких как надежность, быстродействие, соответствие заявленным возможностям, полнота документации, возможности расширения, развития и т. д., без строгого соблюдения определенной технологии практически невозможно. Рассмотрим сначала основные термины и определения. Политехнический словарь оперирует словом «технология» (от грен, techno — искусство, мастерство, умение и логия) в широком смысле как совокупностью «методов обработки, изготовления, изменения состояния, свойств, формы сырья, материала или полуфабрикатов, применимых в процессе производства, для получения готовой продукции»; как наукой «о способах воздействия на сырье, материалы и полуфабрикаты соответствующими орудиями производства. Разработка технологии осуществляется по отраслям производства». В Энциклопедическом словаре определение примерно то же, более того, задача науки технологии заключается в выявлении «физических, химических, механических и др. закономерностей с целью определения и использования на практике наиболее эффективных и экономичных производственных процессов». В Толковом словаре технология — это «совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства». Итак, на основании анализа вышеприведенных определений под технологией программирования в широком смысле следует понимать технологию разработки программного средства, как совокупность абсолютно всех технологических процессов его создания — от момента зарождения идеи о данном ПС до составления необходимой программной документации. Каждый процесс указанной совокупности базируется на использовании неких методов и средств, например компьютерных (в этом случае будем говорить о компьютерной технологии программирования). В литературе имеются и другие, отличные от приведенного понятия технологии программирования. Используется также близкое обсуждаемому понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств. Главное различие между технологией программирования и программной инженерией в качестве учебных дисциплин заключается в способах рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения — в этих процессах используются определенные методы и инструментальные средства разработки ПС (их применение и образует технологический процесс), тогда как в программной инженерии изучаются прежде всего методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Вопросом о том, каким образом эти методы и средства создают технологический процесс, в этом случае никто не задается. Не следует также пугать технологию программирования с методологией программирования, несмотря на то, что в обоих случаях изучаются соответствующие методы. Дело в том, что в технологии программирования методы рассматриваются «сверху», т. е. с точки зрения организации технологических процессов, а в методологии программирования — «снизу», т. е. с точки зрения основ их построения. Имея в виду, что надежность является неотъемлемым атрибутом ПС, технологию программирования здесь будем рассматривать как технологию разработки надежных ПС. Это значит, во-первых, обсуждение всех процессов разработки ПС (от идеи создания до «утилизации»), а во-вторых, вопросов построения программных конструкций, описания функций и принимаемых решений с точки зрения их человеческого восприятия. И наконец, в качестве продукта технологии появится надежное программное средство. Все вышеперечисленное будет существенно влиять на выбор методов и инструментальных средств при разработке ПС. Кратко резюмируем сказанное. Целью программирования является выполнение систематической последовательности действий для достижения автоматической обработки данных, таким образом, технология разработки программного обеспечения или, проще, технология программирования терминологически обозначает совокупность процессов для создания программного продукта требуемой функциональности. Результатом таких процессов является программное средство — совокупность логически связанных программ на носителях данных, снабженных программной документацией и предназначенных для людей, не участвовавших в процессе разработки. Поскольку технологический процесс разработки программного обеспечения вообще аналогичен процессу разработки программного средства (в частности), далее будем рассматривать специфику технологии программирования именно по отношению к ПО. Основа разработки программного обеспечения В основе разработки и дальнейшего применения программного обеспечения пользователем лежит понятие жизненного цикла, который, в сущности, является моделью его создания и использования, отражающей различные состояния, начиная с момента осознания необходимости появления данного ПО и заканчивая моментом его полного выхода из употребления. Существует несколько моделей жизненного цикла (ЖЦ), каждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают в себя пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем названия и краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77. 1. Техническое задание: постановка задачи; выбор критериев эффективности; проведение предварительных научно-исследовательских работ (НИР); разработка ТЗ. 2. Эскизный проект: структура входных и выходных данных; уточнение методов решения; общий алгоритм; разработка документации эскизного проекта. 3. Технический проект: уточнение структуры входных и выходных данных; разработка алгоритмов; формы данных; семантика и синтаксис языка; структура программы; конфигурация технических средств; план работ. 4. Рабочий проект: программирование и отладка; разработка документов; подготовка и проведение испытаний; корректировка программы и документов по итогам испытаний. 5. Внедрение: передача программы и документов для сопровождения; оформление акта; передача в Фонд алгоритмов и программ (ФАП). Модели жизненного цикла В процессе развития технологий разработки программного обеспечения сложились следующие модели жизненного цикла программного обеспечения: Каскадная (характерно последовательное выполнение входящих в ее состав этапов); Итерационная (модель с промежуточным контролем); Спиральная (развитие продукта по спирали - от версии к версии); Rational Objectory Process — модель жизненного цикла (методология объектно-ориентированного программирования). |