Введение в программную инженерию. Введение в программную инженерию понятие программной инженерии. Продолжение кризиса программирования

Транскрипт

1 Введение в программную инженерию Оглавление Лекция 1. О предмете изучения... 3 Программная инженерия... 3 Программное обеспечение... 5 Литература... 6 Лекция 2. Процесс разработки программного обеспечения... 7 Процесс... 7 Совершенствование процесса... 8 Классические модели процесса... 9 Литература Лекция 3. Рабочий продукт, дисциплина обязательств, проект Рабочий продукт Дисциплина обязательств Проект Литература Лекция 4. Архитектура ПО Обсуждение Определение Множественность точек зрения Язык UML Литература Лекция 5. Управление требованиями Проблема Виды и свойства требований Варианты формализации требований Цикл работы с требованиями Литература Лекция 6. Конфигурационное управление Проблема Единицы конфигурационного управления Управление версиями Управление сборками Понятие baseline Литература Лекция 7. Тестирование Управление качеством Тестирование Работа с ошибками Литература

2 Лекция 8. Диаграммные техники в работе со знаниями Метод случаи использования Итеративный цикл автор/рецензент Карты памяти Литература Лекция 9. MSF История и текущий статус Основные принципы Модель команды Прочие особенности Литература Лекция 10. CMMI Что такое CMMI? Уровни зрелости процессов по CMMI Области усовершенствования Литература Лекция 11. «Гибкие» (agile) методы разработки Общее Extreme Programming Scrum Литература Лекция 12. Обзор технологии Microsoft Visual Studio Team System (VSTS) Обзор Состав продукта Правила инсталляции Пакет Team Explorer Лекция 13. VSTS: управление элементами работ (Work Items) Определение, свойства, жизненный цикл Средства использования Лекция 14. VSTS: конфигурационное управление Система контроля версий Автоматические сборки Лекция 15. VSTS: тестирование Система отслеживания ошибок Модульные тесты Пакеты тестов Автоматическое тестирование Web-приложений Лекция 16. VSTS: поддержка различных моделей процесса Поддержка шаблонов процесса Обзор существующих шаблонов MSF for Agile Software Development Scrum

3 Лекция 1. О предмете изучения Программная инженерия Чем программирование отличается от программой инженерии? Тем, что первое является некоторой абстрактной деятельностью и может происходить во многих различных контекстах. Можно программировать для удовольствия, для того, чтобы научиться (например, на уроках, на семинарах в университете), можно программировать в рамках научных разработок. А можно заниматься промышленным программированием. Как правило, это происходит в команде, и совершенно точно для заказчика, который платит за работу деньги. При этом необходимо точно понимать, что нужно заказчику, выполнить работу в определенные сроки и результат должен быть нужного качества того, которое удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить этим дополнительным требованиям, программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.). Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге). Трудозатраты на анализ и проектирование, а также форма представления их результатов сильно варьируются от видов проектов и предпочтений разработчиков и заказчиков. Требуются также специальные усилия по организации процесса разработки. В общем виде это итеративно-инкрементальная модель, когда требуемая функциональность создается порциями, которые менеджеры и заказчик могут оценить, и тем самым есть возможность управления ходом разработки. Однако эта общая модель имеет множество модификаций и вариантов. Разработку системы также необходимо выполнять с учетом удобств ее дальнейшего сопровождения, повторного использования и интеграции с другими системами. Это значит, что система разбивается на компоненты, удобные в разработке, годные для повторного использования и интеграции. А также имеющие необходимые характеристики по быстродействию. Для этих компонент тщательно прорабатываются интерфейсы. Сама же система документируется на многих уровнях, создаются правила оформления программного кода то есть оставляются многочисленные семантические следы, помогающие создать и сохранить, поддерживать единую, стройную архитектуру, единообразный стиль, порядок Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией (software engineering) 1. Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Ведь для облегчения выполнения каждого отдельного проекта, для возможности использовать разнообразный положительный опыт, достигнутый другими командами и 1 В 70-х годах академиком А.П.Ершовым термин software engineering, переводился на расский язык как «технология программирования». Программная инженерия более современный, но менее традиционный перевод этого же термина, предложенный в конце 90-х И.В.Поттосиным. В рамках данного курса будем пользоваться именно этим вариантом перевода. 3

4 разработчиками, этот самый опыт подвергается осмыслению, обобщению и надлежащему оформлению. Так появляются различные методы и практики (best practices) тестирования, проектирования, работы над требованиями и пр., архитектурных шаблонов и пр. А также стандарты и методологии, касающиеся всего процесса в целом (например, MSF, RUP, CMMI, Scrum). Вот эти-то обобщения и входят в программную инженерию как в область знания. Необходимость в программной инженерии как в специальной области знаний были осознаны мировым сообществом в конце 60-х годов прошлого века, более чем на 20 лет позже рождения самого программирования, если считать таковым знаменитый отчет фон Неймана «First Draft of a Report on the EDVAC», обнародованный им в 1945 году. Рождением программной инженерии является 1968 год конференция NATO Software Engineering, г. Гармиш (ФРГ), которая целиком была посвящена рассмотрению этих вопросов. В сферу программной инженерии попадают все вопросы и темы, связанные с организацией и улучшением процесса разработки ПО, управлением коллектива разработчиков, разработкой и внедрением программных средств поддержки жизненного цикла разработки ПО. Программная инженерия использует достижения информатики, тесно связана с системотехникой, часто предваряется бизнес-реинжинирингом. Немного подробнее об этом контексте программной инженерии. Информатика (computer science) это свод теоретических наук, основанных на математике и посвященных формальным основам вычислимости. Сюда относятся математическую логику, теорию грамматик, методы построения компиляторов, математические формальные методы, используемые в верификации и модельном тестировании и т.д. Трудно строго отделить программную инженерию от информатики, но в целом направленность этих дисциплин различна. Программная инженерия нацелена на решение проблем производства, информатика на разработку формальных, математизированных подходов к программированию. Системотехника (system engineering) объединяет различные инженерные дисциплины по разработке всевозможных искусственных систем энергоустановок, телекоммуникационных систем, встроенных систем реального времени и т.д. Очень часто ПО оказывается частью таких систем, выполняя задачу управления соответствующего оборудования. Такие системы называются программно-аппаратными, и участвуя в их создании, программисты вынуждены глубоко разбираться в особенностях соответствующей аппаратуры. Бизнес-реинжиниринг (business reengineering) в широком смысле обозначает модернизацию бизнеса в определенной компании, внедрение новых практик, поддерживаемых соответствующими, новыми информационными системами. При этом акцент может быть как на внутреннем переустройстве компании так и на разработке нового клиентского сервиса (как правило, эти вопросы взаимосвязаны). Бизнесреинжиниринг часто предваряет разработку и внедрение информационных систем на предприятии, так как требуется сначала навести определенный порядок в делопроизводстве, а лишь потом закрепить его информационной системой. Связь программной инженерии (как области практической деятельности) с информатикой, системотехникой и бизнес-реинжинирингом показана на рис

5 Рис. 1.1 Программное обеспечение Определение. Будем понимать под программным обеспечением (ПО) множество развивающихся во времени логических предписаний, с помощью которых некоторый коллектив людей управляет и использует многопроцессорную и распределенную систему вычислительных устройств. Это определение, данное Харальдом Милсом, известным специалистом в области программной инженерии из компании IBM, заключает в себе следующее. 1. Логические предписания это не только сами программы, но и различная документация (например, по эксплуатации программ) и шире определенная система отношений между людьми, использующими эти программы в рамках некоторого процесса деятельности. 2. Современное ПО предназначено, как правило, для одновременной работы с многими пользователями, которые могут быть значительно удалены друг от друга в физическом пространстве. Таким образом, вычислительная среда (персональные компьютеры, сервера и т.д.), в которой ПО функционирует, оказывается распределенной. 3. Задачи решаемые современным ПО, часто требуют различных вычислительных ресурсов в силу различной специализации этих задач, из-за большого объема выполняемой работы, а также из соображений безопасности. Например, появляется сервер базы данных, сервер приложений и пр. Таким образом, вычислительная среда, в которой ПО функционирует, оказывается многопроцессорной. 4. ПО развивается во времени исправляются ошибки, добавляются новые функции, выпускаются новые версии, меняется его аппаратная база. Свойства. Таким образом, ПО является сложной динамической системой, включающей в себя технические, психологические и социальные аспекты. ПО заметно отличается от других видов систем, создаваемых (созданных) человеком механических, социальных, научных и пр., и имеет следующие особенности, выделенные Фредериком Бруксом в его знаменитой статье «Серебрянной пули нет». 1. Сложность программных объектов, которая существенно зависит от их размеров. Как правило, большее ПО (большее количество пользователей, больший объем обрабатываемых данных, более жесткие требования по быстродействию и пр.) с аналогичной функциональностью это другое ПО. Классическая наука строила простые модели сложных явлений, и это удавалось, так как сложность не была характеристической чертой рассматриваемых явлений. (Сравнение программирования именно с наукой, а не с театром, кинематографом, спортом и другими областями человеческой деятельности, оправдано, поскольку оно возникло, 5

6 главным образом, из математики, а первые его плоды компьютеры, языки программы предназначались для использования при научных расчетах. Кроме того, большинство программистов имеют естественнонаучное, математическое или техническое образование. Таким образом, парадигмы научного мышления широко используются при программировании явно или неявно.) 2. Согласованность ПО основывается не на объективных посылках (подобно тому, как различные системы в классической науке основываются на постулатах и аксиомах), а должно быть согласовано с большим количеством интерфейсов, с которыми впоследствии оно должно взаимодействовать. Эти интерфейсы плохо поддаются стандартизации, поскольку основываются на многочисленных и плохо формализуемых человеческих соглашениях. 3. Изменяемость ПО легко изменить и, как следствие, требования к нему постоянно меняются в процессе разработки. Это создает много дополнительных трудностей при его разработке и эволюции. 4. Нематериальность 2 ПО невозможно увидеть, оно виртуально. Поэтому, например, трудно воспользоваться технологиями, основанными на предварительном создании чертежей, успешно используемыми в других промышленных областях (например, в строительстве, машиностроении). Там на чертежах в схематичном виде воспроизводятся геометрические формы создаваемых объектов. Когда объект создан, эти формы можно увидеть. А на чем мы основываемся, когда изображаем ПО? Литература 1. H.Mills. The management of software engineering Part I: Principles of software engineering. // IBM System Journal, Vol. 38, No 2&3, 1999, pp F. Brooks. No Silver Bullet. Information Proceeding of the IFIP 10 th World Computing Conference pp / Русский перевод: Ф. Брукс. Мифический человекомесяц или как создаются программные системы. СПб Символ, c. 3. I.Sommerville Software Engineering. 6 th edition. Addison-Wesley, p. / Русский перевод: И.Соммервилл. Инженерия программного обеспечения. Издательский дом Вильямс, c. 4. А.П.Ершов. Технология разработки систем программирования. // А.П.Ершов. Избранные труды. ВО Наука. Новосибирск C Поттосин И.В. Программная инженерия: содержание, мнения и тенденции. // Программирование N 4. C Д.В.Кознов. Введение в программную инженерию. Часть I. Изд-во Санкт- Петербургского ун-та, 2005 г., 43 с. 2 Здесь мы немного поправили классика у него была незримость.. 6

