Процессы организационного обеспечения проекта

СОДЕРЖАНИЕ

	стр
ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ………………………………	4
ОРГАНИЗАЦИЯ РАБОТЫ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ……………………………………………………………………………….	25
ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ И ИХ АНАЛИЗ……………….	30
МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ…………………..	106
КЛАССИЧЕСКИЕ МЕТОДЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ…….	149
ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ…………………………………………………………………………………..	165
СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ…	181
СТРУКТУРНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ……………….	207
ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ………..	220
МЕТРИКИ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРОГРАММНЫХ СИСТЕМ…………	239
ИСПОЛЬЗОВАННАЯ ЛИТЕРАТУРА……………………………………………………….	262

ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

Основные понятия прогроммной инженерии

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

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

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

Следует различать понятия «программа» и «программное обеспечение». Государ­ственный стандарт 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. процесс менеджмента инфраструктуры (определяет, предоставляет и обслужи­вает средства, инструментарий, активы коммуникационных и информационных технологий, необходимые для деловой деятельности организации);

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

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

5. процесс менеджмента качества (гарантирует соответствие продукта и реализа­ции процессов жизненного цикла целям организации в области качества, что, в конечном счете, обеспечивает удовлетворение заказчика).

Процессы проекта

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

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

1) процесс планирования проекта;

2) процесс управления и оценки проекта.

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

1) процесс менеджмента решений (выбор на существующих альтернатив наиболее предпочтительного направления проектных действий);

2) процесс менеджмента рисков (определение, анализ, обработка и мониторинг факторов риска);

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

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

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

Технические процессы

 

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

Технические процессы состоят из следующих процессов:

1) определение требовании правообладателей (позволяет выявлять правообладателей, которые связаны с системой на протяжении всего ее жизненного цикла, а также их потребности и пожелания):

2) анализ системных требований (преобразование определенных требований правообладателей и совокупность необходимых технический требований, которыми будут руководствоваться в проекте системы):

3) проектирование архитектуры системы (распределению системных требований между элементами системы);

4) процесс реализации (создание заданных элементов системы);

5) процесс комплексирования системы (объединение системных элементов для формирования полной системы, которая будет удовлетворять проекту и ожиданиям заказчика, выраженным в системных требованиях);

6) процесс квалифицированного тестирования системы (тестирование каждой программной реализации на соответствие своему требованию и подтверждение готовности системы к поставке);7) процесс инсталляции программных средств (установка программного продукта, удовлетворяющего заданным требованиям, в целевую среду применения);8) процесс поддержки приемки программных средств (убеждение приобретающей стороны в том, что продукт соответствует заданным требованиям);9) процесс функционирования программных средств (применение программного продукта в предназначенной для него среде и обеспечение поддержки заказчиков программного продукта);10) процесс сопровождения программных средств (обеспечение эффективной по затратам поддержки поставляемого программного продукта):11) процесс изъятия из обращения программных средств (обеспечение завершения существования программного продукта). Базис процессов разработки ПОБудем считать, что модели процессов состоят из таких строительных элементов, как виды деятельности, действия и задачи. Деятельность – самый крупный элемент, который ориентирован на достижение весомой цели (например, обеспечение взаимодействия с заинтересованными в проекте лицами) и применяется независимо от прикладной области, размера проекта, сложности затрат или степени строгости использования «арсенала» программной инженерии. Деятельность состоит из действий. Действие – средний элемент, охватывает набор задач, которые производят этапный рабочий продукт (например, модель результатов проектирования). Задача – самый мелкий элемент. Задача фокусируется на маленькой, но хорошо определенной цели (например, на проведении тестирования модуля), которая приводит к ощутимому реальному результату.Модель процесса программной инженерии не является застывшим описанием порядка строительства ПО. Скорее, это адаптивное руководство, позволяющее людям (команде проекта) выполнять работу, указывая или выбирая подходящий набор рабочих действий и задач. Цель – создавать ПО за приемлемое время и с достаточным качеством, удовлетворяющим тех, кто спонсирует его создание и кто будет использовать его.Р.Прессман предлагает определить в составе базиса процессов такие виды деятельности, которые применимы ко всем программным проектам, независимо от их размера или сложности. Кроме того, целесообразно дополнить базис набором видов защитной деятельности, которые реально используются в процессах разработки. Обобщенный базис процессов для программной инженерии включает пять видов основной деятельности:Подготовка. К любой технической работе нужно правильно подготовиться. Подготовка заключается в тесном сотрудничестве с заказчиком и другими заинтересованными лицами. Главное – понять цели заинтересованных лиц в отношении продукта и проекта, собрать их требования к характеристикам и функциям ПО.Планирование. По понятным причинам опытный путешественник всегда берет в дорогу карту. Программный проект подобен сложному путешествию, и деятельность планирования создает карту, упрощающую «путешествие» команды. Карта называется планом программного проекта. План определяет порядок инженерной работы. Он описывает технические задачи, которые надо выполнять, наиболее вероятные факторы риска, подстерегающие команду, требуемые ресурсы, рабочие продукты, которые будут созданы, и расписание работы.Моделирование. В любой человеческой деятельности каждый день работают с моделями. Модель – упрощенное представление реальности. Обычно моделирование включает в себя два действия: анализ и проектирование. Модель анализа улучшает понимание требований к ПО, а модель проектирования показывает эскиз структуры и поведения ПО, выполняющего эти требования.Конструирование. Эта деятельность объединяет два действия: генерацию программного кода ПО и тестирование, которое требуется для обнаружения ошибок в коде.Развертывание. ПО поставляется заказчику, который оценивает полученный продукт и обеспечивает обратную связь, дающую возможность улучшения продукта.Для многих программных проектов перечисленные виды основной деятельности применяются итеративно, по мере развития проекта. Каждая итерация проекта производит для заинтересованных лиц версию ПО с частичной реализацией характеристик и функций. Виды основной деятельности по разработке дополняются набором видов защитной деятельности. Виды защитной деятельности «пронизывают» весь программный проект и помогают его команде управлять прогрессом, контролировать развитие, качество, изменения и риск. Типичные виды защитной деятельности:Отслеживание (трассировка) и контроль программного проекта – позволяют команде проекта оценивать степень выполнения плана проекта и предоставляют необходимую информацию для модификации расписания.Управление риском – оценка риска, которая может влиять на результат проекта, или качество продукта; выполнение действий, компенсирующих недопустимую степень риска.Обеспечение качество ПО – определяет и проводит действия, требуемые для поддержания качества ПО.Технические проверки – оценивают рабочие продукты программного проекта; цель – обнаружить и удалить ошибки до того, как они распространятся на следующую деятельность.Измерение – выполняет и накапливает измерения процесса, проекта и продукта, обеспечивающие создание таких характеристик ПО, которые соответствуют нуждам заинтересованных лиц. Используется в сочетании с другими видами основной и защитной деятельности.Управление конфигурацией ПО – управляет воздействием изменений на ход разработки в течении всего программного процесса.Управление повторной используемостью – определяет критерии для повторного использования рабочего продукта и задает механизмы для получения повторно используемых компонентов.Подготовка и производство рабочего продукта – включает действия, требуемые для создания рабочих продуктов.

 

---

Дата добавления: 2021-03-18; просмотров: 164; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!