лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки
 Скачать 4.41 Mb.
|
СОДЕРЖАНИЕ
ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные понятия прогроммной инженерии Современное человеческое общество все больше и больше зависит от компьютерных систем, управляемых программным обеспечением (ПО). Эти системы весьма настойчиво проникают во все сферы человеческой жизни. Они буквально окружают человека и на работе, и дома, и на отдыхе. Известно, что аппаратура современных компьютерных систем очень сложна, п вместе с тем считают: сложность программного обеспечения превосходит аппаратную сложность более чем на порядок. Ф. Брукс, известнейший авторитет в данной области, утверждает: «Сложность ПО является существенным, а не второстепенным свойством». С одной стороны, ПО абстрактно и нематериально. Оно не имеет физической природы и присущих этой природе ограничений, кажется чсловеку-творцу очень податливой «глиной», из которой можно «вылепить» все, что угодно. С другой стороны, сложность программного обеспечения может превосходить возможности человеческого разума. Следует различать понятия «программа» и «программное обеспечение». Государственный стандарт 19781-90 и международный стандарт 180/1 КС 2382/1-93 определяют, что ПО включает в себя не только программы, но п всю сопутствующую документацию, а также конфигурационные данные, необходимые для правильной работы программ. Чтобы подчеркнуть наличие многих элементов и отдать дань сложности ПО, его часто называют программной системой (ПС). Итак, программные системы состоят из совокупности программ, файлов конфигурации, необходимых для установки этих программ, и документации, которая описывает организацию системы и объясняет пользователям порядок работы с системой. Программный проект (ргоjесt) — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Временный характер проекта подчеркивает, что у любого проекта есть определенное начало и завершение. Завершение наступает, когда достигнуты цели проекта, или признано, что цели проекта не могут быть достигнуты, или исчезла необходимость в проекте. Характеристика «временный», как правило, не относится к создаваемому в ходе проекта продукту, услуге или результату. Большинство проектов предпринимается для достижения устойчивого, длительного результата — время жизни конечного программного продукта может существенно превышать время жизни программного проекта. В состав программного проекта входят как люди (разработчики), так и необходимые материальные ресурсы. ВНИМАНИЕ------------------------------------------------------------------------------------------- Увы. русскоязычному сообществу не повезло: схожее название (проектирование) имеет один из шагов деятельности программного проекта. Так же называется и выполняемая на этом шаге работа. Суть проектирования состоит в получении эскиза, концептуального решения требуемого ПО, представляемого обычное помощью рисунков и пояснений к ним. В английской же терминологии здесь употребляется Другой термин — design. Будьте внимательны и не называйте проектированием все шаги работы программного проекта. ------------------------------------------------------------------------------------------------------------------- Термин программная инженерия, или инженерия программного обеспечения, впервые был использован в 1968 году в качестве темы конференции, посвященной вопросам максимальной загрузки самых мощных (по тем временам) компьютеров. Там же было дано определение этого термина, нс утратившее своей актуальности и в настоящее время: программная инженерия (инженерия программного обеспечения) — система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах. Определение заложило основы новой научно-практической дисциплины: нужно было создать систему инженерных принципов, применимую к разработке ПО, обеспечить экономичность и надежность строительства, а также эффективную работоспособность конечного продукта на различных реальных машинах. Спустя четверть века международный терминологический стандарт ISO/IEC 2382/1-93 дает более развернутую формулировку: программная инженерия систематическое применение научных и технологических знаний, методов и практического опыта к проектированию, реализации, тестированию и документированию программного обеспечения в целях оптимизации его производства, поддержки и качества. Данная формулировка вводит много понятий, смысл которых будет поясняться но мере чтения учебника. Подчеркнем главное: программная инженерия обеспечивает управляемый, комплексный подход к созданию сложного программного продукта коллективом инженеров, определяя все шаги этой деятельности от начальной идеи до прекращения использования продукта клиентами. При этом гармонизируется взаимодействие разных специалистов, гарантируя синергетический эффект работы коллектива. Буквальный русский перевод термина software engineering нельзя назвать шедевром: звучит он как-то не по-русски. Поэтому долгое время в русскоязычном пространстве бытовал термин технология разработки ПО. Однако такой перевод сужал рамки понятия, оставляя за бортом многие аспекты дисциплины. Именно поэтому в национальных стандартах утвердился перевод программная инженерия. Программная инженерия — сравнительно молодая дисциплина, ее возраст чуть больше сорока лет. Первые двадцать лет (70-80-с годы) в ней доминировал классический, процедурный подход, а следующие двадцать лет (1990-2000-е годы) — объектно-ориентированный подход к разработке ПО. Различают методы, средства и процессы программной инженерии. ПРИМЕЧАНИЕ------------------------------------------------------------------------------------------------ Процессом здесь называют набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты. ------------------------------------------------------------------------------------------------------------------- Методы обеспечивают решение широкого спектра технических задач; например, назовем следующие задачи разработки: планирование и оценка программного проекта; анализ требований к компьютерной системе в целом н к программному обеспечению в частности; проектирование структур программ (и структур данных), входящих в состав ПО; конструирование программного текста (другие названия: кодирование, программирование, реализация); тестирование (выявление ошибок в созданных программах); сопровождение ПО, уже используемого заказчиками. Средства (утилиты) программной инженерии обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированной разработки ПО. Такие системы принято называть САSЕ-системамн. Аббревиатура САSЕ расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой). Процессы являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процессы определяют: порядок применения методов и утилит; формирование отчетов, форм по соответствующим требованиям; контроль, который помогает обеспечивать качество и координировать изменения; формирование ключевых моментов, по которым руководители оценивают прогресс. Реальные процессы достаточно сложны, поэтому в теории программной инженерии предлагаются модели — упрощенные и формализованные описания процессов создания ПО. Современная программная инженерия обеспечивает представительный набор моделей процессов, каждая из моделей имеет свои достоинства и недостатки. Работая с этими моделями, следует помнить, что они являются лишь абстрактными представлениями реальной последовательности шагов строительства ПО. Вместе с тем, применение моделей процессов гарантирует систематический, упорядоченный подход к промышленной разработке, использованию и сопровождению ПО. Фактически эти модели вносят в программные проекты организующее инженерное начало, необходимость которого трудно переоценить. Прежде чем перейти к рассмотрению наиболее популярных моделей процессов, обсудим современную классификацию процессов программной инженерии. Официальная классификация процессов программной инженерии Классификацию процессов программной инженерии задают международный стандарт ISO/IEC 12207-2008 «Systems and software engineering – Software Life Cycle Processes» и его российский аналог ГОСТ Р ИСО/МЭК 12207-2010. ПРИМЕЧАНИЕ--------------------------------------------------------------------------------------- В этих стандартах процессы привязаны к основному понятию программной инженерии — жизненному циклу программного обеспечения (ЖЦ ПО). В авторитетном словаре программной инженерии ISO/IEC/IEEE 24765-2010 «Systems and software Engineering – Vocabulary» записано: жизненный цикл программного обеспечения определяется как период времени, который начинается с момента замысла программного продукта и заканчивается в момент, когда ПО больше недоступно для использования. --------------------------------------------------------------------------------------------------------------- Действия, которые могут выполняться в жизненном цикле ПО, распределены по двум категориям. Одна из них (с названием «Процессы в контексте системы») описывает процессы для работы с автономным программным продуктом. Другая категория (с именем «Специальные процессы программных средств») содержит процессы в отношении программного продукта, являющегося частью более крупной системы. Сосредоточимся на 25 процессах первой категории, которые принадлежат к четырем группам: «Процессы соглашения», «Процессы организационного обеспечения проекта», «Процессы проекта» и «Технические процессы». Процессы соглашения Процессы соглашения состоят из двух процессов, которые определяют действия, необходимые для выработки соглашений между двумя организациями. Если реализуется процесс приобретения, то он обеспечивает средства для проведения деловой деятельности с поставщиком предоставляемых продуктов. Если реализуется процесс поставки, то он обеспечивает средства для проведения проекта, результатом которого является продукт, поставляемый приобретающей стороне. Процессы организационного обеспечения проекта Процессы организационного обеспечения проекта состоят из пяти процессов, осуществляющих менеджмент возможностей организации для приобретения и поставки продуктов через инициализацию, поддержку и управление проектами. Эти процессы обеспечивают ресурсы и инфраструктуру, необходимые для поддержки проектов, и гарантируют удовлетворение организационных целей и установленных соглашений. Они не претендуют на роль полной совокупности деловых процессов, реализующих менеджмент деловой деятельности организации. Процессами организационного обеспечения проекта являются: процесс менеджмента модели жизненного цикла (определяет, адаптирует, совершенствует н сопровождает политики, процессы п процедуры жизненного цикла для поддержки отдельных потребностей проекта); процесс менеджмента инфраструктуры (определяет, предоставляет и обслуживает средства, инструментарий, активы коммуникационных и информационных технологий, необходимые для деловой деятельности организации); процесс менеджмента портфеля проектов (совершает инвестирование адекватных фондов и ресурсов организации, а также санкционирует полномочия, необходимые для осуществления выбранных проектов. Он выполняет постоянную квалификацию проектов с целью подтверждения их обоснованности пли может быть переориентирован на обоснование продолжения инвестирования); процесс менеджмента людских ресурсов (гарантирует наличие персонала, обладающего навыками, опытом и квалификацией для выполнения процессов жизненного цикла); процесс менеджмента качества (гарантирует соответствие продукта и реализации процессов жизненного цикла целям организации в области качества, что, в конечном счете, обеспечивает удовлетворение заказчика). Процессы проекта Существуют две разновидности процессов проекта. Процессы менеджмента проекта используются для планирования, выполнения, оценки и управления продвижением проекта. Процессы поддержки проекта обеспечивают выполнение специализированных целей менеджмента. Процессы менеджмента проекта применяются для создания п совершенствования планов проекта, оценки фактического выполнения и продвижения относительно плановых заданий, а также управления выполнением проекта вплоть до полного его завершения. Отдельные процессы менеджмента проекта могут привлекаться в любое время жизненного цикла и на любом уровне иерархии проекта (в соответствии с планами проекта или возникновением непредвиденных событий). Процессы менеджмента проекта применяются на том уровне строгости и формализации, который зависит от риска и сложности проекта: 1) процесс планирования проекта; 2) процесс управления и оценки проекта. Процессы ношдержки проект формируют конкретную совокупность задач, ориентированных на выполнение специальных целей менеджмента. Все эти процессы очевидны при осуществлении менеджмента любой деятельности, располагаясь по нисходящей от организации в целом вплоть до отдельного процесса жизненного цикла и его задач: 1) процесс менеджмента решений (выбор на существующих альтернатив наиболее предпочтительного направления проектных действий); 2) процесс менеджмента рисков (определение, анализ, обработка и мониторинг факторов риска); 3) процесс менеджмента конфигурации (выявление и поддержание целостности всех выходных результатов проекта, а также обеспечение доступа к ним любой заинтересованной стороны); 4) процесс менеджмента информации (создание. сбор. преобразование, хранение, поиск, распространение и использование информации. Процесс управляет информацией, включая техническую, проектную, организационную, пользовательскую ннформацию, а также информацию, содержащуюся в соглашениях): 5) процесс измерений (сбор анализ и составление отчетов о данных, относящихся к разработанным продуктам и реализованным процессам, целью которого является поддержка эффективного менеджмента и объективная демонстрация качества продуктов). Технические процессы Технические процессы обеспечивают определение требований к системе, преобразование требований в полезный продукт. применение продукта и изъятие продукта из обращения, если он не используется. Технические процессы состоят из следующих процессов: 1) определение требовании правообладателей (позволяет выявлять правообладателей, которые связаны с системой на протяжении всего ее жизненного цикла, а также их потребности и пожелания): 2) анализ системных требований (преобразование определенных требований правообладателей и совокупность необходимых технический требований, которыми будут руководствоваться в проекте системы): 3) проектирование архитектуры системы (распределению системных требований между элементами системы); 4) процесс реализации (создание заданных элементов системы); 5) процесс комплексирования системы (объединение системных элементов для формирования полной системы, которая будет удовлетворять проекту и ожиданиям заказчика, выраженным в системных требованиях); 6) процесс квалифицированного тестирования системы (тестирование каждой программной реализации на соответствие своему требованию и подтверждение готовности системы к поставке); 7) процесс инсталляции программных средств (установка программного продукта, удовлетворяющего заданным требованиям, в целевую среду применения); 8) процесс поддержки приемки программных средств (убеждение приобретающей стороны в том, что продукт соответствует заданным требованиям); 9) процесс функционирования программных средств (применение программного продукта в предназначенной для него среде и обеспечение поддержки заказчиков программного продукта); 10) процесс сопровождения программных средств (обеспечение эффективной по затратам поддержки поставляемого программного продукта): 11) процесс изъятия из обращения программных средств (обеспечение завершения существования программного продукта). Базис процессов разработки ПО Будем считать, что модели процессов состоят из таких строительных элементов, как виды деятельности, действия и задачи. Деятельность – самый крупный элемент, который ориентирован на достижение весомой цели (например, обеспечение взаимодействия с заинтересованными в проекте лицами) и применяется независимо от прикладной области, размера проекта, сложности затрат или степени строгости использования «арсенала» программной инженерии. Деятельность состоит из действий. Действие – средний элемент, охватывает набор задач, которые производят этапный рабочий продукт (например, модель результатов проектирования). Задача – самый мелкий элемент. Задача фокусируется на маленькой, но хорошо определенной цели (например, на проведении тестирования модуля), которая приводит к ощутимому реальному результату. Модель процесса программной инженерии не является застывшим описанием порядка строительства ПО. Скорее, это адаптивное руководство, позволяющее людям (команде проекта) выполнять работу, указывая или выбирая подходящий набор рабочих действий и задач. Цель – создавать ПО за приемлемое время и с достаточным качеством, удовлетворяющим тех, кто спонсирует его создание и кто будет использовать его. Р.Прессман предлагает определить в составе базиса процессов такие виды деятельности, которые применимы ко всем программным проектам, независимо от их размера или сложности. Кроме того, целесообразно дополнить базис набором видов защитной деятельности, которые реально используются в процессах разработки. Обобщенный базис процессов для программной инженерии включает пять видов основной деятельности: Подготовка. К любой технической работе нужно правильно подготовиться. Подготовка заключается в тесном сотрудничестве с заказчиком и другими заинтересованными лицами. Главное – понять цели заинтересованных лиц в отношении продукта и проекта, собрать их требования к характеристикам и функциям ПО. Планирование. По понятным причинам опытный путешественник всегда берет в дорогу карту. Программный проект подобен сложному путешествию, и деятельность планирования создает карту, упрощающую «путешествие» команды. Карта называется планом программного проекта. План определяет порядок инженерной работы. Он описывает технические задачи, которые надо выполнять, наиболее вероятные факторы риска, подстерегающие команду, требуемые ресурсы, рабочие продукты, которые будут созданы, и расписание работы. Моделирование. В любой человеческой деятельности каждый день работают с моделями. Модель – упрощенное представление реальности. Обычно моделирование включает в себя два действия: анализ и проектирование. Модель анализа улучшает понимание требований к ПО, а модель проектирования показывает эскиз структуры и поведения ПО, выполняющего эти требования. Конструирование. Эта деятельность объединяет два действия: генерацию программного кода ПО и тестирование, которое требуется для обнаружения ошибок в коде. Развертывание. ПО поставляется заказчику, который оценивает полученный продукт и обеспечивает обратную связь, дающую возможность улучшения продукта. Для многих программных проектов перечисленные виды основной деятельности применяются итеративно, по мере развития проекта. Каждая итерация проекта производит для заинтересованных лиц версию ПО с частичной реализацией характеристик и функций. Виды основной деятельности по разработке дополняются набором видов защитной деятельности. Виды защитной деятельности «пронизывают» весь программный проект и помогают его команде управлять прогрессом, контролировать развитие, качество, изменения и риск. Типичные виды защитной деятельности: Отслеживание (трассировка) и контроль программного проекта – позволяют команде проекта оценивать степень выполнения плана проекта и предоставляют необходимую информацию для модификации расписания. Управление риском – оценка риска, которая может влиять на результат проекта, или качество продукта; выполнение действий, компенсирующих недопустимую степень риска. Обеспечение качество ПО – определяет и проводит действия, требуемые для поддержания качества ПО. Технические проверки – оценивают рабочие продукты программного проекта; цель – обнаружить и удалить ошибки до того, как они распространятся на следующую деятельность. Измерение – выполняет и накапливает измерения процесса, проекта и продукта, обеспечивающие создание таких характеристик ПО, которые соответствуют нуждам заинтересованных лиц. Используется в сочетании с другими видами основной и защитной деятельности. Управление конфигурацией ПО – управляет воздействием изменений на ход разработки в течении всего программного процесса. Управление повторной используемостью – определяет критерии для повторного использования рабочего продукта и задает механизмы для получения повторно используемых компонентов. Подготовка и производство рабочего продукта – включает действия, требуемые для создания рабочих продуктов. Классические модели жизненного цикла. Собственно, что же такое жизненный цикл программного обеспечения — ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования. Говоря другими словами, это время от начального момента создания какого либо программного продукта, до конца его разработки и внедрения. Жизненный цикл программного обеспечения можно представить в виде моделей. Модель жизненного цикла программного обеспечения — структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта. Эти модели можно разделить на 3 основных группы: Инженерный подход С учетом специфики задачи Современные технологии быстрой разработки Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки. Модель кодирования и устранения ошибок Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы. Данная модель имеет следующий алгоритм: Постановка задачи Выполнение Проверка результата При необходимости переход к первому пункту Модель также ужасно устаревшая. Характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей. Каскадная модель жизненного цикла программного обеспечения (водопад) Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.  Преимущества: Последовательное выполнение этапов проекта в строгом фиксированном порядке Позволяет оценивать качество продукта на каждом этапе Недостатки: Отсутствие обратных связей между этапами Не соответствует реальным условиям разработки программного продукта Относится к первой группе моделей. Каскадная модель с промежуточным контролем (водоворот) Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку. Относится к первой группе моделей. V модель (разработка через тестирование) Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.  Модель на основе разработки прототипа Данная модель основывается на разработки прототипов и прототипирования продукта. Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения: Прояснить не ясные требования (прототип UI) Выбрать одно из ряда концептуальных решений (реализация сцинариев) Проанализировать осуществимость проекта Классификация протопипов: Горизонтальные и вертикальные Одноразовые и эволюционные бумажные и раскадровки Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных. Вертикальные прототипы — проверка архитектурных решений. Одноразовые прототипы — для быстрой разработки. Эволюционные прототипы — первое приближение эволюционной системы. Модель принадлежит второй группе. Спиральная модель жизненного цикла программного обеспечения Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.  Преимущества:Быстрое получение результата Повышение конкурентоспособности Изменяющиеся требования — не проблема Недостатки: Отсутствие регламентации стадий Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике. Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта (рис.3.2). | |||||||||||||||||||||||||||||||||||||