7 Лекция 2. Процесс разработки программного обеспечения Без процесса не понять. Из деловой переписка менеджера программного проекта. Процесс Как мы работаем, какова последовательность наших шагов, каковы нормы и правила в поведении и работе, каков регламент отношений между членами команды, как проект взаимодействует с внешним миром и т.д.? Все это вместе мы склонны называть процессом. Его осознание, выстраивание и улучшение - основа любой эффективной групповой деятельности. Не случайно поэтому, что процесс оказался одним из основных понятий программной инженерии. Центральным объектом изучения программной инженерии является процесс создания ПО множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.). Однако на сегодняшний день не существует универсального процесса разработки ПО набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Tem System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI, Scrum и др. В рамках компании возможна и полезна объединение и стандартизация всех текущих процессов, которую будем называть стандартным процессом. Последний, таким образом, оказывается некоторой базой данных, содержащей следующее: информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования различных IDE, СУБД и т.д.); описание практик разработки проектного менеджмента, правил работы с заказчиком и т.д.; шаблонов проектных документов технических заданий, проектных спецификаций, тестовых планов и т.д. и пр. Также возможна стандартизация процедуры разработки конкретного процесса как «вырезки» из стандартного. Основная идея стандартного процесса курсирование внутри компании передового опыта, а также унификация средств разработки. Очень уж часто в компаниях различные департаменты и проекты сильно отличаются по зрелости процесса разработки, а также затруднено повторное использование передового опыта. Кроме того, случаются, что компания использует несколько средств параллельных инструментов разработки, например, СУБД средства версионного контроля. Иногда это бывает оправдано (например, таковы требования заказчика), часто это необходимо например, 7

8 Java.NET (большая компетентность оффшорной компании позволяет ей брать более широкий спектр заказов). Но очень часто это произвольный выбор самих разработчиков. В любом случае, такая множественность существенно затрудняет миграцию специалистов из проекта в проект, использование результатов одного проекта в другом и т.д. Однако при организации стандартного процесса необходимо следить, чтобы стандартный процесс не оказался всего лишь формальным, бюрократическим аппаратом. Понятие стандартного процесса введено и подробно описано в подходе CMMI. Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии «единой воли» в организации, существующей именно на уровне процесса. На уровне продаж, бухгалтерии и др. привычных для всех компаний процессов и активов единство осуществить не трудно. А вот на уровне процессов разработки очень часто каждый проект оказывается сам по себе (особенно в оффшорных проектах) «текучка» захватывает и изолирует проекты друг от друга очень прочно. Совершенствование процесса Определение. Совершенствование процесса (software process improvement) это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем. 1. Происходит быстрая смена технологий разработки ПО требует изучения и внедрения новых средcтв разработки. 2. Наблюдается быстрый рост компаний и их выход на новые рынки, что требует новой организации работ. 3. Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки. Что и каким образом можно улучшать. 1. Переход на новые средства разработки, языки программирования и т.д. 2. Улучшение отдельных управленческих и инженерных практик тестирования, управления требованиями и пр. 3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI). 4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.). Мы отделили п. 3 от п. 4 потому, что на практике 4 далеко не всегда означает действительную созидательную работу по улучшению процессов разработки ПО, а часто сводится к поддержанию соответствующего документооборота, необходимого для получения сертификации. Сертификат потом используется как средство, козырь в борьбе за заказы. Главная трудность реального совершенствования процессов в компании заключается в том, что она при этом должна работать и создавать ПО, ее нельзя «закрыть на учет». Отсюда вытекает идея непрерывного улучшения процесса, так сказать, малыми порциями, чтобы не так болезненно. Это тем более разумно, что новые технологии разработки, появляющиеся на рынке, а также развитие уже существующих нужно постоянно отслеживать. Эта стратегия, в частности, отражена в стандарте совершенcтвования процессов разработки CMMI. 8

9 Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две следующие парадигмы. 1. Organization pull инновации нацелены на решение конкретных проблем компании. 2. Technology push широкомасштабное внедрение инноваций из стратегических соображений. Вместо конкретных проблем, которые будут решены после внедрения инновации, в этом случае рассматриваются показатели компании (эффективность, производительность, годовой оборот средств, увеличение стоимости акций публичной компании), которые будут увеличены, улучшены после внедрения инновации. При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которых в данный момент ничего не известно. Пример использования стратегии organization pull внедрение новых средств тестирования в ситуации, когда высоки требования по качеству в проекте, либо когда качество программной системы не удовлетворяет заказчика. Пример использования стратегии technology push переход компании со средств структурной разработки на объектно-ориентрованные. Еще один пример использования той же стратегии внедрение стандартов качества ISO 9000 или CMMI. В обоих этих случая компания не решает какую-то одну проблему или ряд проблем она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д. Проблемы применения стратегии technology push в том, что требуется глобальная перестройка процесса. Но компанию нельзя закрыть на реконструкцию за это время положение на рынке может оказаться занято конкурентами, акции компании могут упасть и т.д. Таким образом, внедрение инноваций, как правило, происходит параллельно с обычной деятельностью компании, поэтапно, что в случае с technology push сопряжено с большими трудностями и рисками. Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push. Необходимо также отметить, что существуют проблемы, которые невозможно устранить точечными переделками процесса, то есть необходимо применять стратегию technology push. Приведем в качестве примера зашедший в тупик процесс сопровождения и развития семейства программных продуктов компания терпит большие убытки, сопровождая уже поставленные продукты, инструментальные средства проекта безнадежно устарели и находятся в плачевном состоянии, менеджмент расстроен, все попытки руководства изменить процесс наталкиваются на непонимание коллектива, ссоры и конфликты. Возможно, что в таком случае без революции не обойтись. Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push. Классические модели процесса Определение модели процесса. Процесс создания программного обеспечения не является однородным. Тот или иной метод разработки ПО, как правило, определяет некоторую динамику развертывания тех или иных видов деятельности, то есть, определяет модель процесса (process model). 9

10 Модель является хорошей абстракцией различных методов разработки ПО, позволяя лаконично, сжато и информативно их представить. Однако, сама идея модели процесса является одной из самых ранних в программной инженерии, когда считалось, что удачная модель самое главное, что способствует успеху разработки. Позднее пришло осознание, что существует множество других аспектов (принципы управления и разработки, структуру команды и т.д.), которые должны быть определены согласовано друг с другом. И стали развиваться интегральные методологии разработки. Тем не менее существует несколько классических моделей процесса, которые полезны на практике и которые будут рассмотрены ниже. Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности. Фаза (phase) это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы. Редко какой заказчик согласится первый раз увидеть результаты только после завершения проекта. С другой стороны, подрядчики предпочитают получать деньги постепенно, по мере того, как выполняются отдельные части работы. Таким образом, появляются фазы, позволяющие создавать и предъявлять промежуточные результаты проекта. Фазы полезны также безотносительно взаимодействия с заказчиком с их помощью можно синхронизировать деятельность разных рабочих групп, а также отслеживать продвижение проекта. Примерами фаз может служить согласование с заказчиком технического задания, реализация определенной функциональности ПО, этап разработки, оканчивающийся сдачей системы на тестирование или выпуском альфаверсии. Вид деятельности (activity) это определенный тип работы, выполняемый в процессе разработки ПО. Разные виды деятельности часто требуют разные профессиональные навыки и выполняются разными специалистами. Например, управление проектом выполняется менеджером проекта, кодирование программистом, тестирование тестеровщиком. Есть виды деятельности, которые могут выполняться одними и теми же специалистами например, кодирование и проектирование (особенно в небольшом проекте) часто выполняют одни и те же люди. В рамках одной фазы может выполнятся много различных видов деятельности. Кроме того, один вид деятельности может выполняться на разных фазах например, тестирование: на фазе анализа и проектирования можно писать тесты и налаживать тестовое окружение, при разработке и перед сдачей производить, собственно, само тестирование. На настоящий момент для сложного программного обеспечения используются многомерные модели процесса, в которых отделение фаз от видов деятельности существенно облегчает управление разработкой ПО. Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы. Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования. 10

11 Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование см. рис Еще одним достоинством этой модели явилось ограничение возможности возвратов на произвольный шаг назад, например, от тестирования к анализу, от разработки работе над требованиями и т.д. Отмечалось, что такие возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг, например, от тестирования к кодированию, от кодирования к проектированию и т.д. Разработка системных требований Разработка требований к ПО Анализ Проектирование Кодирование Тестирование Использование Рис Наконец, в рамках этой модели было введено прототипирование, то есть предлагалось разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия прототип позволяет увидеть основные риски и обосновано принять главные архитектурные решения. На создание прототипа отводилось до одной трети времени всей разработки. В годах прошлого века эта модель прочно укоренилась в разработке ПО в силу своей простоты и сходности с моделями разработки иных, не программных систем. В дальнейшем, в связи с развитием программной инженерии и осознанием итеративного характера процесса разработки ПО эта модель активно критиковалась, практически, каждым автором соответствующих статей и учебников. Стало общепринятым мнение, что она не отражает особенностей разработки ПО. Недостатками водопадной модели являются: отождествление фаз и видов деятельности, что влечет потерю гибкости разработки, в частности, трудности поддержки итеративного процесса разработки; требование полного окончания фазы-деятельности, закрепление результатов в виде подробного исходного документа (технического задания, проектной спецификации); однако опыт разработки ПО показывает, что невозможно 11

