Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

1.Документы управления разработкой программного средства (process documen-101 tation). Эти документы протоколируют процессы разработки и сопровождения, обеспечивая связи внутри проектной группы.

2.Документы, входящие в состав программного средства (product documentation),

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

2.1.Пользовательская документация (user documentation), если ПС предполага-

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

Различают две категории пользователей:

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

−Администраторы (system administrator), которые управляет использованием системы конечными пользователями, и осуществляют не связанное с модификацией программ сопровождение. Например, администратор может регулировать права доступа конечных пользователей, поддерживать связь с поставщиками системы или выполнять определѐнные действия, чтобы поддерживать рабочее состояние системы.

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

2.2.Документация по сопровождению (system documentation). Содержит итого-

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

Документацию по сопровождению можно разбить на две группы:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−Документация, определяющая строение программ и структур дан-102 ных, а также технологию разработки. Эта документация содержит итоговые документы каждого этапа разработки программного средства.

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

6.1.Документы управления разработкой

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

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

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

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

6.2. Пользовательская документация

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

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

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

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 103

ния, а также (при необходимости) объяснение действий по сопровождению ратуры. Документ предназначен для системных администраторов.

6.3. Документация по сопровождению

Внешнее описание (requirements document). Состоит из спецификации качества и функциональной спецификации программного средства.

Описание архитектуры (description of the system architecture). Состоит из описаний архитектурного стиля, подсистем, коопераций классов, а также спецификаций каждой программы.

Описание структуры каждой компоненты и каждого модуля (design description).

Соответствует спецификациям компонентов и модулей.

Исходные тексты программ (program source code listings). Тексты исходных про-

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

Схема тестирования и описание всех тестов (validation documents). Документы ус-

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

Руководство по сопровождению (system maintenance guide). Этот документ, помимо описания имеющихся в ПС проблем и его аппаратно-программной платформы, включает также сведения о его возможном развитии, которое принималось в расчѐт при конструировании.

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

6.4. Стандарты документации

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

Ниже перечислены некоторые важные стандарты документирования, определѐнные Институтом инженеров по электротехнике и электронике IEEE (Institute of Electrical and Electronic Engineers):

−План управления конфигурациями программного обеспечения SCMP (Software Configuration Management Plan). Определяет, как и где должны хра-

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

−План управления программным проектом SPMP (Software Project Management Plan). Определяет, как управлять проектом, и соответствует установленному в организации процессу разработки программного обеспечения.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−Спецификация требований к программному обеспечению SRS (Software Re-104 quirements Specification). Определяет предъявляемые заказчиком требования

к программному продукту.

−Проектная документация программного обеспечения SDD (Software Design Document). Описывает архитектуру и детали проектирования в соответствии со стандартами выбранной методологии.

−Документация по тестированию программного обеспечения STD (Software Test Documentation). Описывает то, каким образом необходимо проводить тестирование исполняемого приложения, а также его компонентов.

−План экспертизы программного обеспечения SVVP (Software Verification and Validation Plan). Определяет, как и в какой последовательности должны проверяться этапы проекта и программный продукт на соответствие предъявляемым к нему требованиям. План верификации ориентирован на контроль правильности сборки приложения, план валидации – на соответствие приложения требованиям.

−План контроля качества программного обеспечения SQAP (Software Quality Assurance Plan). Определяет то, каким образом проект должен достигнуть уровня, установленного в спецификации качества.

Кроме этого, для стандартизации описания объектно-ориентированных программных проектов консорциум OMG (Object Management Group) рекомендует использо-

вать стандарт унифицированного языка моделирования UML.

7. УНИФИЦИРОВАННЫЙ ПРОЦЕСС РАЗРАБОТКИ

Рациональный унифицированный процесс RUP (Rational Unified Process) – одна из наиболее совершенных методологий, которая формировалась с прицелом на поддержку управления качеством в рамках требований CMM – SEI (модели роста возможностей Capability Maturity Model Института разработки программ Software En- gineering Institute).

Унифицированный процесс – это методология создания ПС, оформленная в виде базы знаний, которая снабжена поисковой системой.

RUP определяет: кто делает, когда делает, что делает, как достичь заданной цели.

Методология широко используется для производства объектно-ориентированных программных систем и соответствует стандарту ISO 12207, связанному с процессами жизненного цикла. Унифицированный процесс, созданный в компании IBM Rational Software, представляет собой программный продукт, применение которого гарантирует получение как минимум третьего уровня технологической зрелости организаций-разработчиков согласно CMM – SEI.

Возможности RUP:

1.Поддержка необходимого уровня хода разработки.

2.Обеспечение всестороннего контроля.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

3.Установление последовательности различных видов деятельности, необходи-105 мых для преобразования требований пользователей в ПС.

4.Управление задачами как одного разработчика, так и проектной группы в целом.

7.1. Базовые понятия RUP

Основными понятиями унифицированного процесса являются:

1.Артефакт (artifact). Существенная часть информации, которая порождается, изменяется и используется разработчиками в ходе проекта для выпуска целевой системы. Артефактом может быть модель или еѐ часть, код программы, исполняемая программа, стандарт, документация и т.д. Весь процесс разработки рассматривается в RUP как последовательное создание и развитие артефактов.

2.Вариант использования (use case), или прецедент (precedent). Описывает закон-

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

3.Роль (role). Видение системы, которое может быть поручено отдельному сотруднику или группе. Каждая роль требует ответственности и способностей для выполнения некоторой деятельности или разработки некоторого артефакта. Типичные роли для RUP: руководитель проекта, архитектор, аналитик, проектировщик, программист, тестер, пользователь.

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

5.Дисциплина (discipline). Соответствует технологическому процессу и представляет собой последовательность действий, приводящую к получению конкретного и значимого результата.

Связь между понятиями представлена на рис. 7-1.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011