12 полностью завершить разработку требований, дизайн системы и т.д. все это подвержено изменениям; и причины тут не только в том, что подвижно окружение проекта, но и в том, что заранее не удается точно определить и сформулировать многие решения, они проясняются и уточняются лишь впоследствии; интеграция всех результатов разработки происходит в конце, вследствие чего интеграционные проблемы дают о себе знать слишком поздно; пользователи и заказчик не могут ознакомиться с вариантами системой во время разработки, и видят результат только в самом конце; тем самым, они не могут повлиять на процесс создания системы, и поэтому увеличиваются риски непонимания между разработчиками и пользователями/заказчиком; модель неустойчива к сбоям в финансировании проекта или перераспределению денежных средств, начатая разработка, фактически, не имеет альтернатив по ходу дела. Однако данная модель продолжает использоваться на практике для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в оффшорных проектах3 с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другим модели и методологии, например, в MSF. Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной. Последовательность витков может быть такой: на первом витке принимается решение о целесообразности создания ПО, на следующем определяются системные требования, потом осуществляется проектирование системы и т.д. Витки могут иметь и иные значения. Каждый виток имеет следующую структуру (секторы): определение целей, ограничений и альтернатив проекта; оценка альтернатив, оценка и разрешение рисков; возможно использование прототипирования (в том числе создание серии прототипов), симуляция системы, визуальное моделирование и анализ спецификаций; фокусировка на самых рисковых частях проекта; разработка и тестирование здесь возможна водопадная модель или использование иных моделей и методов разработки ПО; планирование следующих итераций анализируются результаты, планы и ресурсы на последующую разработку, принимается (или не принимается) решение о новом витке; анализируется, имеет ли смысл продолжать разрабатывать систему или нет; разработку можно и приостановить, например, из-за сбоев в финансировании; спиральная модель позволяет сделать это корректно. 3 От английского offshore вне берега, в расширенном толковании вне одной страны. 12

13 Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение. Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели. Спиральная модель не нашла широкого применения в индустрии и важна, скорее в историко-методологическом плане: она является первой итеративной моделью, имеет красивую метафору спираль, и, подобно водопадной модели, использовалась в дальнейшем при создании других моделей процесса и методологий разработки ПО. Литература 1. I.Sommerville Software Engineering. 6th edition. Addison-Wesley, p. / Русский перевод: И.Соммервилл. Инженерия программного обеспечения. Издательский дом «Вильямс», c. 2. W.Humphrey. Managing the Software Process. Addison-Wesley, p. 3. R. W.Zmud. An Examination of «Push-Pull» Theory Applied to Process Innovation in Knowledge Work, Management Science, Vol. 30(6), 1984, pp B. Boehm. A Spiral Model of Software Development and Enhancement. // IEEE Computer, vol.21, #5, May P W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August P Переиздана: Proceedings of the 9th International Software Engineering Conference, Computer Society Press, P Р.Т.Фатрепп, Д.Ф.Шафер, Л.И.Шафер. Управление программными проектами: достижение оптимального качества при минимуме затрат. Изд. дом «Вильямс» c. 7. Д.В.Кознов. Языки визуального моделирования: проектирование и визуализация программного обеспечения. Изд. СПбГУ, с. 8. Д.В.Кознов. Введение в программную инженерию. Часть I. Изд-во Санкт- Петербургского ун-та, 2005 г., 43 с. 9. Д.Ахен, А.Клауз, Р.Тернер. CMMI: комплексный подход к совершенствованию процессов. Пер с англ. М.:МФК с. 10. CMMI for Development, Version 1.2. CMMI-DEV (Version 1.2, August 2006). Carnegie Mellon University Software Engineering Institute (2006). Retrieved on 22 August

14 Лекция 3. Рабочий продукт, дисциплина обязательств, проект В силу творческого характера программирования, существенной молодости участников разработки ПО, оказываются актуальными некоторые вопросы обычного промышленного производства, ставшие давно общим местом. Прежде всего, это дисциплина обязательств и рабочий продукт. Данные знания, будучи освоенными на практике, чрезвычайно полезны в командной работе. Кроме того, широко применяемые сейчас на практике методологии разработки ПО, поддержанные соответствующим программным инструментарием, активно используют эти понятия, уточняя и конкретизируя их. Рабочий продукт Одной из существенных условий для управляемости промышленного процесса является наличие отдельно оформленных результатов работы как в окончательной поставке так и промежуточных. Эти отдельные результаты в составе общих результатов работ помогают идентифицировать, планировать и оценивать различные части результата Промежуточные результаты помогают менеджерам разных уровней отслеживать процесс воплощения проекта, заказчик получает возможность ознакомиться с результатами задолго до окончания проекта. Более того, сами участники проекта в своей ежедневной работе получают простой и эффективный способ обмена рабочей информацией обмен результатами. Таким результатом является рабочий продукт (work product) любой артефакт, произведенный в процессе разработки ПО, например, файл или набор файлов, документы, составные части продукта, сервисы, процессы, спецификации, счета и т.д. Часть итоговой поставки Промежуточный Бывает Рабочий продукт Напрмиер Пользовтельская документация Компоненты ПО Налаженные процессы Рис

15 Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем (not to be engineered), хотя может быть таковым. Нематериальный рабочий продукт это, как правило, некоторый налаженный процесс промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д. Важно отметить, что рабочий продукт совсем не обязательно является составной частью итоговой поставки. Например, налаженный процесс тестирования системы не поставляется заказчику вместе с самой системой. Умение управлять проектами (не только в области программирования) во многом связано с искусством определять нужные рабочие продукты, настаивать на их создании и в их терминах вести приемку промежуточных этапов работы, организовывать синхронизацию различных рабочих групп и отдельных специалистов. Многие методологии включают в себя описание специфичных рабочих продуктов, используемых в процессе CMMI, MSF, RUP и др. Например, в MSF это программный код, диаграммы приложений и классов (application diagrams и class diagrams), план итераций (iteration plan), модульный тест (unit test) и др. Для каждого из них точно описано содержание, ответственные за разработку, место в процессе и др. аспекты. Остановимся чуть детальнее на промежуточных рабочих продуктах. Компонента ПО, созданная в проекте одним разработчиком и предоставленная для использования другому разработчику, оказывается рабочим продуктом. Ее надо минимально протестрировать, поправить имена интерфейсных классов и методов, быть может, убрать лишнее, не имеющее отношение к функциональность данной компоненты, по-лучше разделить public и private, и т.д. То есть проделать некоторую дополнительную работу, которую, быть может, разработчик и не стал делать, если бы продолжал использовать компоненту только сам. Объем эти дополнительных работ существенно возрастает, если компонента должна быть представлена для использования в разработке, например, в другой центр разработки (например, иностранным партнерам, что является частой ситуацией в оффшорной разработке). Итак, изготовление хороших промежуточных рабочих продуктов очень важно для успешности проекта, но требует дополнительной работы от их авторов. Работать одному, не предоставляя рабочих продуктов легче и для многих предпочтительнее. Но работа в команде требует накладных издержек, в том числе и в виде трат на создание промежуточных рабочих продуктов. Конечно, качество этих продуктов и трудозатраты на их изготовление сильно варьируются в зависимости от ситуации, но тут важно понимать сам принцип. Итак, подытожим, что промежуточный рабочий продукт должен обязательно иметь ясную цель и конкретных пользователей, чтобы минимизировать накладные расходы на его создание. 15

16 Обмена результатами Контроля разработки Используется для Рабочий продукт Должен иметь Требует Цель Пользователь Накладные расходы Рис Дисциплина обязательств В основе разделения обязанностей в бизнесе и промышленном производстве лежит, корпоративных правил и норм лежит определенная деловая этика, форма отношений дисциплина обязательств. Она широко используется на практике и является одним из возможных форм социального взаимоотношения между людьми. Привнесение в бизнес и промышленность иных моделей человеческих отношений семейных, сексуальных, дружеских и т.д. часто наносит делам серьезный урон, порождает конфликтность, понижает эффективность. Основой этой формы отношений являются обязательства, которые: даются добровольно; не даются легко работа, ресурсы, расписание должны быть тщательно учтены; между сторонами включает в себя то, что будет сделано, кем и в какие сроки; открыто и публично сформулированы (то есть это не тайное знание). Кроме того: ответственная сторона стремится выполнить обязательства, даже если нужна помощь; до наступления deadline, как только становится очевидно, что работа не может быть закончена в срок, обсуждаются новые обязательства. Отметим, что дисциплина обязательств не является каким-то сводом правил, законов, она отличается также от корпоративной культуры. Это определенный групповой психический феномен, существующий в обществе современных людей. Приведенные выше пункты не являются исчерпывающим описанием этого феномена, но лишь проявляют и обозначают его, так сказать, вызывают нужные воспоминания. Дисциплина обязательств, несмотря на очевидность, порой, не просто реализуется на практике, например, в творческих областях человеческой деятельности, в области 16

17 обучения и т.д. Существуют отдельные люди, которым эта дисциплина внутренне чужда вне зависимости от их рода деятельности. С другой стороны, люди, освоившие эту дисциплину, часто стремятся применять ее в других областях жизни и человеческих отношений, что оказывается не всегда оправданным. Подчеркнем, что данная дисциплина является далеко не единственной моделью отношений между людьми. В качестве примера можно рассмотреть отношения в семье или дружбу, что, с очевидностью, не могут быть выражены дисциплиной обязательств. Так, вместо точности и пунктуальности в этих отношениях важно эмоционально-чувственное сопереживание, без которого они невозможны. Дисциплине обязательств уделяется много внимания в рамках MSF, поскольку там в модели команды нет лидера, начальника. Эта дисциплина реализована также в Scrum: Scrum-команда имеет много свобод, и в силу этого большую ответственность. Регламентируются также правила действий, когда обязательства не могут быть выполнены такой командой. Проект Классическое операционное разделение труда идет еще от Адама Смита и является сутью массового индустриального производства. То есть существует четко налаженный процесс работы и имеются области специализации один цех точит, другой строгает, третий собирает, четвертый красит и т.д. Пропускная способность такого производства намного превосходит выполнение всей работы одним человеком или одной группой. Таким образом в XIX веке операционное разделение труда стало основой мануфактур, вытеснивших индивидуальное, ремесленное производство. В начале XX века эту структуру работ перенесли и на управление то есть многочисленные менеджеры контролировали отдельные участки работ. Однако высокий уровень сложности ряда задач в промышленности и бизнесе не позволяет (к счастью!) так работать везде. Существует много творческих, новых задач, где, быть может, в будущем и удастся создать конвейеры, но в данный момент для их решения требуется существенная концентрация сил и энергии людей, неожиданные решения, а также удача и легкая рука. Это и есть область проектов. Проеќт это уникальная (в отличии от традиционной пооперационной промышленного производства) деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата/цель, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсами и срокам, а также требованиям к качеству и допустимому уровню риска. В частности, разработка программного обеспечения, является, преимущественно, проектной областью. Необходимо различать проекты промышленные и проекты творческие. У них разные принципы управления. Сложность промышленных проектов в большом количестве разных организаций, компаний и относительной уникальности самих работ. Пример строительство многоэтажного дома. Сюда же относятся различные международные проекты и не только промышленные образовательные, культурные и пр. Задача в управлении такими проектами это все охватить, все проконтролировать, ничего не забыть, все свести воедино, добиться движения, причем движения согласованного. Творческие проекты характеризуются абсолютной новизной идеи новый сервис, абсолютно новый программный продукт, какого еще не было на рынке, проекты в области искусства и науки. Любой начинающий бизнес, как правило, является таким вот творческим проектом. Причем новизна в подобных проектов не только абсолютная такого еще не было. Такое, может, уже и было, но только не снами, командой проекта. То есть присутствует огромный объем относительной новизны для самих людей, которые воплощают этот проект. 17

18 Проекты по разработке программного обеспечения находятся между двумя этими полюсами, занимая в этом пространстве различное положение. Часто они сложны потому, что объемны и находятся на стыке различных дисциплин того целевого бизнеса, куда должен встроиться программный продукт, и сложного, нетривиального программирования. Часто сюда добавляется еще разработка уникального электронномеханического оборудования. С другой стороны, поскольку программирование активно продвигается в разные сферы человеческой деятельности, то происходит это путем создания абсолютно новых, уникальных продуктов, и их разработка и продвижение обладают всеми чертами творческих проектов. Управление проектами (project management) область деятельности, в ходе которой, в рамках определенных проектов, определяются и достигаются четкие цели при нахождении компромисса между объемом работ, ресурсами (такими как время, деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Отметим несколько важных аспектов управления проектами. Stakeholedrs это люди/стороны, которые не участвуют непосредственно в проекте, но влияют на него и или заинтересованы в его результатах. Это могут быть будущие пользователи системы (например, в ситуации, когда они и заказчик это не одно и то же), высшее руководство компании-разработчика и т.д. Идентификация всех stakeholders и грамотная работа с ними важная составляющая успешного проектного менеджмента Project scope это границы проекта. Это очень важное понятие для программных проектов в виду изменчивости требований. Часто бывает, что разработчики начинают создавать одну систему, а после, постепенно, она превращается в другую. Причем для менеджеров по продажам, а также заказчика, ничего радикально не произошло, а с точки зрения внутреннего устройства ПО, технологий, алгоритмов реализации, архитектуры все радикально меняется. За подобными тенденциями должен следить и грамотно с ними разбираться проектный менеджмент. Компромиссы важнейший аспект управления программными проектами в силу согласовываемости ПО. Важно не потерять все согласуемые параметры и стороны и найти приемлемый компромисс. Одна их техник управления компромиссами будет рассказана в контексте изучения методологии MSF. При разработке программных проектов, следуя MSF 3.1, важны следующие области управления. Область управления проектами Описание Планирование и мониторинг проекта, контроль за изменениями в проекте (Project planning / Tracking / Change Control) Управление рамками проекта (Scope Management) Управление календарным графиком проекта (Schedule Management) Интеграция и синхронизация планов проекта; организация процедур и систем управления и мониторинга проектных изменений Определение и распределение объема работы (рамок проекта); управление компромиссными решениями в проекте Составление календарного графика исходя из оценок трудозатрат, упорядочивание задач, соотнесение доступных ресурсов с задачами, 18

19 Управление стоимостью (Cost Management) Управление персоналом (Staff Resource Management) Управление коммуникацией (Communications Management) Управление рисками (Risk Management) Управление (Procurement) снабжением Управление качеством (Quality Management) применение статистических методов, поддержка календарного графика Оценки стоимости исходя из оценок временных затрат; отчетность о ходе проекта и его анализ; анализ затратных рисков; функциональностоимостной анализ (value analysis) Планирование ресурсов; формирование проектной команды; разрешение конфликтов; планирование и управление подготовкой Коммуникационное планирование (между проектной группой, заказчиком/спонсором, потребителями/пользователями, др. заинтересованными лицами); отчетность о ходе проекта Организация процесса управления рисками в команде и содействие ему; обеспечение документооборота управления рисками Анализ цен поставщиков услуг и/или аппаратного/программного обеспечения; подготовка документов об инициировании предложений (requests for proposals RFPs), выбор поставщиков и субподрядчиков; составление контрактов и переговоры об их условиях; договора; заказы на поставку и платежные требования Планирование качества, определение применяемых стандартов, документирование критериев качества и процессов его измерения Литература 1. W.Humphrey. Managing the Software Process. Addison-Wesley, p. 2. Д.Ахен, А.Клауз, Р.Тернер. CMMI: комплексный подход к совершенствованию процессов. Пер с англ. М.:МФК с. 3. Carnegie Mellon University Software Engineering Institute (2006). Retrieved on 22 August

20 Лекция 4. Архитектура ПО Обсуждение Как-то раз один менеджер объяснял основные идеи одного достаточно крупного проекта, которым он руководил. Он начертил на доске три кубика: frontend, backend, tools. И сказал, что это и есть главное строение проекта. И в смысле внутреннего устройства продукта, и в смысле распределения работ в команде по трем дистанционно разнесенным центрам разработки. Задачи backend сложные, ресурсоемкие, выполняются пакетно. Они отделены от графического интерфейса продукта (frontend), который также непросто устроен. Frontend это пользовательский интерфейс: сложный, параметризуемый, с рядом встроенных пользовательских сервисов (в частности, браузер информации), а также настраиваемый. Обе этих подсистемы взаимодействуют друг с другом через хорошо определенный и детально описанный программный интерфейс: алгоритмы backend разбиты на методы, которые frontend может вызывать по особым правилам, с параметрами, выстраивая в цепочку для достижения своих задач. «Сбоку» от всего этого находятся дополнительные tools. Они интегрируются во frontend, но не пользуются методами backend, а реализуют свои задачи самостоятельно. Эти задачи не требуют сложной пакетной обработки, а нацелены на интерактивное взаимодействие с пользователем. При их реализации особенно много внимания уделялось usability. Каждая из трех подсистем требовала от разработчиков особых навыков. В случае backend это было умение и опыт по реализации такого рода пакетных алгоритмов, в случае с frontend умение создавать сложный пользовательский интерфейс, в случае с tools требовалось искусство в проектировании и реализации «легковесных» инструментов, предоставляющих пользователям системы дополнительные сервисные возможности. В том, чтобы разделить работы таким образом, был еще и ряд политических аспектов. В частности, руководство проекта хотело иметь процесс разработки пользовательского интерфейса рядом с собой, в одном из трех центров разработки, который совпадал со штаб-квартирой. Считалось, что внешний вид продукта очень важен для его успешной продажи и требует особенного внимания. В результате выполнения проекта (а он развивался более 15 лет, достигая в апогее до 150 человек, одновременно занятых в нем) такая четкая структура несколько сместилась так географически интерфейс почти «переехал» в тот центр, где разрабатывался backend. Но в целом такое сквозное разделение проекта на части оставалось много лет и было основным скелетом всей разработки. Это и есть пример архитектуры программного проекта. Определение Будем понимать под архитектурой ПО внутреннюю структуру продукта (компоненты и их связи), основы пользовательского интерфейса продукта, а также квинтесенцию знаний и решений, являющихся инструментом разработки и управления проектом. То есть архитектура это сквозная концепция или набор таковых для преодоления энтропии и хаоса, стремящихся «проглотить» разработку в виду сложности, нематериальности, согласовываемости и изменчивости ПО. При этом мы не разделяем продукт и проект, так как на практике это, как правило, одно целое, причем эта «сквозность», если она имеется, является «сильной» стороной данной разработки. Часто под архитектурой понимают например, только внутреннее устройство ПО, выраженное в UML-диаграммах. Вот шутка на тему того, что архитектуру нельзя понимать односторонне. Одного известного трансляторщика спросили, почему в его знаменитом трансляторе ровно 21 просмотр. Ожидали услышать перечисление про алгоритмических проблем, которые таким способом удалось преодолеть, что-то про 20

Часть 2. Понимание потребностей пользователей Приложение Г Принципы управления требованиями в стандартах SEI-CMM и ISO 9000 Принципы управления требованиями в стандарте SEI-CMM В ноябре 1986 года в Институте

ГОСТ Р ИСО/МЭК ТО 9294-93 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Информационная технология РУКОВОДСТВО ПО УПРАВЛЕНИЮ ДОКУМЕНТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ГОССТАНДАРТ РОССИИ Москва Предисловие

ГОСТ Р ИСО/МЭК ТО 9294-93 Группа Т55 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Информационная технология РУКОВОДСТВО ПО УПРАВЛЕНИЮ ДОКУМЕНТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Information technology.

Планирование Исполнение /Контроль и анализ Принятие решения Управление проектами Информационные технологии «1С:Предприятие» ТЕХНОЛОГИЯ КОРПОРАТИВНОГО ВНЕДРЕНИЯ: АКСИОМЫ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА И ОБЛАСТЬ

ГОСТ Р ИСО/МЭК ТО 9294-93 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Информационная технология РУКОВОДСТВО ПО УПРАВЛЕНИЮ ДОКУМЕНТИРОВАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Издание официальное ГОССТАНДАРТ РОССИИ

ОСНОВЫ СИСТЕМНОЙ ИНЖЕНЕРИИ ЛЕКЦИЯ 1. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМНОЙ ИНЖЕНЕРИИ 1.1. Возникновение системной инженерии Рост масштабов и усложнение способов организации деятельности по созданию систем, повышение

Название: «Управление качеством в процессах разработки программного обеспечения.» (Quality management in software development processes.)

Â.À. Êîïíîâ ÌÅÒÎÄÈ ÅÑÊÈÅ ÓÊÀÇÀÍÈß ISO 9001 Ñèñòåìû Ìåíåäæìåíòà Êà åñòâà Ñåìèíàð äëÿ âûñøåãî ðóêîâîäñòâà Ñåðèÿ ìåæäóíàðîäíûõ ñòàíäàðòîâ ISO9000 Ïðèíöèïû ìåíåäæìåíòà êà åñòâà òî òàêîå Ñèñòåìà Ìåíåäæìåíòà

Программное обеспечение Проектирование ПО Фаза проектирования ПО Жизненный цикл ПО Программный продукт Ицыксон В.М. ТРПО (С) 2011 2 Анализ и планирование Проектирование Реализация Тестирование Документирование

БАЛТИЙСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ «ВОЕНМЕХ» имени Д. Ф. Устинова Обзор стандарта ГОСТ Р ИСО/МЭК 12207-99.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Санкт-Петербургский государственный институт точной механики и оптики (технический университет) УТВЕРЖДАЮ Ректор СПбГИТМО(ТУ) В.Н.Васильев " " 200 г. РАБОЧАЯ

Логотип ISO Документ: ISO/TC 176/SC 2/N 544R3 Наш номер Секретариат ISO/TC 176/SC 2 Дата: 15 октября 2008 Пакет документов для внедрения и поддержки стандартов серии ISO 9000: Руководство по концепции

Коллективная деятельность в масштабе группы Продукт Rational Team Concert for Power существенно упрощает совместную деятельность, имеющую критически важное значение. Апрель 2010 г. Дон Яньцзи (Don Yantzi)

УДК 004.55 ОСОБЕННОСТИ УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В IT-КОМПАНИЯХ 2013 О.С. Кулакова* Ключевые слова: разработка программного обеспечения, управление разработкой программного обеспечения,

Scientific and Practical Results in 2014. Prospects for Their Development Толепберген С. О., к. э. н. Бермухамедова Г. Б. Казахстан, Актау, Казахский государственный университет технологии и инжиниринга

Мережні технології-2 Технології інтернет Лекция Методологии разработки ПО Штогрина Елена Сергеевна Методология Методология это система принципов, а также совокупность идей, понятий, методов, способов и

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

Фред Брукс и «Мифический человеко-месяц» Фредерик Филлипс Брукс Младший Родился 19 апреля 1931 в городе Дарем, Северная Каролина 1953 год окончил Университет Дьюка 1956 год получил титул Ph.D. по прикладной

УДК 338.24.01 РАЗРАБОТКА И ВНЕДРЕНИЕ ИНТЕГРИРОВАННОЙ СИСТЕМЫ МЕНЕДЖМЕНТА Т.А. Салимова, доктор экон. наук, профессор, зав. кафедрой управления качеством ГОУ ВПО «Мордовский государственный университет

Вводная лекция Цель лекции: 1. Показать значимость и актуальность информационных технологий в управлении организацией (предприятием) 2. Определить требования к изучению дисциплины. 3. Дать характеристику

SWorld 17-28 June 2014 http://www.sworld.com.ua/index.php/ru/conference/the-content-of-conferences/archives-of-individual-conferences/june-2014 MODERN PROBLEMS AND WAYS OF THEIR SOLUTION IN SCIENCE, TRANSPORT,

УДК 654-34 УПРАВЛЕНИЕ ИНВЕСТИЦИЯМИ В ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ НА ОСНОВЕ СТАНДАРТА ISO/IEC 15288 И МОДЕЛИ ЗРЕЛОСТИ ПРЕДПРИЯТИЯ Годунова Анастасия Олеговна, Студент 4 курса экономического факультета, e-mail:

ПЛАН ТЕСТИРОВАНИЯ КЛИЕНТ-СЕРВЕРНОЙ СИСТЕМЫ 1 ОГЛАВЛЕНИЕ 1. ВВЕДЕНИЕ... 3 1.1. Цели тестирования... 3 1.2. Стратегии тестирования... 3 1.3. Виды тестирования... 3 1.4. Документирование... 5 2. ЦИКЛ ТЕСТИРОВАНИЯ...

СЕКРЕТЫ УСПЕШНЫХ БАНКОВ Р.А. ИСАЕВ СЕКРЕТЫ УСПЕШНЫХ БАНКОВ: менеджмент качества и ISO 9000 ЭЛЕКТРОННАЯ КНИГА-ОРГАНАЙЗЕР Москва ИНФРА М 2012 УДК 650 ББК 65.290 И85 И85 Исаев Р.А. Секреты успешных банков:

Технология разработки программного обеспечения 2015-2016 гг. Лекции 3-4: гибкие технологии Пудов Сергей Григорьевич Составление ТЗ и плана работ Техническое задание (ТЗ) документ, содержащий набор требований

Вишняков Олег Леонидович, Директор по бизнес-консалтингу ООО «Логика бизнеса», Тулинцев Константин Геннадьевич, консультант ООО «Логика бизнеса» Процессный подход в управлении организацией Немного истории

Реализация качества разработки для платформы Atom/MeeGo В. И. Кияев 1 Лекция13 Реализация качества Важнейшей составной частью философии предпринимательства является философия качества, которая имеет острую

ISSN 2079-8490 Электронное научное издание «Ученые заметки ТОГУ» 2014, Том 5, 4, С. 20 24 Свидетельство Эл ФС 77-39676 от 05.05.2010 http://pnu.edu.ru/ru/ejournal/about/ [email protected] УДК 338.242.2

Ââåäåíèå В настоящее время в большинстве организаций различного профиля ощущается потребность в специалистах, которые профессионально владеют разнообразными современными информационными технологиями. При

Жеребина О.Г., [email protected] Фирма «1С», Москва Использование профессионального стандарта «Специалист по информационным системам» в высшем и среднем профессиональном образовании Проект разработки профессиональных

ГОСУДАРСТВЕННАЯ ТЕХНИЧЕСКАЯ КОМИССИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Руководящий документ СРЕДСТВА ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ. МЕЖСЕТЕВЫЕ ЭКРАНЫ. ЗАЩИТА ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ИНФОРМАЦИИ. ПОКАЗАТЕЛИ ЗАЩИЩЕННОСТИ

ЭЛЕКТРОННЫЙ НАУЧНЫЙ ЖУРНАЛ «APRIORI. CЕРИЯ: ЕСТЕСТВЕННЫЕ И ТЕХНИЧЕСКИЕ НАУКИ» 6 2015 УДК 004 АВТОМАТИЗАЦИЯ ОТДЕЛА ОХРАНЫ ТРУДА Баулин Станислав Сергеевич магистрант Мордовский государственный университет

НОУ ВПО Частное образовательное учреждение высшего образования «ЕССЕНТУКСКИЙ ИНСТИТУТ УПРАВЛЕНИЯ, БИЗНЕСА И ПРАВА» кафедра Высшей математики и информатики ЕИУБиП ЧОУ ВО ЕИУБП РАБОЧАЯ ПРОГРАММА ПО ДИСЦИПЛИНЕ

ОСВОИЛ САМ ПОМОГИ ДРУГИМ Марианна Матюкова, зам. директора по качеству, компания «Альтер Лого» Стабильно высокий успех может обеспечить четко функционирующая и результативная система менеджмента качества

1 2 3 4 5 6 7 80 9 0 Лекция 6 Элементы технологического слоя. Моделирование технологической архитектуры сервис интерфейс Артефакт функционал Узел Сеть 90 / 142 реализует Copyright Рубенчик А.В. 2016. Все

Тема 3 Фазы проекта и его жизненный путь. Развитие и оценка проекта Каждый проект независимо от его сложности, области применения или объемов работ, необходимых для его выполнения, проходит в своем развитии

УДК 002:658.516+658.562 П.В. СТРЕЛЬНИКОВ О СЕРТИФИКАЦИИ СИСТЕМ МЕНЕДЖМЕНТА КАЧЕСТВА Abstract: The basic stimulus for creation of quality management systems at the enterprises are created. Some advantages

ИСПОЛЬЗОВАНИЕ ЛОГИСТИЧЕСКОГО ПОДХОДА В ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ ПРИ СОЗДАНИИ ИННОВАЦИОННЫХ ПРОДУКТОВ Левкин Г.Г. к. вет. н., доцент кафедры экономика транспорта, логистика и управление качеством, Омский

ВВЕДЕНИЕ Данное пособие составлено в соответствии с требованиями Государственного образовательного стандарта специальности «Прикладная информатика в экономике» и отражает следующие разделы дисциплины «Разработка

Руководящий документ Средства вычислительной техники. Межсетевые экраны Защита от несанкционированного доступа к информации Показатели защищенности от несанкционированного доступа к информации Утверждено

Система управления эффективностью деятельности Развитие технологий, изменения рыночной конъюнктуры и усиление конкуренции ставит перед предприятиями и организациями задачи повышения эффективности управления,

BUSINESS ASSURANCE ISO 9001:2015 обзор ключевых изменений 2016-02-22 1 SAFER, SMARTER, GREENER Содержание Основные направления эволюции стандарта ISO 9001 Унифицированная структура верхнего уровня Гармонизация

Система менеджмента качества компании Fastwel: опыт внедрения и сертификации Алексей Маклаков Разработка и внедрение системы менеджмента качества на предприятии задача сложная и для каждого отдельного

Интеграция и внешних систем «Управляем предприятием» 12 (47), 2014 ИТ-инфраструктура Михаил Киреев Руководитель отдела разработки департамента 1С ГК «КОРУС Консалтинг». Руководил проектами разработки и

СИБИРСКИЙ УНИВЕРСИТЕТ ПОТРЕБИТЕЛЬСКОЙ КООПЕРАЦИИ ПРОГРАММА ВСТУПИТЕЛЬНЫХ ИСПЫТАНИЙ ПО НАПРАВЛЕНИЮ 230700.62 Прикладная информатика Новосибирск ВВЕДЕНИЕ Программа вступительных испытаний по направлению

СИСТЕМА ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА СХЕМА ДИСТРИБЬЮЦИИ И ПРОИЗВОДСТВЕННЫЙ ЦИКЛ Листов 9 2016 СОДЕРЖАНИЕ 1. ТЕРМИНЫ, СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ... 3 2. ВВЕДЕНИЕ... 4 2.1. Назначение документа... 4 2.2.

АЮСооляттэ Модели офисов управления проектами, программами, портфелями проектов Данный материал является выдержкой из книги Андрея Сооляттэ «Управление проектами в компании: методология, технологии, практика»

Документирование на этапах проектирования ИС 1 Этап 1. Системный анализ проекта ПС 1.1. Исследования и определение концепции версии ПС Результаты обследования и описание объекта и целей его информатизации

38 Вестник РЭА 2007 6 К. М. Марченкова ЗАДАЧИ И ФУНКЦИИ ФИНАНСОВОГО КОНТРОЛЛИНГА Изложена концепция финансового контроллинга как эффективного инструмента управления корпоративными финансами. Актуальность

Табельный учет (Russian Time Management) Модуль Табель предназначен для планирования и учета использования рабочего времени сотрудников предприятия. Модуль Табель интегрирован в приложение Oracle HRMS.

Тема работы: «ИНФОРМАЦИОННЫЕ АСПЕКТЫ СИСТЕМНОГО АНАЛИЗА В СОЗДАНИИ СИСТЕМ УПРАВЛЕНИЯ АВТОТРАНСПОРТНЫМ ПРЕДПРИЯТИЕМ» Тема реферата: «СИСТЕМА УПРАВЛЕНИЯ АВТОТРАНСПОРТНЫМ ПРЕДПРИЯТИЕМ» Выполнил студент(ка)

Принципы и проблемы разработки сложных программных систем Кафедра дискретной математики и информационных технологий Синельников Евгений Александрович [email protected] 12 Сентябрь, 2011 TIOBE Programming

Будущее серии стандартов ISO 9000 Иван Чайка, президент Международной Гильдии профессионалов качества, к.э.н., академик Академии проблем качества Стандарты серии ISO сегодня применяют более миллиона предприятий,

МЕНЕДЖМЕНТ И МАРКЕТИНГ Социальная ответственность бизнеса как элемент корпоративного управления Л.НУГУМАНОВА Сущность и принципы корпоративного управления. Сегодня во многих странах мира, в том числе в

Руководящий документ Средства вычислительной техники Защита от несанкционированного доступа к информации Показатели защищенности от несанкционированного доступа к информации Утверждено решением председателя

Министерство образования Республики Беларусь Учреждение образования «Белорусский государственный университет информатики и радиоэлектроники» В. В. Бахтизин, Л. А. Глухова Технология разработки программного

Альперин М.И., Самсонова Э.Р., Решетников Р.С. Alperin M.I., Samsonova E.R., Reshetnikov R.S. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ОБУЧЕНИЯ В МАЛЫХ ГРУППАХ SOFTWARE FOR TRAINING IN SMALL GROUPS [email protected]

НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. ВИДЫ И КРИТИЧНОСТЬ ОШИБОК. Дроботун Е. Б. Военная академия воздушно космической обороны, г.тверь [email protected] В работе рассматриваются качество и надежность программного

Технологии, модели и процессы создания ПО

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

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

Инженерия ПО – инженерная дисциплина, охватывающая все аспекты разработки ПО.

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

Процесс создания ПО – совокупность процессов, приводящих к созданию программного продукта. Фундаментальные процессы, присущие любому проекту создания ПО:

- Разработка спецификации требований на ПО (Определяют функциональные характеристики системы и обязательны для выполнения).

- Создание программного обеспечения (создание ПО согласно спецификации).

- Аттестация ПО (Созданное ПО должно пройти аттестацию для подтверждения соответствию требованиям заказчика).

- Модернизация ПО (совершенствование ПО согласно измененным требованиям потребителя).

Модель процесса создания ПО – последовательность этапов, необходимых для разработки создаваемого ПО.

Рис. 1 – Распределения затрат при разработке ПО

Модели процесса разработки ПО:

1. Каскадная модель

2. Эволюционная модель

3. Формальное преобразование

4. Сборка программных продуктов из ранее созданных компонентов (модель сборки)

5. Итерационная (спиральная) модель

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

Все методы основаны на использовании моделей системы в качестве спецификации ее структуры:

1. Функционально-ориентированные (структурный анализ, JSD, 70-е годы) основаны на определении основных функциональных компонент системы.

2. Объектно-ориентированные (Booch, Rumbaugh) используют подходы, основанные на использовании унифицированного языка моделирования UML.

Computer-Aided Software Engineering– автоматизированная разработка ПО.

Процессы создания ПО Базовые процессы создания ПО:

Разработка спецификации. Проектирование и реализация. Аттестация.

Эволюция.

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

Разработка требований к ПО

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

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

- анализ технической осуществимости создания системы,

- формирование и анализ требований,

- специфицирование требований и создание соответствующей документации,

- аттестация этих требований.

Рис. 13 – Процесс формирования требований

Анализ осуществимости должен осветить следующие вопросы:

1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?

2. Можно ли реализовать систему, используя существующие на данный момент техно¬логии и не выходя за пределы заданной стоимости?

3. Можно ли объдинить систему с другими системами, которые уже эксплуатируются?

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

1. Что произойдет с организацией, если система не будет введена в эксплуатацию?

2. Какие текущие проблемы существуют в организации и как новая система поможет их решить?

3. Каким образом система будет способствовать целям бизнеса?

4. Требует ли разработка системы технологии, которая до этого не использовалась в организации?

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

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

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

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

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

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

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

Рис. 14 – Процесс формирования и анализа требований

Процесс формирования и анализа требований проходит через ряд этапов:

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

Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.

Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требовании.

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

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

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

Метод опорных точек зрения

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

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

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

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

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

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

Этот тип точек зрения имеет ряд преимуществ:

Точки зрения, внешние к системе, - естественный способ структурирования процесса формирования требований.

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

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

Этнографический подход

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

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

Рис. 20 – Процесс разработки требований согласно этнографическому подходу

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

1. Проверка правильности требований.

2. Проверка на непротиворечивость.

3. Проверка на полноту.

4. Проверка на выполнимость.

Существует ряд методов аттестации требований:

1. Обзор требований.

2. Прототипирование.

3. Генерация тестовых сценариев.

4. Автоматизированный анализ непротиворечивости.

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

С точки зрения разработки требования можно разделить на два класса:

1. Постоянные требования.

2. Изменяемые требования.

Планирование управления требованиями

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

2. Управление процессом внесения изменений.

3. Стратегия оперативного контроля.

- Информация об источнике требования

- Информация о требованиях

- Информация о структуре системы

4. Поддержка CASE-средств.

Процесс управления изменениями состоит из трех основных этапов:

1. Анализ проблем изменения спецификации.

2. Анализ изменений и расчет их стоимости.

3. Реализация изменений.

Определение								Пересмотренные
проблем в
								требования
требованиях
	Анализ проблем			изменений и			Реализация
	изменение спецификации			расчет их			изменений
				стоимости

Рис. 21 – Процесс управления требованиями

Вопросы для обсуждения

1. Предложите, кто бы мог участвовать в формировании требований для университетской системы регистрации студентов.

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

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

Формальные спецификации

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

Термин "формальные методы" подразумевает ряд операций, в состав которых входят создание формальной спецификации системы, анализ и доказательство спецификации, реализация системы на основе преобразования формальной спецификации в программы и верификация программ. Все эти действия зависят от формальной спецификации программного обеспечения. Формальная спецификация - это системная спецификация, записанная на языке, словарь, синтаксис и семантика которого определены формально. Необходимость формального определения языка предполагает, что этот язык основывается на математических концепциях. Здесь используется область математики, которая называется дискретной математикой и основывается на алгебре, теории множеств и алгебре логики.

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

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

Рис. 22 – Процесс разработки формальной спецификации

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

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

1. Алгебраический подход, при котором система описывается в терминах операций и их отношений.

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

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

Таблица 2 - Языки разработки формальных спецификаций

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

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

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

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

Структура спецификации объекта состоит из четырех компонентов:

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

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

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

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

Рис. 23 - Структура алгебраической спецификации

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

1. Структурирование спецификации. Представление неформальной спецификации интерфейса в виде множества абстрактных типов данных или объектных классов. Также неформально определяются операции, ассоциированные с каждым классом.

2. Именование спецификаций. Задаются имена для каждой спецификации абстрактного типа, определяются параметры спецификаций (если они необходимы) и имена определяемых классов.

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

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

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

6. Определение аксиом. Определение семантики операций путем описания условий, которые должны

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

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

1. Операции конструирования, которые создают или изменяют объекты класса. Обычно их называют Create (Создать), Update (Изменить), Add (Добавить) или Cons (Конструирование).

2. Операции проверки, которые возвращают атрибуты класса. Обычно им дают имена, соответствующие именам атрибута, или имена, подобные Eval (Значение), Get (Получить) и т.п.

Хорошим эмпирическим правилом для написания алгебраической спецификации является создание аксиом для каждой операции конструирования с применением всех операций проверки. Это означает, что если есть m операций конструирования и n операций проверки, то должно быть определено m x n аксиом.

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

В спецификации списка операциями конструирования являются Create, Cons и Tail, которые создают списки. Операциями проверки являются Head и Length, которые используются для получения значений атрибутов списка. Операция Tail не является примитивной конструкцией, поэтому для нее можно не определять аксиомы с использованием операций Head и Length, но в таком случае Tail необходимо определить посредством примитивных конструкций.

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

Иногда проще понять рекурсивные преобразования, используя короткий пример. Предположим, что есть список , где элемент 5 - начало (вершина) списка, а элемент 7- конец списка. Операция Cons(, 9) должна возвратить список , а операция Tail, примененная к этому списку, должна возвратить список . Приведем последовательность рекурсивных преобразований, приводящую к этому результату.

Tail () =

Tail (Cons (, 9)) =

Cons (Tail (), 9) =

Cons (Tail (Cons (, 7)), 9) =

Cons (Cons (Tail (), 7), 9) =

= Cons (Cons (Tail (Cons (, 5)), 7), 9) =

= Cons (Cons (, 7), 9) =

Cons (, 9) =

Здесь систематически использовались аксиомы для Tail, что привело к ожидаемому результату. Аксиому для операции Head можно проверить подобным способом.

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

Более того, я думаю, что алгебраические описания поведения систем часто искусственны и трудны для понимания.

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

Вопросы для обсуждения

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

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

3. Абстрактный тип данных, представляющий стек, имеет следующие операции:

a. New (Создать) - создает пустой стек;

b. Push (Добавить) - добавляет элемент в вершину стека;

c. Тор (Вершина) - возвращает элемент на вершине стека;

d. Retract (Удалить) - удаляет элемент из вершины стека и возвращает модифицированный стек;

e. Empty (Пустой) - возвращает значение истины, если стек пустой.

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

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

Модели систем

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

Модели могут представить систему в различных аспектах:

Внешнее представление, когда моделируется окружение или рабочая среда системы. Описание поведения системы, когда моделируется ее поведение.

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

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

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

Модель обработки данных. Диаграммы потоков данных показывают последовательность обработки данных в системе.

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

Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система. Классификационная модель. Диаграммы наследования классов показывают, какие объекты имеют общие характеристики.

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

Модели системного окружения

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

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

Рис. 24 – Пример модели окружения

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

Рис. 25 - Модель процесса приобретения оборудования

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

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

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

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

Рис. 26 – Модель потоков данных

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

Рис. 27 - Диаграмма потоков данных комплекса CASE-средств

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

Модели конечных автоматов являются неотъемлемой частью методов проектирования систем реального времени. Такие модели определяются диаграммами состояний , которые стали основой системы нотаций в языке моделирования UML.

• Размер: 821 Кб
• Количество слайдов: 61

Описание презентации Введение в программную инженерию ПОНЯТИЕ ПРОГРАММНОЙ ИНЖЕНЕРИИ по слайдам

ПОНЯТИЕ ПРОГРАММНОЙ ИНЖЕНЕРИИ Чем программирование отличается от программой инженерии? Программирование является некоторой абстрактной деятельностью и может происходить во многих различных контекстах. Промышленное программирование, как правило, происходит в команде, и совершенно точно – для заказчика, который платит за работу деньги. Необходимо точно понимать, что нужно заказчику, выполнить работу в определенные сроки и результат должен быть нужного качества –того, которое удовлетворит заказчика и за которое он заплатит. Чтобы удовлетворить этим дополнительным требованиям, программирование «обрастает» различными дополнительными видами деятельности: разработкой требований, планированием, тестированием, конфигурационным управлением, проектным менеджментом, созданием различной документации (проектной, пользовательской и пр.).

Разработка программного кода предваряется анализом и проектированием (первое означает создание функциональной модели будущей системы без учета реализации, для осознания программистами требований и ожиданий заказчика; второе означает предварительный макет, эскиз, план системы на бумаге). Требуются специальные усилия по организации процесса разработки. Разработку системы необходимо выполнять с учетом удобств u ее дальнейшего сопровождения, повторного использования и интеграции с другими системами. Это значит, что система разбивается на компоненты, удобные в разработке, годные для повторного использования и интеграции Для этих компонент тщательно прорабатываются интерфейсы. Сама же система документируется на многих уровнях, создаются правила оформления программного кода – то есть оставляются многочисленные семантические следы, помогающие создать и сохранить, поддерживать единую, стройную архитектуру, единообразный стиль, порядок… Все эти и другие дополнительные виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов и будем называть программной инженерией (software engineering)

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

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

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

Продолжение кризиса программирования Несмотря на то, что программная инженерия достигла определенных успехов, перманентный кризис программирования продолжается. Связано это с тем, что рубеж 80– 90 -х годов отмечается как начало информационно- технологической революции, вызванной взрывным ростом использования информационных средств: персональный компьютер, локальные и глобальные вычислительные сети, мобильная связь, электронная почту, Internet и т. д. Цена успеха – кризис программирования принимает хронические формы. Standish Group, проанализировав работу сотен американских корпораций и итоги выполнения нескольких десятков тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» пришла к следующим выводам: – Только 35 % проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности. – 46 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме. Среднее превышение сроков составило 120%, среднее превышение затрат 100%, обычно исключалось значительное число функций.

19 % проектов полностью провалились и были аннулированы до завершения. Результаты анализа успешности программных проектов за 2006 год

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

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

Процесс разработки ПО - совокупность процессов, обеспечивающих создание и развитие программного обеспечения. Модель процесса разработки ПО - формализованное представление процесса разработки ПО. Часто при описании процессов вместо слова модель употребляется термин методология. На сегодняшний день нет единого определения понятия «программная инженерия» . Ниже приведено несколько таких Определения, данные крупными специалистами в этой области, или зафиксированные в документах ведущих организаций: – установление и использование обоснованных инженерных принципов (методов) для экономного получения ПО, которое надежно и работает на реальных машинах. ; – та форма инженерии, которая применяет принципы информатики (computer science) и математики для рентабельного решения проблем ПО. – применение систематического, дисциплинированного, измеряемого подхода к разработке, использованию и сопровождению ПО . – дисциплина, целью которой является создание качественного ПО, которое завершается вовремя, не превышает выделенных бюджетных средств и удовлетворяет выдвигаемым требованиям .

Хронология развития программной инженерии 1958 г. — всемирно известный статистик Джон Тьюкей (John Tukey) впервые ввел термин software – программное обеспечение. 1968 г. — Термин software engineering (программная инженерия) впервые появился в названии конференции НАТО, состоявшейся в Германии посвященной так называемому кризису программного обеспечения. 1970 г. — У. У. Ройс (W. W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению стоимости разработки. Была предложена концепция жизненного цикла (SLC – Software Lifetime Cycle). 1990 — 1995 г. — велась работа над международным стандартом, который должен был дать единое представление о процессах разработки программного обеспечения. В результате был выпущен стандарт ISO/IEC 12207 ―Software Lifecycle Processes. – Соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207 -99 [ГОСТ 12207, 1999] содержит полный аутентичный перевод текста международного стандарта ISO/IEC 12207 —

1. Guide to the Software Engineering Body of Knowledge (SWEе. K), IEEE 2004 Version — Руководство к Своду Знаний по Программной Инженерии, в дальнейшем просто ― SWEе. K; Одной из важнейших целей SWEе. K является именно определение тех аспектов деятельности, которые составляют суть профессии инженера-программиста. 2. Software Engineering 2004. – Учебный План для Преподавания Программной Инженерии в ВУЗах [ SE, 2004]. 2004 г — ACM/IEEE-CS сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии – Software Engineering:

Структура и содержание SWEBOK Согласно SWEBOK 2004, программная инженерия включает в себя 10 основных и 7 дополнительных областей знаний, на которых базируются процессы разработки ПО. К основным областям знаний относятся следующие области: Software requirements - программные требования. Software design - дизайн (архитектура). Software construction - конструирование программного обеспечения. Software testing - тестирование. Software maintenance - эксплуатация (поддержка) программного обеспечения. Software configuration management - конфигурационное управление. Software engineering management - управление в программной инженерии. Software engineering process - процессы программной инженерии. Software engineering tools and methods - инструменты и методы. Software quality - качество программного обеспечения. Описание областей знаний в SWEе. K построено по иерархическому принципу, как результат структурной декомпозиции.

Связанные дисциплины Дополнительные области знаний включают в себя: Computer engineering - разработка компьютеров. Computer science - информатика. Management - общий менеджмент. Mathematics - математика. Project management - управление проектами. Quality management - управление качеством. Systems engineering - системное проектирование.

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

Системотехника (system engineering) объединяет различные инженерные дисциплины по разработке всевозможных искусственных систем – энергоустановок, телекоммуникационных систем, встроенных систем реального времени и т. д. Очень часто ПО оказывается частью таких систем, выполняя задачу управления соответствующего оборудования. Такие системы называются программно-аппаратными, и участвуя в их создании, програм -мисты вынуждены глубоко разбираться в особенностях соответствующей аппаратуры. Бизнес-реинжиниринг (business reengineering) – в широком смысле обозначает модернизацию бизнеса в определенной компании, внедрение новых практик, поддерживаемых соответствующими, новыми информаци -онными системами. При этом акцент может быть как на внутреннем переустройстве компании так и на разработке нового клиентского сервиса (как правило, эти вопросы взаимосвязаны). Бизнес-реинжиниринг часто предва- ряет разработку и внедрение информационных систем на предприятии, так как требуется сначала навести определенный порядок в делопроизводстве, а лишь потом закрепить его информационной системой.

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОДУКТА Методологическую основу любой инженерии составляет понятие жизненного цикла (ЖЦ) изделия (продукта) как совокупности всех действий, которые надо выполнить на протяжении всей «жизни» изделия. Смысл жизненного цикла состоит во взаимосвязанности всех этих действий. Жизненный цикл промышленного изделия определяется как последователь- ность этапов (фаз, стадий), состоящих из технологических процессов, действий и операци Организация промышленного производства с позиции жизненного цикла позволяет рассматривать все его этапы во взаимосвязи, что ведет к сокраще- нию сроков, стоимости и трудозатрат. Разделение понятий ЖЦ ПО и модели ЖЦ ПО. – ЖЦ ПО — полная совокупность всех процессов и действий по созданию и применению ПО; – модель ЖЦ – конкретный вариант организации ЖЦ, обоснованно (разумно) выбранный для каждого конкретного случая.

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

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

Содержание основных этапов. Системный анализ — задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. На этом этапе начинается решение задачи планирования проекта ПО. Определяются: – объем проектных работ; – риск; – необходимые трудозатраты; – формируются рабочие задачи; – план-график работ. Анализ требований — относится к программному элементу - программному обеспечению. Уточняются и детализируются – Функции; – Характеристики; – Интерфейс. Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений: – архитектуры ПО; – модульной структуры ПО; – алгоритмической структуры ПО; – структуры данных; – входного и выходного интерфейса (входных и выходных форм данных). Исходные данные для проектирования содержатся в спецификации анализа. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта. Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Тестирование - выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Сопровождение - это внесение изменений в эксплуатируемое ПО. Цели изменений: – исправление ошибок; – адаптация к изменениям внешней для ПО среды; – усовершенствование ПО по требованиям заказчика.

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

Макетирование Проблемы Заказчик — не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. Разработчик может сомневаться: – в приспосабливаемости продукта под операционную систему; – форме диалога с пользователем; – в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование. Основная цель макетирования - снять неопределенности в требованиях заказчика. Макетирование (прототипирование) - это процесс создания модели требуемого программного продукта. Модель может принимать одну из трех форм: 1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); 2) работающий макет (выполняет некоторую часть требуемых функций); 3) существующая программа (характеристики которой затем должны быть улучшены).

Сбор и уточнение требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавлива -ют, какие требования известны, а какие предстоит доопределить. Быстрое проектирование. Внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построе- нию макета. Макетирование. Оценивается макета заказчиком — используется для уточнения требований к ПО. Уточнение макета. Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано. Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования: заказчик может принять макет за продукт; разработчик может принять макет за продукт.

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

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

Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE / EIA 12207. 2 Стратегия конструирован ия В начале процесса определены все требования? Множество циклов конструирова- ния? Промежуточ ное ПО распространя- ется? Однократный проход Инкрементная (запланированн ое улучшение продукта) Эволюционная Да Да Нет Может быть Да

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

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Пример. ПО для обработки слов в 1 -м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2 -м инкременте - более сложные возможности редактирования и документирования; в 3 -м инкременте - проверку орфографии и грамматики; в 4 -м инкременте - возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт. Современная реализация инкрементного подхода - экстремальное програм- мирование ХР. (Кент Бек, 1999)

Быстрая разработка приложений Модель быстрой разработки приложений (Rapid Application Development) - второй пример применения инкрементной стратегии конструирования

RAD -модель обеспечивает экстремально короткий цикл разработки. RAD - высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD -процесс позволяет группе создать полностью функциональную систему за очень короткое время (60 -90 дней). RAD -подход ориентирован на разработку информационных систем и выделяет следующие этапы: – бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее? – моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;

– моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных; – генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4 -го поколения. Вместо создания ПО с помощью языков программирования 3 -го поколения, RAD -процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации; – тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы). Применение RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему.

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

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

Спиральная модель: 1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; 6 - начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком. Модель определяет четыре действия, представляемые четырьмя квадрантами спирали. 1. Планирование - определение целей, вариантов и ограничений. 2. Анализ риска - анализ вариантов и распознавание/выбор риска. 3. Конструирование - разработка продукта следующего уровня. 4. Оценивание - оценка заказчиком текущих результатов конструирования.

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

Достоинства спиральной модели: 1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения; 2) позволяет явно учитывать риск на каждом витке эволюции разработки; 3) включает шаг системного подхода в итерационную структуру разработки; 4) использует моделирование для уменьшения риска и совершенствования программного изделия. Недостатки спиральной модели: 1) новизна (отсутствует достаточная статистика эффективности модели); 2) повышенные требования к заказчику; 3) трудности контроля и управления временем разработки.

Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В модели конкретизируется содержание квадранта конструирования - оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов. – Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. – В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. – Далее проверяется наличие этих кандидатов в библиотеке. – Если кандидаты найдены, то компоненты извлекаются из библиотеки и используются повторно. – В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку. Достоинства компонентно-ориентированной модели: 1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки.

Тяжеловесные и облегченные процессы В XXI веке потребности общества в программном обеспечении информационных технологий достигли экстремальных значений. Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные (heavyweight) процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими (predictive) процессами. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг и человеческие слабости в расчет не принимался, а объем необходимой документации был очень велик. В последние годы появилась группа новых, облегченных (lightweight) процессов, которые теперь называют подвижными (agile) процессами. Они привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов и воплощают в жизнь разумный компромисс между слишком строгой дисциплиной и полным ее отсутствием.

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

ХР-процесс Экстремальное программирование (e. Xtreme Programming , XP) - облегченный (подвижный) процесс (или методология), (Кент Бек, 1999). ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении. Основная идея ХР - устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных. ХР-процесс должен быть высокодинамичным процессом. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем.

Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. В ХР эти принципы достигают «экстремальных значений» . Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. В ХР эти принципы достигают «экстремальных значений» . Рассмотрим структуру «идеального» ХР-процесса. Основным структурным элементом процесса является ХР-реализация, в которую многократно вкладывается базовый элемент - ХР-итерация. В состав ХР-реализации и ХР-итерации входят три фазы - – исследование, – блокировка, – регулирование.

Исследование (exploration) - это поиск новых требований (историй, задач), которые должна выполнять система. Блокировка (commitment) - выбор для реализации конкретного подмножества из всех возможных требований (иными словами, планирование). Регулирование (steering) - проведение разработки, воплощение плана в жизнь. ХР рекомендует: – первая реализация должна иметь длительность 2 -6 месяцев – продолжительность остальных реализаций - около двух месяцев – каждая итерация длится приблизительно две недели, – численность группы разработчиков не превышает 10 человек. Пример ХР-процесса для проекта с семью реализациями, осуществляемый за 15 месяцев – Процесс инициируется начальной исследовательской фазой. – Фаза исследования, с которой начинается любая реализация и итерация, имеет клапан «пропуска» , на этой фазе принимается решение о целесообразности дальнейшего продолжения работы. – Предполагается: длительность первой реализации составляет 3 месяца, длительность второй - седьмой реализаций - 2 месяца.

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

Модели качества процессов конструирования В условиях жесткой конкуренции, очень важно гарантировать высокое качество процесса конструирования ПО. Гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетными являются модели стандартов: – ISO 9001: 2000; – ISO / IEC 15504 ; – Модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон. Модель стандарта ISO 9001: 2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO / IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Базовым понятием модели СММ считается зрелость компании – Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

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

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

Уровень 4 (Управляемый). С переходом на управляемый уровень в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса. Уровень 5 (Оптимизирующий). Высший уровень подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффек- тивности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется. Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Пример, ОКП 5 -го уровня образуют процессы: – предотвращения дефектов; – управления изменениями технологии; – управления изменениями процесса. Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ

Управление проектами. Определения и концепции Управление проектами, лишь одна из 17 областей знаний программной инженерии, и то вспомогательная. Однако основной причиной большинства провалов программных проектов является именно применение неадекватных методов управления разработкой. Проект – это комплекс усилий, предпринимаемых с целью получения конкретных уникальных результатов в рамках отведенного времени и в пределах утвержденного бюджета, который выделяется на оплату ресурсов, используемых или потребляемых в ходе проекта. [Арчибальд Р. ]. Проект, есть комплекс действий, направленных на получение уникального результата, будь то продукт или услуга. Цель проекта описывает какие задачи должны быть решены в результате проекта. Содержание проекта — что именно является результатом проекта. Для информационной системы – ее функциональность. Управление проектом определяет “как”, с помощью каких действий, будет достигнута цель проекта и создан необходимый результат. При этом, управление проектами может и должно применяться на всех этапах жизненного цикла проекта, т. е. управление проектом есть постоянная деятельность.

В силу масштабности содержания проекта либо, например, разнородности его составных частей (например, программно-аппаратный комплекс шифрования данных) проект может быть разбит на несколько более мелких проектов. Так как с любым проектом ассоциированы цели, ресурсы, время, мы можем сформулировать, что управление проектами – есть дисциплина применения методов, практик и опыта к проектной деятельности для достижения целей проектов, при условии удовлетворения ограничений, определяющих их рамки. Ограничения (constraints) в проектах. Чаще всего говорят о трех основных ограничениях или “железном треугольнике” 1. Содержании проекта 2. Времени 3. Стоимости

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

В приложении к индустрии программного обеспечения обычно добавляют четвертое ограничение – качество (quality), приемлемое качество. В зависимости от контекста и обсуждаемых в конкретном случае критериев качества, “приемлемое” качество может рассматриваться как необходимое, например, заданное требованиями качества и внутрикорпоративными стандартами.

Введение в программную инженерию

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

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

Инженерия программного обеспечения – сравнительно молодая научная дисциплина. Термин software engineering был впервые предложен в 1968 году на конференции, посвященной так называемому кризису программного обеспечения. Этот кризис был вызван появлением мощной (по меркам того времени) вычислительной техники третьего поколения. Новая техника позволяла воплотить в жизнь не реализуемые ранее программные приложения. В результате программное обеспечение достигло размеров и уровня сложности, намного превышающих аналогичные показатели у программных систем, реализованных на вычислительной технике предыдущих поколений.

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

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

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

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

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

Вопросы и ответы об инженерии программного обеспечения

Этот раздел построен в виде ответов на некоторые основные вопросы, касающиеся инженерии программного обеспечения. В данном разделе используется формат "списка FAQ" (Frequently Asked Questions – часто задаваемые вопросы). Такой формат обычно применяется в группах новостей Internet, предлагая новичкам ответы на часто задаваемые вопросы. Надеюсь, что подобный подход будет эффективен в качестве краткого введения в предмет инженерии программного обеспечения.

Вопросы и ответы, подробно рассматриваемые в этом разделе, компактно представлены в табл. 1.1.

Таблица 1.1. Часто задаваемые вопросы об инженерии программного обеспечения

Главная > Документ

Введение в программную инженерию

1. Программная инженерия: назначение, основные принципы и понятия

1.1Предпосылки и история

В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.

С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. На слайде представлены ряд фундаментальных проблем разработки программ и найденных фундаментальных методов их решения. Эти методы и по сей день составляют основу подходов к проектированию программных продуктов.

1. Повторное использование кода (модульное программирование)

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

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

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

1. Рост сложности программ (структурное программирование)

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

Большой объем кода (миллионы строк)

Большое количество связей между элементами кода

Большое количество разработчиков (сотни человек)

Большое количество пользователей (сотни и тысячи)

Длительное время использования

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

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

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

Применение специальных языков проектирования и средств автоматизации использования этих языков

Дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствие кода проектной документации

Структурное кодирование без goto

1. Модификация программ (ООП)

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

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

Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки).

Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов

Полиморфизм – определение свойств и методов объекта по контексту

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

В отделе 3 частично изменились правила начисления зарплаты. В этой ситуации при объектно-ориентированном подходе из класса «Зарплата» выводится класс «Зарплата 1», который наследует неизменившиеся правила начисления зарплаты и переопределяет изменившиеся. Здесь при расчете зарплаты объектам «Отдел 1» и «Отдел 2» будет передаваться объект «Зарплата», а объекту «Отдел 3» - объект «Зарплата 1». При таких изменениях:

Срабатывает принцип наследования: код «Зарплата», «Отдел 1» и «Отдел 2» остаются без изменения, а код «Зарплата 1» изменяется ровно настолько, насколько это необходимо.

Срабатывает принцип полиморфизма: код «Отдел 3» также не изменяется – он продолжает считать, что работает с объектом «Зарплата»

1. Некоторые итоги

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

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

1. Продолжение кризиса программирования

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

Цена успеха – кризис программирования принимает хронические формы:

США тратит ежегодно более $200 млрд. на более чем 170 тыс. проектов разработки ПО в сфере IT; 31,1% из них закрываются, так и не завершившись; 52,7% проектов завершаются с превышением первоначальных оценок бюджета/сроков и ограниченной функциональностью; потери от недополученного эффекта внедрения ПО измеряются триллионами.

Статистика по 30,000 проектам по разработке ПО в американских компаниях показывает следующее распределение между:

У спешными – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ

Проблемными – нарушение сроков, перерасход бюджета и/или сделали не все, что требовалось

Проваленными – не были доведены до конца из-за перерасхода средств, бюджета, качества.

Источник: The Standish Group International The Standish Group International, Inc., Extreme Chaos, 2000 - //sample_research/PDFpages/extreme_chaos.pdf

1.2Программная инженерия – что это такое?

1. Начнем с определений

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

Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г.Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем.

Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. Вокруг этой концепции было много споров. В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению стоимости разработки.

1. Разберемся в вопросах

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

Что такое программное обеспечение (software)? Что такое программная инженерия? В чем разница между программной инженерией (software engineering) и информатикой (computer science)? В чем разница между программной инженерией и системной инженерией (systems engineering)? В чем отличие программной инженерии от других инженерий?

1. Что такое программное обеспечение (software)?

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

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

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

1. Что такое программная инженерия?

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

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

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

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

Для решения задачи инженеры применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. В этом случае инженер ищет метод или средство для решения задачи, применяет его и несет ответственность за результат – ведь метод или средство еще не проверены. Набор таких инженерных методов или способов, теоретически возможно не обоснованных, но получивших неоднократное подтверждение на практике, играет большую практическую роль. В программной инженерии они получили название лучших практик (best practices).

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

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

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

1. В чем отличия от информатики?

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

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

1. В чем отличие от других инженерий?

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

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

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

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

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

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

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

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

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

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

1. В чем еще отличие от других инженерий?

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

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

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

Подробнее о проблемах проектирования ПО можно посмотреть в неоднозначной статье Кони Бюрера «От ремесла к науке: поиск основных принципов разработки ПО» /fset.asp?Url=/rational/science.htm

1. Из чего складывается стоимость ПО?

Структура стоимости ПО существенно зависит от типа ПО, применяемых методов его разработки и … метода оценки. Так, многие авторы отмечают высокую долю стоимости этапа сопровождения. Для некоторых типов ПО она может составлять 60 и более процентов от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требованиям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения на стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изменений – к новому проекту.

Типовое распределение стоимости между основными этапами (без сопровождения) выглядит следующим образом:

15% - спецификация – формулировка требований и условий разработки

25% - проектирование – разработка и верификация проекта

20% - разработка – кодирование и тестирование компонент

40% - интеграция и тестирование – объединение и сборочное тестирование продукта

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

Для коробочного ПО характерна более высокая доля тестирования за счет сокращения прежде всего доли спецификации (до 5%)

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

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

1. Еще вопросы

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

Что такое программный процесс?

Что такое модель программного процесса?

Что такое методы программной инженерии?

Что такое CASE (Computer-Aided Software Engineering)?

Какими свойствами обладает хорошая программа?

Какие основные трудности стоят перед программной инженерией?

1. Программный процесс?

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

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

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

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

Разработка проекта программы (результат – описание того, как программа будет работать)

Кодирование (результат – исходный код и файлы конфигурации)

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

Документирование (результат – документация к программе)

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

Процесс должен быть установлен. Полное установление процесса предполагает:

Описание процесса – детальное описание действий и операций процесса Обучение процессу – проведение занятий с персоналом по освоению процесса Введение метрик – установление количественных показателей хода выполнения Контроль выполнения – измерение метрических показателей и оценка хода выполнения Усовершенствование – изменение процесса при меняющихся условиях применения

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