Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Вопросы к экзамену по курсу
«Программная инженерия»
(Презентация 1)
Программная инженерия — это область компьютерной науки и технологии, которая занимается построением программных систем, настолько больших и сложных, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций.
Суть методологии программной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств.
Термином жизненный цикл (ЖЦ) принято отражать совокупность процессов и этапов развития организмов живой природы, технических систем, продуктов производства от моментов зарождения или появления потребности их создания и использования до прекращения функционирования или применения. Это соответствует всеобщему закону развития любых изделий, событий или процессов между их началом и концом, которые определяют цикл их создания, существования и применения.
Программы и данные в системах и вычислительных машинах являются наиболее гибкими компонентами программной инженерии и подвержены изменениям в течение всего их ЖЦ.
Типовая модель процессов жизненного цикла сложной системы начинается с концепции идеи системы или потребности в ней, охватывает проектирование, разработку, применение и сопровождение системы и заканчивается снятием системы с эксплуатации.
Общая модель ЖЦ:
снятие с эксплуатации (утилизация).
Организованное, контролируемое и методичное отслеживание динамики изменений в жизненном цикле программ и данных, их слаженная разработка при строгом учете и контроле каждого изменения являются основой эффективного, поступательного развития каждой крупной системы методами программной инженерии.
Существует множество моделей процессов жизненного цикла систем и программных средств, но три из них в международных стандартах обычно квалифицируются как фундаментальные: каскадная; инкрементная; эволюционная.
Каскадная модель жизненного цикла наиболее известна и применяется достаточно широко. Она, по существу, реализует принцип однократного выполнения каждого из базовых процессов и этапов в их естественных границах.
(Презентация 1)
Система — это совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей. Определяющим признаком системы является то, что свойства и поведение системных компонентов влияют друг на друга сложным образом.
Системотехника — как технология создания систем охватывает все аспекты создания и модернизации сложных вычислительных комплексов, где программные продукты играют ведущую роль. Сюда можно отнести технологию разработки аппаратных средств, внутренних вычислительных процессов и связей всей системы, а также технологию создания ПС.
Программный менеджер и/или системный инженер должен быть знаком с несколькими способами проектирования, знать, как перевести расплывчатые требования и пожелания заказчика в четкое техническое задание, и уметь разговаривать с пользователем системы на языке предметной области, а не на профессиональном программистском жаргоне.
Программная инженерия — как часть системотехники охватывает все аспекты жизненного цикла ПС от начальной стадии разработки системных требований до завершения использования программного продукта. При этом специалисты выполняют практическую, инженерную работу. Они применяют теоретические построения, методы и средства там, где это необходимо, но делают это выборочно и всегда пытаются найти практическое решение задачи, даже если не существует подходящей теории или методов решения.
Программирование компонентов — это дело, главным образом, индивидуальное, а программная инженерия систем — всегда коллективная работа.
Программный инженер — это член команды, поэтому должен обладать навыками общения и межличностных отношений, а также уметь планировать не только свою работу, но и координировать ее с работой других.
(Презентация 1)
Основная цель современных технологий программной инженерии состоит в обеспечении эффективности всего жизненного цикла комплексов программ для ЭВМ в различных проблемно-ориентированных областях.
Современная технология - совокупность методов и инструментальных средств автоматизации, а также технологические процессы, обеспечивающие жизненный цикл сложных ПС с заданными функциональными и конструктивными характеристиками качества. Для этого рекомендуется использовать наиболее эффективные и совершенные методы проектирования и проводить комплексную автоматизацию ЖЦ ПС
Методической основой технологии, регламентирующей деятельность специалистов, является типовой технологический процесс. Он отражается набором этапов и операций в последовательности их выполнения и взаимосвязи, обеспечивающих ведение работ на всех стадиях от инициирования проекта и подготовки технического задания до завершения испытаний или применения версии ПС.
Индустриализация технологий программной инженерии базируется на стандартизации процессов разработки программ, их структурного построения и интерфейсов с операционной и внешней средой. Для этого с самого начала разработки должны определяться состав и этапы работ, необходимые для достижения конечной цели, а также требуемые для их выполнения ресурсы.
Значительные достижения в развитии и применении современных методов и технологии обеспечения крупномасштабных проектов ПС сосредоточены в методологии CMM (Capability Maturity Model — система и модель для оценки зрелости) комплекса технологических процессов жизненного цикла ПС, а также в ее последующем развитии в CMMI:2003.
Методология обеспечения качества ПС в программной инженерии поддержана рядом методических документов и инструментальных средств, а также формализована комплексом международных стандартов. Внедрение комплекса требует больших усилий и затрат, что ограничило его массовое использование для относительно простых и средней сложности проектов.
Концептуальные и организационные основы административного управления жизненным циклом и качеством ПС в системе СММ, а также CMMI:2003, определены в восьми базовых принципах, которые декларированы в стандартах ISO 9000:2000 и ISO 15504:1-9.
(Презентация 2)
Профиль стандартов — это совокупность нескольких (или подмно-жество одного) базовых стандартов (и других нормативных документов) с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций
Основными целями применения профилей стандартов при создании и применении ПС являются:
(Презентация 2)
Применение стандартизированных профилей позволяет заказчику системы освободиться от зависимости от одного поставщика программных или аппаратных средств за счет выбора этих средств из числа доступных на рынке и соответствующих стандартам, нормативным требованиям и рекомендациям профиля.
Применение профилей, относящихся к программным комплексам (функциональным частям систем), облегчает повторное использование в проектируемой системе уже разработанных и проверенных программных компонентов.
Профиль стандартов ЖЦ ПС (функциональных частей системы) должен определять архитектуру программного комплекса (модели функций, логические модели данных, внешние интерфейсы) и их структуру (разбиение системы на подсистемы и систем на модули, определение унифицированных интерфейсов взаимодействия между комплексами программ и их компонентами)
В зависимости от области распространения профилей они могут иметь разные статусы утверждения:
Для эффективного применения конкретного профиля необходимо:
(Презентация 2)
Профиль стандартов конкретной системы не является статичным, он развивается и конкретизируется (возможно, во взаимодействии с заказчиком) в процессе жизненного цикла и оформляется в составе документации системы.
Проектированию системы предшествует обследование объекта автоматизации, результатом которой являются его функциональная и информационная модели, определение целей создания системы и состава ее функций.
После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и управлении конфигурацией.
Целесообразно рассматривать две группы профилей систем
На этапах жизненного цикла системы выбираются и затем применяются общесистемные функциональные профили:
Создание и применение профилей жизненного цикла ПС можно разделить на два крупных процесса:
(Презентация 2)
Комплексное, скоординированное применение профилей стандартов и средств в процессе создания, развития и применения ПС позволяет исключать многие виды дефектов или значительно ослаблять их влияние. Тем самым, уровень достигаемого качества ПС становится предсказуемым и управляемым, непосредственно зависящим от ресурсов, выделяемых на его достижение, а главное, от системы качества и эффективности технологии, используемых на всех этапах жизненного цикла ПС.
Общая структура и состав профиля стандартов жизненного цикла системы и крупного программного средства для управления проектом представлены на рис. ниже. На этом рисунке выделены и отражены группа базовых стандартов управления проектами систем и основными процессами сложных программных средств, а также перечень совокупности стандартов, детализирующих и поддерживающих процессы их жизненного цикла.
Модель профиля стандартов жизненного цикла сложных программных средств обычно формируется из 10—12 базовых стандартов. Их количество зависит от целей, сложности и особенностей проекта, от назначения и области применения модели, а также от возможностей формализации ее компонентов.
(Презентация 3)
В методологии СММ выделены пять уровней зрелости, раскрываемые в этом стандарте де-факто. Виды деятельности для высоких уровней зрелости в соответствии с СММ в стандарте делятся на базовые и общие.
Базовые виды деятельности являются обязательными и сгруппированы в пять категорий:
контрактная; инженерная; управленческая; вспомогательная; организационная.
Уровни зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств автоматизации работ, наличием и полнотой реализации функций системой
обеспечения качества технологических процессов и их результатов.
Уровень 1 — Начальный:
приближенная оценка процессов, размера работ, ресурсов и результатов
Уровень 2 — Управляемый — базовое управление:
управление процессами - управление требованиями;
планирование и мониторинг проекта;
Уровень 3 — Определенный — стандартизация процессов:
определение стандартного процесса; интегрированное управление проектом; компонентами и продуктами;
верификация, валидация, контроль качества процессов и продуктов;
Уровень 4 — Предсказуемый — количественное управление:
измерение характеристик компонентов, продукта и процессов;
количественное управление процессами, затратами и характеристиками
качества;
распределение, контроль и обеспечение процессов ресурсами;
количественный контроль и управление рисками процессов, ресурсов и качества;
контроль и управление поставкой продуктов
Уровень 5 — Оптимизационный — непрерывное улучшение:
управление изменением и качеством процессов и продукта;
инновации, количественное управление процессами и обеспечением
ресурсами;
совершенствование качества и управления процессами и
продуктами;
Зрелость процессов — это степень их управляемости,
возможность поэтапной количественной оценки качества, контролируемости
и эффективности результатов.
Модель зрелости предприятия представляет собой методический нормативный материал, определяющий правила создания и функционирования системы управления жизненным циклом ПС, методы и стандарты систематического повышения
культуры и качества производства.
(Презентация 3)
В 2003 году американский Институт программной инженерии (SEI)
опубликовал новую комплексную модель CMMI, уточняющую и совершенствующую предшествовавшие модели СММ
Внедрение этой модели акцентировано на улучшении процессов управления проектами ПС, обеспечении их высокого качества и конкурентоспособности, с основной целью — сделать процессы проектов управляемыми, а результаты — предсказуемыми.
Значительное внимание в CMMI уделяется процессам разработки и учету итераций при изменении требований заказчиков, их прослеживанию к функциям, компонентам, тестам и документам проекта.
Модели CMMI представляют помощь специалистам при организации технологии и совершенствовании их продуктов, а также для упорядочения и обслуживания процессов разработки и сопровождения ПС. Концепция этих моделей покрывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также процессов создания интегрированных программных продуктов и совершенствования их разработки.
Варианты описания моделей построены по единой схеме, которая
содержит общие разделы:
предисловие;
1)введение;
2) модель компонентов;
3) терминология;
4) содержание уровней и главные компоненты каждого варианта модели
(разработка целей и процедур);
5 раздел — структура взаимодействия процессов. Аннотированы четыре
категории процессов раздела 7, их общий обзор и схемы взаимодействия
CMMI процессов:
• менеджмент процессов;
• менеджмент — управление проектом;
• инжиниринг (технология);
• поддержка;
6 раздел — использование модели CMMI — краткие рекомендации
для пользователей по применению модели и обучению;
Последний, седьмой раздел самый большой в каждом стандарте, он
занимает около 500 страниц из полного объема документа, который составляет
свыше 700 страниц. В этом разделе представлены подробные
рекомендации для реализации каждого из перечисленных в нем множества процессов, которые учитывают особенности конкретной модели.
(Презентация 4)
Серия стандартов ISO 9000:2000 разработана, чтобы помочь предприятиям
всех типов и размеров внедрить и использовать эффективные
системы менеджмента (административного управления) качества.
Совместно они образуют комплект согласованных стандартов управления системами качества и могут применяться как основа процессов управления
в программной инженерии:
— ISO 9000:2000 — представляет введение в системы управления качеством продукции и услуг и словарь качества;
— ISO 9001:2000 — устанавливает детальные требования для систем управления качеством, достаточные в случае необходимости продемонстрировать способность предприятия, обеспечить соответствие качества продукции и услуг требованиям заказчика;
— ISO 9004:2000 — содержит руководство по внедрению и применению широко развитой системы управления качеством, чтобы достичь постоянного улучшения деловой деятельности и результатов предприятия
Стандарты серии ISO 9000:2000 применяют процессный подход в административном управлении системами качества предприятий, а также рассматривают способы быстрого выявления и реализации возможностей для их улучшения.
Стандарт ISO 9001:2000 — Система менеджмента (административного управления) качества. Требования — является базой для Руководства по их реализации в стандарте ISO 9004.
Общие требования к системе менеджмента качества. Организация- разработчик должна установить и управлять процессами, необходимыми для обеспечения уверенности в том, что продукция и/или услуга соответствуют требованиям заказчика.
В качестве способа внедрения и демонстрации установленных процессов организация должна создать систему менеджмента качества, основываясь на требованиях настоящего международного стандарта. Система менеджмента качества должна быть внедрена, поддерживаться в рабочем состоянии и подвергаться улучшениям со стороны организации.
Стандарт ISO 90003:2004 — Рекомендации по применению стандарта ISO 9001:2000 для программных средств — предназначен для регламентирования менеджмента при приобретении, поставке, разработке, применении, сопровождении сложных программных средств и при их обслуживании. Стандарт не содержит ограничений и изменений базовых требований ISO 9001:2000 и предлагается при установлении соответствия требованиям комплексов программ:
— как части коммерческого контракта с другими организациями;
— при представлении полезного продукта для рынка;
— для использования при поддержке процессов организации проектов ПС;
— для учета при встраивании программных средств в комплексы аппаратуры;
— при организации сервиса программных продуктов.
Стандарт ISO 10006:1997 — Руководство по качеству при управлении проектом — содержит принципы управления качеством различных по содержанию крупных проектов. В нем изложены рекомендации по административному управлению качеством процесса проектирования сложных объектов и в том числе программных средств.
В стандарте ISO 10013:1995 — Руководящие указания по разработке руководств по качеству — изложены рекомендации по подготовке конкретного Руководства по качеству, адаптированного к определенным потребностям предприятия и пользователей. Созданное в результате Руководство должно отражать документированные процедуры системы качества конкретного предприятия или проекта в соответствии с общими требованиями стандартов серии ISO 9000.
(Презентация 4)
Рядом зарубежных организаций и промышленных фирм под руководством IEEE с 1990 года ведется активная разработка последовательных версий стандартов интерфейсов открытых систем POSIX (Portable operating system interfaces). Выполнена большая работа по пересмотру, расширению и реорганизации около двадцати базовых спецификаций POSIX 1990—1998 годов IEEE 1003. Улучшена систематизация и структура стандартов, усовершенствовано удобство их применения пользователями.
Стандарты открытых систем — POSIX регламентируют совокупность базовых, системных сервисов для обеспечения унифицированных интерфейсов прикладных программ, специфицированных для языка Си, командного языка и совокупности служебных программ. Основная цель — сделать программы переносимыми на уровне различных исходных языков.
При формировании концепции стандартов POSIX были поставлены следующие задачи:
— содействовать облегчению и автоматизации переноса кода готовых прикладных программ на иные платформы;
— способствовать определению и унификации интерфейсов программных компонентов заранее при проектировании программных средств, а не только в процессе их реализации;
— сохранять по возможности и учитывать все главные, созданные ранее, унаследованные и используемые программные средства и компоненты;
Цель данной версии стандарта состоит в том, чтобы минимизировать дополнительную работу для разработчиков прикладных программ.
Цель состояла также в том, чтобы продвинуть мобильность прикладных программ по всей области применения операционной системы UNIX, развивая ясный, последовательный и однозначный стандарт для спецификации интерфейса переносимой операционной системы, основанной на документации системы UNIX. Этот стандарт систематизирует все существующие типовые формулировки операционной системы UNIX.
Новую версию международных стандартов POSIX составляют аннотированные ниже четыре части стандартов ISO 9945:1-4:2003 — ИТ.
Интерфейсы переносимых операционных систем.
Ч. 1. Базовые определения.
Ч. 2. Системные интерфейсы.
Ч. 3. Команды управления и сервисные
программы.
Ч. 4. Обоснование.
Стандарт ISO 9945-1:2003 — содержит основные концептуальные определения и подробные пояснения методов реализации интерфейсов для обеспечения мобильности компонентов и комплексов программ, общее для всех томов оглавление стандарта, в том числе сервисные соглашения и определения заголовков языка Си.
Стандарт ISO 9945-2:2003 — Системные интерфейсы — уточняет и детализирует: концепцию переносимости и принципы ее обеспечения путем унификации интерфейсов прикладных программ с операционными системами, функции обслуживания, ориентированные на язык программирования Си, функциональные вопросы, в том числе мобильность, обработка ошибок, и устранение ошибок
В третьей части стандарта ISO 9945-3:2003 — Основные команды управления и сервисные программы (Shell and utilities) — изложено конкретное представление команд операционной системы и утилит, обеспечивающих унифицированное взаимодействие с мобильными прикладными программами, определения для стандартного источника кодового уровня интерфейса командного интерпретатора («shell») и стандартные утилиты для прикладных программ.
Четвертая часть стандарта ISO 9945-4:2003 — Обоснование — содержит группу из пяти крупных приложений:
— обоснование базовых определений — приложение А;
— обоснование системных интерфейсов — приложение В;
— обоснование команд управления и сервисных программ-утилит — приложение С;
— рассмотрение переносимости — приложение D;
— рассмотрение субпрофилей — приложение Е.
(Презентация 5)
Комплекс формально организованных мероприятий по достижению единой цели создания сложной системы с требуемыми характеристиками качества при ограниченных ресурсах получил название — проект.
Цель управления проектом — рациональное использование и предупреждение потери ресурсов путем сбалансированного распределения их по частным работам на протяжении всего жизненного цикла объекта с заданным качеством.
Управление проектом — это особый вид деятельности, включающий
при создании сложных систем.
Задачи целевого управления такими работами — сводить воедино усилия исполнителей — специалистов разной квалификации, подрядчиков и субподрядчиков, добиваясь, чтобы они выступали как команда при создании компонентов систем, а не как разрозненная группа функциональных специалистов.
Методологической базой целевого планирования и управления проектами ПС является системный анализ, который предполагает:
— обследование объектов и среды проектирования для предварительной формализации целей, назначения и задач проекта ПС;
— исследование и сопоставление альтернативных действий, которые должны приводить к достижению поставленных целей проектирования;
Системное проектирование сложных комплексов программ является фундаментом для обеспечения функциональной адекватности требованиям всего жизненного цикла ПС. От полноты и тщательности системного проектирования зависят эффективность реализации функций системы и степень удовлетворения ожиданий и требований заказчика и пользователей.
(Презентация 5)
Основная цель системного проектирования в программной uнжeнерии — подготовить, обосновать и согласовать замыслы и решения заказчика(потребителя) и разработчика (поставщика) о необходимости, направлениях и концепции создания или модернизации существующего ПС и изменениях его качества.
Результатом этих работ должны быть системный проект, техническое задание и контракт на продолжение разработки ПС или решение о ее нецелесообразности и прекращении.
В последовательности выработки и подготовки к реализации этих требований обычно рассматриваются три крупных этапа:
— обследование, системный анализ сущест-вующей системы и выявление ее недостатков;
— обобщение результатов системного анализа и создание предварительной концепции новой или модернизированной системы и ее программных средств;
— разработка системного проекта комплекса программ и базы данных, определяющего и конкретизирующего цель, назначение и методы дальнейшего детального проектирования и всего жизненного цикла ПС.
Системное проектирование структурировано, и методология его реализации отражает следующие проблемы, процессы и методы:
— цели и принципы системного проектирования сложных программных средств для обеспечения их последующего жизненного цикла в информационных системах;
— подготовку к непосредственному детальному проектированию, разработке и всему жизненному циклу комплекса программ и базы данных для информационной системы;
— основы предварительного структурного проектирования и современных технологий системного анализа и проектирования сложных комплексов программ;
— методы разработки требований к характеристикам качества и распределения ресурсов, необходимых для реализации проектов сложных ПС и баз данных;
— задачи и принципы системного проектирования обеспечения безопасности и защиты комплексов программ от различных угроз;
В последние десятилетия быстро возрастает сложность объектов и систем, создаваемых в различных областях индустрии. Для их разработки привлекаются специалисты разной квалификации и большие финансовые и материальные ресурсы. Использование этих ресурсов должно координироваться и объединяться комплексом мероприятий для достижения общей цели — создания соответствующего сложного объекта или системы с заданным качеством в условиях ограниченных ресурсов.
Целевое системное управление проектами позволяет планировать, контролировать и анализировать информацию о состоянии и тенденциях изменения объекта разработки, его качестве и затраченных ресурсах. При этом непрерывно должны сохраняться основные цели проекта и главные пути ее достижения.
Это позволяет рассматривать альтернативы технических решений и предотвращает от сосредоточения внимания на частных задачах или вариантах решений, которые кажутся полезными и интересными, но мало отражаются на достижении главной цели проекта ПС.
(Презентация 5)
Системное проектирование в программной инженерии охватывает период жизненного цикла сложных комплексов программ, начиная от формулирования первичного замысла на создание или модернизацию системы и до начала детального проектирования и разработки ПС.
В системном проекте должны быть обобщены и отражены следующие основные результаты выполненных системных исследований и разработок :
— обобщенный анализ проведенного обследования объекта информатизации, функций существующей информационной системы, качества ее основных программных компонентов и базы данных;
— совокупность предварительных исходных требований к функциям и характеристикам комплекса программ;
— оценки имеющихся и потенциально доступных ресурсов (финансовых, вычислительных средств, специалистов) для обеспечения всего жизненного цикла и требуемого качества проекта комплекса программ;
— проект формализованного технического задания и спецификации требований к ПС, а также предложения по его финансированию и обеспечению ресурсами;
— системный проект, обобщающий проведенные исследования и разработки, позволяющий заключить контракт между разработчиком и заказчиком на финансирование и продолжение проектирования и/или на весь жизненный цикл ПС.
Системное проектирование сложных ПС начинается с обследования объекта информатизации, системного анализа предметной области и выявления потребности в создании или модернизации комплекса программ с определенными функциями и качеством.
Разработка исходных требований для технического задания на проект ПС начинается с анализа результатов обследования объекта информатизации и оценки доступных ресурсов для реализации проекта.
Предварительный анализ и моделирование процессов обработки данных при системном проектировании должны проходить этапы от простого установления базовых отношений между понятиями, через определение интерфейсов доступа и атрибутов, к проекту модели состояний и взаимодействий между реальными объектами и процессами ПС. Эти модели должны служить базой при разработке схем потоков управления и данных, описывающих процессы их обработки, а впоследствии интегрироваться с отработанными моделями процессов для комплексного исследования функционирования прототипов — пилотных проектов ПС в целом.
Наглядными и удобными в работе являются графические представления описаний проектных решений, которые позволяют создавать прототипы ПС.
Одним из наиболее эффективных направлений сокращения затрат и повышения качества комплексов программ является активное использование методического, технологического, алгоритмического и программного задела из предшествующих проектов, которое может быть названо прототипированием в широком смысле слова.
Таким образом, последовательное прогнозирование, планирование и системное управление проектом обеспечивают рациональное использование ресурсов в процессе создания сложных ПС гарантированного качества.
Системный проект программного средства новой или модернизированной системы должен содержать достаточно полные требования к функциям и характеристикам качества комплекса программ, описание и графическое представление его архитектуры, базы данных и взаимодействия компонентов, предполагаемую модель жизненного цикла, предварительные планы последующих этапов и работ.
(Презентация 6)
При разработке структуры программного средства в процессе системного проектирования, прежде всего, необходимо сформулировать критерии ее формирования.
Важнейшими критериями могут быть: модифицируемость, возможности отладки и удобство управления разработкой ПС, обеспечение возможности контролируемого изменения конфигурации, состава и функций компонентов с сохранением целостности структурного построения базовых версий ПС.
Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:
— стандартизированную структуру целостного построения ПС и/или БД определенного класса;
— унифицированные правила структурного построения функциональных программных компонентов и модулей;
— стандартизированную структуру базы данных, обрабатываемых программами;
— унифицированные правила структурного построения информационных модулей, заполняющих базу данных;
Методология структурного анализа и предварительного структурного проектирования ПС начинается с общего обзора функций системы. Далее функции должны детализироваться сверху вниз в виде иерархической структуры таким образом, чтобы процедуры сбора, хранения и переработки информации, рассматриваемые сначала как нечто единое целое, расчленялись на отдельные элементы данных, компонентов и действия, совершаемые над этими данными.
Структурный анализ, исходя из функционального описания системы в целом, позволяет разделить ее на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать структуры данных.
Разделение общей задачи системы и программного средства на компоненты
Спецификация требований к предварительной архитектуре комплекса программ
Анализ концепции, требований технического задания и технико-экономических оценок должен позволять выполнить предварительное структурное проектирование ПС и оценку вычислительных ресурсов, необходимых для решения основных функциональных задач. Повышению эффективности структурирования могут значительно способствовать заимствование из предыдущих проектов спецификаций прототипов, версий и отдельных компонентов ПС. Для обеспечения системного проектирования на этом этапе большое значение имеют графические методы визуализации технических решений и логического контроля проекта.
(Презентация 6)
Сложная система обычно может быть разделена на более простые части — модули. Модульность является важным качеством инженерных процессов и продуктов. Большинство промышленных процессов являются модульными и составлены из комплексов работ, которые комбинируются простыми способами (последовательными или перекрывающимися) для достижения требуемого результата.
Главное преимущество модульности заключается в том, что она позволяет применять принцип разделения задач на двух этапах:
— при работе с элементами каждого модуля отдельно (игнорируя элементы других модулей);
— при работе с общими характеристиками групп модулей и отношениями между ними с целью объединить их в конкретный, более крупный и сложный компонент.
Программные модули решают относительно небольшие функциональные задачи, и каждый реализуется 10—100 операторами языка программирования. Каждый модуль может использовать на входе около десятка типов переменных. Если для решения небольшой функциональной задачи требуется более 100 операторов, то обычно целесообразно проводить декомпозицию задачи на несколько более простых модулей.
Проектирование модулей включает в себя разработку локальных функций и подробных описаний алгоритмов обработки данных; межмодульных интерфейсов; внутренних структур данных; структурных схем передач управления; средств управления в исключительных ситуациях. С их помощью определяются функции: порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а также повторно используемые функции программы.
Комплексы программ — программные продукты создаются для решения сложных задач управления и обработки информации. В комплексы объединяются несколько или десятки функциональных групп программ для решения общей целевой задачи системы. Размеры ПС зачастую исчисляются сотнями модулей, десятками и сотнями тысяч операторов. Встречаются ПС, содержащие до двух-трех десятков структурных иерархических уровней, построенных из модулей.
Структурное проектирование сложных комплексов программ активно развивается на основе концепции и стандартов открытых систем. Применение стандартов открытых систем следует начинать при создании архитектуры исходных модулей мобильных ПС и БД, а далее неукоснительно использоваться при всех процессах ЖЦ. Во всех случаях создание архитектуры модулей и компонентов современных сложных систем целесообразно вести с использованием профилей международных стандартов, значительная часть которых обеспечивает мобильность и возможность повторного использования готовых программных средств и баз данных
Создание современных модулей и компонентов ПС и БД поддерживается методами и инструментальными средствами технологий, методами тестирования и аттестации программ и их интерфейсов, а также стандартизированным составом и содержанием документации на программы и базы данных. Эти методы и средства обеспечивают необходимое качество модулей и компонентов сложных ПС и БД. В результате обеспечена мобильность функциональной части текстов программ, однако они могут требовать доработок интерфейсов для сопряжения с новой средой аппаратного и операционного окружения систем.
(Презентация 7)
Выбор и формирование требований к функциональной пригодности ПС — наиболее ответственная, стратегическая задача начальных этапов технико-экономического обоснования проекта программного продукта, системного проектирования и всего последующего развития его жизненного цикла.
Жизненный цикл ПС можно разделить на две части, существенно различающиеся экономическими особенностями процессов и ресурсов, характеристиками и влияющими на них факторами.
В первой части ЖЦ ПС производятся системный анализ, проектирование, разработка, тестирование и испытания базовой версии программного продукта. Номенклатура работ, их трудоемкость, длительность и другие экономические характеристики на этих этапах ЖЦ существенно зависят от характеристик объекта, технологии и инструментальной среды разработки.
Ориентирами для оценивания необходимых ресурсов трудоемкости, длительности и числа специалистов по крупным этапам работ при создании сложных ПС высокого качества могут служить данные, приведенные ниже в п. 2—4 данного раздела. Максимум трудоемкости и числа специалистов приходится на этапы программирования и тестирования компонентов, когда привлекается основная масса программистов-кодировщиков для разработки компонентов ПС.
Вторая часть ЖЦ, отражающая эксплуатацию, сопровождение, модификацию, управление конфигурацией и перенос ПС на иные платформы, в меньшей степени зависит по величине требуемых ресурсов от функциональных характеристик объекта и среды разработки. Номенклатура работ на этих этапах более или менее определенная, но их трудоемкость и длительность могут сильно варьироваться, в зависимости от массовости и других внешних факторов распространения и применения конкретных версий программного продукта.
Для прогнозирования и планирования любых процессов или характеристик объектов (в частности ПС) используются исходные данные
двух типов:
— функции и номенклатура характеристик самого прогнозируемого объекта или процесса, для которого необходимо спланировать жизненный цикл;
— характеристики прототипов и пилотных проектов, в некоторой степени подобных планируемому объекту, о которых известны реализованные планы и необходимые экономические характеристики уже завершенных аналогичных процессов или объектов.
Совместная, корректная обработка исходных данных этих двух типов позволяет при проектировании оценивать и получать новые, прогнозируемые характеристики процессов, планов и экономических показателей создания ПС. Исходные данные первого типа отражают характеристики конкретного создаваемого объекта или процесса, доступные методы и инструментальные средства автоматизации труда при их создании. Эти данные последовательно детализируются и уточняются в процессе проектирования и дальнейшего ЖЦ ПС, что, в частности, позволяет уточнять выбор компонентов аналогичных объектов и их характеристик для исходных данных второго типа.
Второй тип исходных данных для обоснования и планирования разработки ПС составляют обобщенный опыт проектирования и экономические характеристики прототипов нового программного продукта. Для достоверного планирования необходимо накопление, обобщение и изучение конкретных данных о реализованных планах, затратах и использованных ресурсах завершенных разработок ПС в различных аспектах. Такие ТЭП и факторы, их определяющие, изучены в процессе обработки значительного статистического материала реальных отечественных и зарубежных проектов программных продуктов и использованы ниже в методиках прогнозирования(см. п. 2 — 4).
(Презентация 7)
Выбор и формирование требований к функциональной пригодности ПС — наиболее ответственная, стратегическая задача начальных этапов технико-экономического обоснования проекта программного продукта, системного проектирования и всего последующего развития его жизненного цикла.
При технико-экономическом обосновании проекта ПС на любом уровне целесообразно применять методы и методики, адекватные целям и этапам его реализации. Следует согласовывать цели оценивания ТЭП с потребностями в информации, способствующей принятию решений для планирования затрат труда и других ресурсов.
При разработке ПС необходимо учитывать, что экономические, временные, вычислительные и другие ресурсы на разработку и весь ЖЦ программ всегда ограниченны и используемые затраты для улучшения каждой характеристики должны учитывать эти ограничения. Для рационального распределения этих ресурсов необходимо знать, как отражается изменение затрат на улучшении каждой характеристики качества ПС.
Основными ресурсами у разработчиков при создании сложных комплексов программ являются: допустимые трудозатраты (стоимость) на разработку ПС с требуемым качеством; время — длительность полного цикла создания программного продукта; необходимое и доступное число специалистов соответствующей квалификации. Потребность в этих ресурсах в наибольшей степени зависит от размера — масштаба и сложности разрабатываемого ПС.
— цели оценивания ТЭП должны быть согласованы с потребностями в информации, способствующей принятию решений на соответствующем этапе проекта ПС;
— достоверность оценок ТЭП должна быть сбалансирована для различных компонентов системы, и величина уровня неопределенности для каждого компонента должна быть примерно одинаковой, если в процессе принятия решения все компоненты имеют одинаковый вес;
— следует возвращаться к предшествующим целям оценивания ТЭП и изменять их, когда это необходимо для ответственных бюджетных решений, принимаемых на ранних этапах и влияющих на следующие этапы.
Практически всегда необходимо время и трудоемкость на:
— первичный системный анализ целесообразности применения ПИК;
— поиск, адаптацию и процессы использования готовых компонентов;
— оценку затрат с учетом стоимости приобретения и адаптации переносимых программ и баз данных;
— интегрирование в новой операционной или внешней среде;
— тестирование и испытания компонентов в комплексе с унаследованными программами.
Накопленный опыт создания ПС и обобщение проведенных исследований позволили выделить четыре основные группы факторов, влияющих на оценки затрат при непосредственной разработке программ:
— факторы, отражающие особенности создаваемого комплекса программ, как объекта разработки, требования к его функциональным характеристикам и к качеству;
— факторы, определяющие организацию процесса разработки комплексов программ и его обеспечение квалифицированными специалистами;
— факторы, характеризующие технологическую среду и оснащенность инструментальными средствами автоматизации процесса разработки программ;
— факторы, отражающие оснащенность процесса создания ПС аппаратурными вычислительными средствами, на которых реализуются комплексы программ и базируются инструментальные системы автоматизации разработки.
(Презентация 7)
В этой методике реализован метод прогноза ТЭП с учетом экспертной оценки минимального числа факторов. Данная методика оценки ТЭП может применяться, когда определены цели и общие функции проекта ПС, сформулированные в концепции и первичных требованиях с досто-верностью около 20—40%. Основная цель оценки ТЭП — подготовить возможность принять обоснованное решение о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требований и предварительного проектирования.
В качестве основных критериев выбора методик прогнозирования ТЭП разработки ПС целесообразно учитывать возможность их использования как на начальных, так и на более поздних этапах разработки.
Если оказывается, что рассчитанные технико-экономические показатели и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны кардинальные решения: либо изменение некоторых ТЭП и выделяемых ресурсов, либо прекращение проектирования данного ПС. Учитывая полноту и достоверность доступных характеристик и требований к проекту ПС, должны быть определены цели и возможная достоверность технико-экономического обоснования продолжения проектирования ПС.
При наличии перечисленных исходных данных и положительной оценке целесообразности экспертного анализа ТЭП проекта может реализовываться методика, состоящая из следующих шагов:
— определение класса, сложности функций проекта программного средства;
— экспертная оценка размера — масштаба, числа строк предполагаемого текста разрабатываемых программ, с учетом размера повторно используемых компонентов и характеристик возможного языка программирования;
— экспертная оценка возможной средней производительности труда специалистов при разработке программ и/или стоимости (и длительности) разработки одной сроки текста программ проекта ПС;
— расчет возможной полной трудоемкости и длительности разработки проекта ПС, а также среднего числа специалистов, необходимых для его реализации;
— обобщение основных технико-экономических по-казателей и полной стоимости разработки проекта ПС, анализ результатов и технико-экономическое обоснование рентабельности продолжения проектирования комплекса программ.
Достоверность прогнозов ТЭП зависит, прежде всего, от точности экспертной оценки исходных данных: размера — масштаба ПС и от достоверности экспертной оценки производительности труда специалистов или оценки стоимости разработки одной строки текста программ (см. таблицу 2). Кроме того, экспертные оценки зависят от компетенции и объективности экспертов, их оптимистичности, пессимистичности, знания существенных особенностей проекта.
Экспертная оценка размера проекта программного средства наиболее сложная задача в этой методике. Приступая к разработке комплекса программ, как в любой профессиональной деятельности, необходимо сначала провести реалистическую оценку возможного масштаба проекта — поставленных целей, ресурсов проекта и выделенного времени. Задача управления масштабом состоит в задании базовых требований, которые включают разбитое на компоненты ограниченное множество функций и требований, намеченных для реализации в конкретной версии проекта.
Экспертная оценка необходимого числа специалистов всех квалификаций рассчитывается путем деления полной трудоемкости разработки ПС на длительность ее реализации. Для примера крупного проекта ПС реального времени, размером 500 тысяч строк, необходимое число специалистов достигает 160 человек, а для относительно небольшого проекта (30 тысяч строк) — в десять раз меньше (16 человек). Аналогично можно получить оценки необходимого числа специалистов на выделенных крупных этапах разработки ПС, что полезно для первичного формирования коллектива и оценки возможности реализации им конкретного проекта ПС
Экспертная оценка длительности разработки сложных ПС (таблица 3), может базироваться на формулах модели СОСОМО. Основой для расчета длительности целесообразно использовать рассчитанную ранее трудоемкость разработки проекта ПС, от которой не линейно зависит длительность (месяцы), приблизительно равная трудоемкости (человеко-месяцы) в степени 0,3. Например, крупные проекты ПС реального времени размером около 500 тысяч строк требуют для реализации около 3,5 лет, а небольшие (30 тысяч строк) — около одного года. При этом следует учитывать, что необходимая численность коллектива специалистов изменяется в десяток раз.
Экспертные оценки удельных затрат на строку текста программ относятся к полному циклу разработки крупных комплексов программ, начиная от создания концепции и требований до завершения испытаний и передачи программного продукта заказчику или пользователям, с учетом всего состава коллектива специалистов всех квалификаций. По мнению некоторых специалистов, несмотря на появление новых методов и инструментальных средств разработки сложных ПС, средняя производительность при их создании за последние двадцать лет осталась почти неизменной и составляет около 3000 строк кода на одного разработчика проекта в год (порядка 250 строк на человеко-месяц).
(Презентация 8)
Обобщенные оценки технико-экономических показателей проекта ПС целесообразно представлять в виде таблиц с указанием достоверности оценок результатов расчетов. На основе анализа результатов и оценивания рассчитанных характеристик следует выполнять заключительное технико-экономическое обоснование проекта ПС и определять:
— целесообразно ли продолжать работы над конкретным проектом ПС в направлении детализации требований, функций и технико-экономических характеристик или следует его прекратить вследствие недостаточных ресурсов специалистов, времени или возможной стоимости и трудоемкости разработки;
— при наличии достаточных ресурсов, следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта ПС и создания программного продукта для поставки на рынок;
— достаточно ли полно и корректно формализованы концепция и требования к проекту ПС, на основе которых проводились расчеты ТЭП, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными;
— есть ли возможность применить готовые повторно используемые компоненты ПС, в каком относительном размере от всего комплекса программ, и рентабельно ли их применять в конкретном проекте ПС или весь проект целесообразно разрабатывать как полностью новый.
в СОСОМО II для оценки ТЭП представлены две модели — для этапов предварительного и детального проектирования (см. Boehm B.W. et al. Software cost estimation with СОСОМО П. Prentice Hall PTR. New Jersey. 2000).
(Презентация 8)
Обобщенные оценки технико-экономических показателей проекта ПС целесообразно представлять в виде таблиц с указанием достоверности оценок результатов расчетов. На основе анализа результатов и оценивания рассчитанных характеристик следует выполнять заключительное технико-экономическое обоснование проекта ПС и определять:
— целесообразно ли продолжать работы над конкретным проектом ПС в направлении детализации требований, функций и технико-экономических характеристик или следует его прекратить вследствие недостаточных ресурсов специалистов, времени или возможной стоимости и трудоемкости разработки;
— при наличии достаточных ресурсов, следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта ПС и создания программного продукта для поставки на рынок;
— достаточно ли полно и корректно формализованы концепция и требования к проекту ПС, на основе которых проводились расчеты ТЭП, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными;
— есть ли возможность применить готовые повторно используемые компоненты ПС, в каком относительном размере от всего комплекса программ, и рентабельно ли их применять в конкретном проекте ПС или весь проект целесообразно разрабатывать как полностью новый.
Для более точного технико-экономического обоснования проектов ПС при детальном проектировании обычно целесообразно учитывать влияние ряда дополнительных факторов из четырех групп, что позволяет повысить достоверность прогнозирования технико-экономических показателей ПС до уровня около 5—10%.
В детальной модели СОСОМО II влияние на трудоемкость определяют 22 фактора, из которых пять — масштабные факторы, характеризуются множителем в значении степени размера ПС, а 17 множителей непосредственно изменяют трудоемкость разработки. Перечень, максимальные значения и содержание этих множителей представлены в таблице 8. При этом номинальными (средними) ниже принимаются все, при которых соответствующий фактор практически не влияет на трудоемкость ПС.
Для выполнения оценок трудоемкости разработки (человеко-месяцы) в детальной модели СОСОМО II предложены выражения, уточняющие зависимости.
В модели СОСОМО II поддерживаются вероятностные диапазоны оценок, представляющие одно стандартное отклонение на фоне наиболее достоверных оценок. При использовании представленных выражений для прогнозирования ТЭП конкретных проектов следует выбирать набор факторов (калибровать модель), имеющих наибольшие значения коэффициентов изменения трудоемкости (КИТ) и в соответствии с характеристиками конкретного проекта и среды разработки и вставлять выбранные значения в таблицу 8. Значения этих коэффициентов и уровни оценок их влияния на трудоемкость по основным выделенным группам факторов представлены в модели СОСОМО II.
В модели СОСОМО II поддерживаются вероятностные диапазоны оценок, представляющие одно стандартное отклонение на фоне наиболее достоверных оценок.
При калибровке модели СОСОМО II последовательно выполняются следующие процедуры для конкретного проекта:
— выбирается набор факторов, оказывающих наибольшее влияние на прогнозируемую трудоемкость проекта ПС;
— устанавливаются значения масштабных факторов;
— для каждого из выбранных факторов производится оценка коэффициента изменения трудоемкости для анализируемого проекта ПС.
Проекты программных средств разли-чаются по уровню сложности,масштабу и необходимому качеству. Они имеют различное назначение, содержание и относятся к разным областям применения. Поэтому существует потребность в четко организованном процессе, методах формализации и управления требованиями к конкретным программным продуктам.
разработкой ПС должны заниматься хорошо организованные и обученные коллективы — команды разработчиков.
Команда должна применить методы и процессы для того, чтобы понять решаемую проблему заказчика до начала разработки ПС. Для этого следует использовать метод анализа, выявления и освоения проблемы и интересов заказчика:
— достигнуть соглашения между заказчиком и разработчиком по определению проблемы, целей и задач проекта;
— выделить основные причины — проблемы, являющиеся ее источниками и стоящие за основной проблемой проекта системы и ПС;
— выявить заинтересованных лиц и пользователей, чьи коллективное мнение и оценка в конечном итоге определяют успех или неудачу проекта;
— определить, где приблизительно находятся область и границы возможных решений проблем;
— понять ограничения, которые будут наложены на проект, команду и решения проблем.
В результате необходимо предложить заказчику возможные решения рассматриваемой проблемы. Для анализа проблемы можно использовать разнообразные методы. В частности, моделирование бизнес-процессов, специальный метод анализа проблем, который достаточно хорошо зарекомендовал себя для сложных информационных систем, осуществляющих поддержку ключевых инфраструктур. Выявленные на данном этапе прецеденты могут позднее применяться для определения совокупности требований к ПС.
Методы системного анализа позволяют осуществить разбиение сложной системы на подсистемы. Этот процесс помогает понять, каким общим целям должно служить ПС. При этом часто оказывается, что в чем-то усложняются требования, создавая новые подсистемы, для которых, в свою очередь, нужно заниматься разработкой и пониманием требований.
— интервьюирования и анкетирования — создание структурированного интервью; проведение интервью с 5—15 пользователями и/или заинтересованными лицами; подведение итогов совокупности интервью, формулирование 10—15 наиболее часто упоминавшихся потребностей заказчика и пользователей;
— совещания, посвященные анализу и синтезу требований — формулирование и определение целей программного продукта; ознакомление с ними всех участников проекта и установление, что они с ними согласны; если это не так, следует остановиться и уточнениями добиться согласия; обязательно убедиться в согласии заказчиков;
— мозговой штурм и отбор идей, чтобы: выявить и/или уточнить функции проекта; отсечь нецелесообразные идеи; провести классификацию функций, чтобы определить приоритеты, риски, трудоемкости реализации функций;
— анализ иллюстративных прецедентов в приложении к концепции требований (или системному проекту), чтобы их функции были наглядны и понятны;
— по возможности выявление или создание временных прототипов на основе первичных требований.
Для сложных систем требуются стратегии управления информацией о требованиях. Для этого применяется информационная иерархия; она начинается с потребностей пользователей, писанных с помощью функций, которые затем превращаются в более подробные требования к ПС, выраженные посредством прецедентов или традиционных форм описания и стандартизированных характеристик. Эта иерархия отражает уровень абстракции при рассмотрении взаимосвязи области проблемы и области решения. Концепцию требований, модифицированную в соответствии с конкретным содержанием комплекса программ, необходимо иметь в каждом проекте.
В требованиях к ПС следует указывать, какие функции должны осуществляться, а не то, как они могут реализоваться
Без лидера руководителя проекта, который будет утверждать требования к ПС, согласовывать и поддерживать потребности заказчика и команды разработчиков, нельзя быть уверенным в том, что будут приняты необходимые четкие, скоординированные решения.
В требованиях должны быть полно и сжато зафиксированы потребности пользователей в таком виде, чтобы разработчик мог построить удовлет-воряющее их ПС и его компоненты.
При планировании, разработке и реализации требований к характеристикам качества ПС необходимо в первую очередь учитывать следующие основные факторы:
— функциональную пригодность (функциональность) конкретного проекта ПС;
— возможные конструктивные характеристики качества комплекса программ, необходимые для улучшения функциональной пригодности;
— доступные ресурсы для создания и обеспечения всего жизненного цикла ПС с требуемым качеством.
Поэтому при средней и относительно невысокой сложности ПС во многих случаях можно удовлетвориться подготовкой требований к качеству с подробностью анализа, соответствующей системному проектированию. Для крупномасштабных и особо сложных проектов необходимы более детальный анализ факторов при разработке требований и их оптимизация по критерию качество/затраты. Поэтому на этапах проектирования последовательно
должны определяться требования:
— при проектировании концепции — предварительные требования к назначению, функциональной пригодности и к номенклатуре необходимых конструктивных характеристик качества ПС;
— при предварительном проектировании — требования к шкалам и мерам применяемых атрибутов характеристик качества с учетом общих ограничений ресурсов;
— при детальном проектировании — подробные требования к атрибутам качества с детальным учетом и распределением реальных ограниченных ресурсов, а также, возможно, их оптимизация по критерию качество/затраты.
В реальных проектах при подготовке требований к качеству ПС могут исключаться этапы проектирования, однако содержание и последовательность работ по анализу и детализации требований к характеристикам и атрибутам качества целесообразно сохранять.
Эти требования закрепляются в контракте и техническом задании, по которым разработчик впоследствии должен отчитываться перед заказчиком при завершении проекта или его версии.
Состав концепции основных требований к программному средству:
— описание обобщенных результатов обследования и изучения существующей системы и внешней среды;
— описание целей, назначения программного продукта и потребностей заказчика и потенциальных пользователей в заданной среде применения;
— перечень базовых стандартов предполагаемого проекта программного продукта;
— общие требования к характеристикам комплекса задач ПС:
• цели создания программного продукта и назначение комплекса функциональных задач;
• перечень объектов среды применения ПС (технологических объектов управления, подразделений предприятия и т. п.), при управлении которыми должен решаться комплекс задач;
• периодичность и продолжительность решения комплекса задач;
• связи и взаимодействие комплекса задач с внешней средой и другими компонентами системы;
• распределение функций между персоналом, программными и техническими средствами при различных ситуациях решения требуемого комплекса функциональных задач;
— требования к входной информации:
• источники информации и их идентификаторы;
• перечень и описание входных сообщений (идентификаторы, формы представления, регламент, сроки и частота поступления);
• перечень и описание структурных единиц информации входных сообщений или ссылка на документы, содержащие эти данные;
— требования к выходной информации:
• потребители и назначение выходной информации;
• перечень и описание выходных сообщений;
• регламент и периодичность их выдачи;
• допустимое время задержки решения определенных задач;
— описание и оценка преимуществ и недостатков разработанных альтернативных вариантов функций в концепции создания проекта ПС;
— сопоставительный анализ требований заказчика и пользователей к программному продукту и набора функций в концепции ПС для удовлетворения требований заказчика и пользователей;
— обоснование выбора оптимального варианта требований к содержанию и приоритетам комплекса функций ПС в концепции;
— общие требования к структуре, составу компонентов и интерфейсам с внешней средой;
— ожидаемые результаты и возможная эффективность реализации выбранного варианта требований в концепции ПС;
— ориентировочный план реализации выбранного варианта требований концепции ПС;
— общие требования к составу и содержанию документации проекта ПС;
— оценка необходимых затрат ресурсов на разработку, ввод в действие и обеспечение функционирования ПС;
— предварительный состав требований, гарантирующих качество применения ПС;
— предварительные требования к условиям испытаний и приемки системы и ПС.
Спецификация требований к системе и к комплексу программ на этапе детального проектирования:
— требования проекта системы к комплексу программ, как к целому в общей архитектуре системы;
— требования к унификации интерфейсов и базы данных комплекса программ;
— требования и обоснование выбора проектных решений уровня системы, состава компонентов системы, описание функций системы и ПС с точки зрения пользователя;
— спецификация требований верхнего уровня комплекса программ, производные требования к компонентам ПС и требования к интерфейсам между системными компонентами, элементами конфигурации ПС и аппаратуры;
— описание распределения системных требований по компонентам ПС с учетом требований, которые обеспечивают заданные характеристики качества;
— требования к архитектуре системы, содержащей идентификацию и функции компонентов системы, их назначение, статус разработки, аппаратные и программные ресурсы;
— требования совместного целостного функционирования компонентов ПС, описание и характеристики их динамических связей;
— требования анализа трассируемости функций компонентов программного средства к требованиям проекта системы;
— требования для системы или/и подсистем и методы, которые должны быть использованы для гарантии того, что каждое требование к комплексу программ будет выполнено и прослеживаемо к конкретным требованиям системы
• к режимам работы;
• к производительности системы;
• к внешнему и пользовательскому интерфейсу системы;
• к внутреннему интерфейсу компонентов и к внутренним данным системы;
• по возможности адаптации ПС к внешней среде;
• по обеспечению безопасности системы, ПС и внешней среды;
• по обеспечению защиты, безопасности и секретности данных;
• ПО ограничениям доступных ресурсов проекта ПС;
• по обучению и уровню квалификации персонала;
• по возможностям средств аттестации результатов и компонентов, включающих в себя демонстрацию, тестирование, анализ, инспекцию и требуемые специальные методы для контроля функций и качества конкретной системы или компонента ПС.
Цель планирования жизненного цикла программного средства состоит в выборе и определении способов создания и совершенствования ПС, которые способны удовлетворить требованиям технического задания, спецификаций и контракта, а также обеспечить уровень качества, соответствующий заданным требованиям.
В современных стандартах подчеркивается, что эффективное планирование — определяющий фактор высокого качества всего ЖЦ программного средства, удовлетворяющего требованиям заказчика
Планы, связанные с выполнением процесса, должны содержать описания соответствующих работ и задач, обозначения создаваемых компонентов программного средства и охватывать следующие задачи:
— установление графиков своевременного решения частных задач и всего ПС;
— оценки необходимых трудозатрат на задачи и проект в целом;
— определение ресурсов, необходимых для выполнения задач и проекта;
— распределение задач по исполнителям;
— определение обязанностей исполнителей;
— определение критических ситуаций, связанных с задачами или процессами ЖЦ ПС;
— установление используемых в процессах ЖЦ ПС критериев управления качеством;
— определение затрат, связанных с реализацией каждого процесса;
— обеспечение условий и определение инфраструктуры выполнения процессов ЖЦ ПС.
Должны быть определены обязанности специалистов по подготовке и утверждению (согласованию) планов.
Оценки проекта, используемые при планировании, должны охватывать:
— стоимость реализации соответствующих процессов;
— инфраструктуру обеспечения реализации процессов;
— потребности в ресурсах, включая соответствующее управление и контроль;
— оценку и контроль качества реализации процессов;
— управление риском результатов процессов;
— обеспечение среды программной инженерии проекта ПС;
— задания, выполняемые в каждом процессе и (или) работе.
Администраторы каждого программного проекта должны стремиться по возможности использовать существующую организационную инфраструктуру предприятия.
Планирование является постоянной, повторяющейся работой, при выполнении которой оценивают, уточняют и, при необходимости, корректируют ход проекта
В стандарте ISO 15504 расширены, детализированы задачи и виды деятельности, которые следует отражать в плане управления проектом ПС:
— выбрать модель жизненного цикла программных средств, соответствующую назначению, функциям, величине и сложности проекта;
— определить работы, которые необходимо выполнить по проекту, и возможность достижения целей проекта в рамках существующих ресурсов и ограничений;
— оценить варианты достижения целей проекта и определить, на основе анализа рисков, какая стратегия целесообразна;
— количественно оценить сложность работ и ресурсы, необходимые для их выполнения, рассматривая варианты достижения целей проекта и принимая во внимание существующие риски и возможности, чтобы весь жизненный цикл ПС удовлетворял требованиям заказчика;
— выявить и выбрать элементы человеческих и материальных ресурсов, необходимые для обеспечения и реализации стратегии проекта;
— установить график (исполнители, сроки, ресурсы) выполнения проекта, основываясь на распределении работ, оценках и элементах инфраструктуры;
— выявить конкретных лиц и группы, дающие требуемый вклад в проект, определить им конкретные зоны ответственности и обеспечить то, чтобы обязанности были поняты и приняты, профинансированы и достижимы;
— идентифицировать интерфейсы между элементами проекта, а также с другими проектами и организационными единицами системы;
— определить инструментарий для обеспечения того, чтобы планы проекта были формально разработаны, реализованы, поддержаны и доступны лицам, вовлеченным в проект, обеспечить публикацию планов для специалистов, к которым они относятся;
— использовать упорядоченные методы для того, чтобы регулярно оценивать степень выполнение проекта, принимать меры для корректировки отклонений от плана и предотвращения повторения проблем, выявленных в проекте.
План управления жизненным циклом ПС включает регламентированные стандартами процедуры анализа, проверки и оценки состояния проекта для реализации организационных и управляющих воздействий на компоненты и ПС в целом. При этом должны использоваться техническое задание и спецификации требований. Особого внимания потребителя требует сотрудничество с разработчиком-поставщиком, своевременное предоставление ему нужной информации и решение оперативных вопросов для обеспечения качества ПС.
Целесообразно планировать либо регулярно проводить разработчиком и заказчиком совместный анализ состояния проекта либо такие анализы в случае значительных проектных событий
План верификации и тестирования ПС является предварительным описанием организации процедур тестирования, удовлетворяющих цели достижения заданной корректности программ.
План сопровождения и управления конфигурацией ПС устанавливает методы, используемые для сопровождения программных средств и их компонентов в течение всего жизненного цикла
Цель планирования технологической среды жизненного цикла ПС состоит в том, чтобы определить методы, инструментальные средства, процедуры, языки программирования и аппаратные средства, которые будут использоваться и совершенствоваться для разработки, верификации, управления и подготовки документации программного средства.
Все перечисленные планы должны иметь в своем составе предварительные графики, идентифицирующие: этапы работ; входные, выходные данные и описания решаемых задач; необходимые ресурсы, длительность и сроки выполнения; взаимосвязи этапов и работ
Анализ состояния и результатов проекта следует официально планировать и регулярно проводить на соответствующих этапах ЖЦ ПС.
при проектировании ПС планирование процессов управления качеством ПС целесообразно отделять от непосредственного планирования и управления процессами создания и совершенствования крупных комплексов программ. Это позволяет сосредоточить внимание выделенных специалистов на совокупности мероприятий, гарантирующих качество конечного продукта. Чтобы такие гарантии достигались при минимальных затратах, необходимы целенаправленное, координируемое планирование и управление для предотвращения ошибок проектирования, а также для выявления и устранения дефектов проекта на самых ранних этапах разработки.
В соответствии со стандартами процедуры управления качеством должны применяться к различным документам и данным, включая: контрактные документы; процедурные документы, описывающие процессы системы качества; состояние работ поставщика-разработчика; взаимодействие поставщика и заказчика; документы и данные, которые описывают конкретный программный продукт.
Для этого в общем случае должны быть выделены руководители и коллектив специалистов, которые должны планировать, создавать, утверждать и сопровождать комплекты документов. Они должны стимулировать разработчиков ПС осуществлять непрерывное, регламентированное документирование процессов и результатов своей деятельности, а также контролировать полноту и качество результирующих и отчетных документов.
Организационной основой управления качеством ПС на базе стандартов ЖЦ является план обеспечения заданных характеристик качества на всех этапах жизненного цикла комплекса программ. Для этого до начала разработки в процессе формирования требований технического задания следует сформулировать основные положения методики обеспечения качества, поэтапных испытаний компонентов и определения достигнутых значений характеристик, допустимых для продолжения работ на следующих этапах
В плане управления качеством ПС должны быть отражены:
— цели управления качеством, номенклатура и требования к значениям характеристик качества, область действия требований и условия их применения;
— методы управления и достижения заданных значений качества; процедуры, которые должны выполняться для каждого процесса и на протяжении всего жизненного цикла ПС; действия, связанные с отчетностью об ошибках, с трассировкой и системой корректирующих действий;
— организация разработчиков и технология создания ПС; утвержденные обязанности специалистов по обеспечению качества, их ответственность и полномочия на утверждение программных компонентов и документов;
— ресурсы, базовые документы и стандарты, используемые для обеспечения качества на всех этапах разработки;
— средства автоматизации разработки, обеспечивающие достижение и измерение заданных свойств и значений характеристик качества;
— структура и содержание отчетных документов, удостоверяющих достижение определенного качества компонентов и ПС в целом на последовательных этапах разработки, а также их соответствие стандартам и требованиям заказчика.
необходимо контролировать требуемые характеристики в процессе разработки, анализировать их адекватность целям проекта и управлять их изменениями в нужном направлении. Активное взаимодействие разработчиков с заказчиком или потенциальными пользователями на всех этапах разработки позволяет уточнять, корректировать и детализировать совокупность спецификаций требований и атрибуты качества в соответствии с развитием концепции и возрастанием понимания задач проекта как заказчиком, так и разработчиком.
В общем случае в процессе планирования и управления качеством ПС следует учитывать:
— анализ контракта и спецификаций требований заказчика к ПС, выделение и ранжирование приоритетов характеристик и атрибутов качества конечного продукта;
— декомпозицию требований к характеристикам качества по контролируемым этапам и компонентам разработки и создание разделов по детальным требованиям к атрибутам качества в спецификациях на программные компоненты и ПС в целом;
— выбор или создание методов, технологии и инструментальных средств автоматизации разработки, обеспечивающих создание ПС и его компонентов с требуемыми характеристиками качества;
— разработку методик контроля соблюдения стандартов, правил технологии проектирования и системы обеспечения качества жизненного цикла программных средств;
— создание методов, методик и средств объективного измерения свойств и/или значений атрибутов характеристик качества программных компонентов на этапах их создания и всего ЖЦ ПС для испытаний заказчиком и эксплуатации пользователями;
— организацию, обучение и стимулирование коллектива специалистов на создание компонентов и ПС в целом, в максимальной степени удовлетворяющих требования заказчиков и пользователей к характеристикам качества.
В результате успешной реализации процессов в проекте должно быть обеспечено:
— на основе явных и неявных требований потребителя необходимо определить цели по качеству продукта и процессов, которые следует оценивать, предпочтительно количественным образом, для различных контрольных точек в жизненном цикле ПС;
— определить общую стратегию на уровне проекта ПС и предприятия, помогающие аттестовать достижение соответствующих целей по качеству, определяя количественную меру результатов деятельности по проекту и критерии их приемки;
— для каждой цели по качеству ПС идентифицировать виды деятельности по контролю и обеспечению качества, помогающие достижению этой цели и ее мониторингу как на уровне проекта, так и на уровне предприятия, и интегрировать эти виды деятельности в жизненный цикл ПС;
— проводить идентифицированные виды деятельности по контролю и обеспечению качества и подтверждать их выполнение;
— по ходу реализации проекта в контрольных точках жизненного цикла ПС применять заданные метрики качества для аттестации достижения соответствующих целей по качеству;
— в случаях, когда заданные цели по качеству не достигаются, применять корректирующие или предотвращающие мероприятия, которые могут включать либо исправление продукта, либо изменение запланированного набора видов деятельности для лучшего достижения целей по качеству, либо изменение спецификации требований продукта или определения процесса для предотвращения повторения дефектов.
Объектно-ориентированное проектирование (ООП) предназначено организовывать программные системы с большими базами данных на основе описаний объектов реального мира, важных для пользователей. Этот подход существенно отличается от структурного проектирования, которое акцентировано на сложные функции и процессы обработки данных. Объекты реального мира, существующие внутри области действия ООП программных проектов, определяются в терминах целей, характеристик и ответственностей поведения соответствующих данных (атрибутов) и отношений с другими многочисленными объектами. Все функции при этом скрыты внутри деталей описаний объекта.
Объектно-ориентированное проектирование пред-ставляет собой стратегию, в рамках которой про-граммная система состоит из взаимодействующих объектов, имеющих собственное локальное состояние и способных выполнять определенный набор операций, определяемый состоянием объекта. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Под процессом ООП подразумевается проектирование классов объектов и взаимоотношений между этими классами. Объектно-ориентированные системы можно рассматривать как совокупность автономных и в определенной степени независимых объектов.
Изменение реализации какого-нибудь объекта или добавление новых функций не влияет на другие объекты системы.
Общий процесс объектно-ориентированного проектирования состоит из нескольких крупных этапов:
— определение рабочего окружения системы и разработка моделей ее использования;
— проектирование архитектуры программной системы;
— определение и идентификация основных объектов системы;
— разработка модели архитектуры комплекса программ;
— определение и документирование интерфейсов объектов.
Главное преимущество ООП программных средств состоит в том, что оно упрощает задачу внесения изменений в системную архитектуру, поскольку представление состояния объекта не оказывает на нее влияния. Изменение внутренних данных объекта не должно влиять на другие объекты системы. Более того, так как объекты слабо связаны между собой, обычно новые объекты просто вставляются без значительных воздействий на остальные компоненты системы.
Основные понятия ООП включают:
— при объектно-ориентированном проектировании основные компоненты программной системы представляются как объекты со своими состояниями и операциями;
— объекты предоставляют сервисы (методы) другим объектам и создаются в реальном времени на основе определения класса объектов;
— объекты могут быть реализованы последователь-но и параллельно, параллельный объект может быть пассивным, у которого состояние изменяется только через его интерфейс, или активным, который может изменять свое состояние без вмешательства извне;
— в процессе объектно-ориентированного проектирования возможно создание ряда различных моделей, которые можно разделить на статические (модели классов, модели обобщения, модели агрегирования) и динамические (модели последовательностей, модели конечного автомата);
— важным преимуществом объектно-ориентированного проектирования является то, что он упрощает процесс модификации системы.
ООП — только часть объектно-ориентированного процесса разработки системы, где на протяжении всего процесса создания ПС используется объектно-ориентированный метод. Этот подход подразумевает выполнение трех этапов:
— объектно-ориентированный анализ — создание модели предметной области приложения ПС, где объекты отражают реальные объекты - сущности, а также определяются операции, выполняемые объектами;
— объектно-ориентированное проектирование — разработка модели системы ПС и системной архитектуры с учетом системных требований, в которой определение всех объектов подчинено решению конкретной задачи;
— объектно-ориентированное программирование — реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (например, Java), непосредственно выполняющего отражение определенных объектов и предоставляющего средства для определения классов объектов.
При ООП основное внимание уделяется тому, что следует делать, каким образом добиться цели, а процесс ее достижения целиком зависит от этапа разработки.
В программных средствах при ООП рекомендуется выделять три уровня:
— уровень интерфейсов, который занимается всеми взаимодействиями с другими частями системы и предоставлением внешних интерфейсов системы;
— уровень сбора данных, управляющий сбором информации из внешней среды и обобщающий данные перед отправкой их в систему построения обобщенных результатов;
— уровень объектов, в котором представлены и описаны все объекты, используемые в процессе сбора исходных данных.
Класс представляет собой абстракцию в предметной области приложения, в общем случае выраженную существительным. Абстракция может быть концептуальной или физической: она отражает возможности системы по хранению информации о ней, по взаимодействию с ней или же оба эти фактора. Класс включает: атрибуты (данные, описывающие объект, а также тот объем информации об объекте, который хранится в системе); отношения с другими классами и операциями (поведение данного объекта, которое и описывает соответствующие ответственности).
Классы имеют свойства, структуру, поведение и отличаются независимостью существования
Объект является отдельным (особенным) экземпляром класса. Объекты — это исполняемые сущности с атрибутами и сервисами класса объектов. Объекты представляют собой реализацию класса, на основе одного класса можно создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточено на классах объектов и их отношениях. Во всех случаях применяется общее правило, согласно которому объект инкапсулирует данные о своем внутреннем строении.
Объект — это сущность, способная пребывать в различных состояниях и имеющая определенное множество операций
Интерфейсом называется набор операций, характеризующих поведение элемента.
Один и тот же объект может иметь несколько интерфейсов
Сообщения — содержат объект назначения (включающий операцию, предназначенную для выполнения), название выполняемого оператора и параметры, которые необходимы для выполнения операции.
Модели систем, разрабатываемые при формирова-нии требований, должны отображать реальные сущ-ности, принадлежащие классам объектов. Все объек-ты связаны с различными уровнями в архитек-туре системы.
Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением. Модель окружения системы — это статическая модель, которая описывает другие системы из окружения разрабатываемого ПС. Модель использования системы — динамическая модель, которая показывает взаимодействие данной системы со своим окружением. Модель окружения системы можно представить с помощью схемы связей, которая дает простую блок-схему общей архитектуры системы. С помощью пакетов языка UML ее можно представить в развернутом виде как совокупность подсистем.
Объектные модели, разработанные для формирования требований, могут использоваться как для представления данных, так и для процессов их обработки. В этом отношении они объединяют модели потоков данных и семантические модели данных. Они также полезны для классификации системных сущностей и могут представлять сущности, состоящие из других сущностей. Для некоторых классов систем объектные модели — естественный способ отображения реально существующих объектов, которые находятся под управлением системы
Модели данных — больших программных систем используют информационные базы данных. В одних случаях эта база данных существует независимо от программной системы, в других — специально создается для разрабатываемой системы. Важной частью моделирования систем является определение логической формы данных, обрабатываемых системой. Наиболее широко используемой методологией моделирования данных является моделирование типа «сущность — связь — атрибут», которое показывает структуру данных, их атрибуты и отношения между ними
Существует два типа объектно-ориентированных моделей системной архитектуры:
— статические модели, которые описывают структуру системы в терминах классов объектов и взаимоотношений между ними, которые документируются на данном этапе, являются отношениями обобщения, отношениями «используют — используются» и структурными отношениями;
— динамические модели, которые описывают структуру системы и показывают динамические взаимодействия между объектами системы (но не классами объектов), — документируемые взаимодействия содержат последовательность составленных объектами запросов к сервисам и описывают реакцию системы на взаимодействия между объектами.
В языке моделирования UML поддерживается ряд возможных статических и динамических моделей:
— модели подсистем, которые показывают логически сгруппированные объекты, они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет, и является статическим;
— модели последовательностей, которые показывают взаимодействия между объектами, они представляются в UML с помощью диаграмм последовательности или кооперативных диаграмм — динамические модели;
— модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события, в UML они представлены в виде диаграмм состояния — динамические модели.
Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов.
Статическое представление объектно-ориентированного анализа — представляет собой диаграмму класса, а также диаграмму объекта для представления определенного экземпляра класса, куда входят компоненты атрибутов, служб и отношений наряду с понятиями, взятыми из иерархии, абстракции, инкапсуляции и наследования. Идентифицируются ответственности классов, затем обработка идет наверх, а для достоверности применяются сценарии вариантов использования. В этом случае реализуется подход снизу-вверх.
Подобный способ достаточно хорош, но существует еще путь сверху-вниз, когда при идентификации классов начинают с практических примеров, а затем продолжается обработка вниз, доходя до сценариев. Если начать с классов, можно сначала идентифицировать их через абстракции. Затем для каждого класса перечисляются ответственности, идентифицируются атрибуты и операции (поведение — снова через абстракцию) и, наконец, обращаются к сценариям вариантов использования для подтверждения диаграммы класса. Однако сначала рассматривается описание диаграмм классов.
Статическое представление объектно-ориентированной разработки проекта — диаграммы взаимодействия и сотрудничества отображают взаимодействия, которые пространственно ориентированы на окружение модели и характеризуют классы и ассоциации (экземпляры и связи). Целью сотрудничества является определение способов реализации вариантов использования. Диаграмма сотрудничества отображает отношения между экземплярами объектов.
В то же время диаграмма на уровне экземпляра отображает экземпляры и связи, которые согласуются с ролями в сотрудничестве. При отображении сотрудничества указывается, какие экземпляры свойств должны принимать участие в сотрудничестве, т.е. каждый участник указывает необходимые свойства, которыми должен обладать согласуемый экземпляр.
Динамическое представление объектно-ориентированного проектирования — диаграммы взаимодействия и последовательные диаграммы демонстрируют взаимодействие, отображенное в динамике. В ней отображаются экземпляры, участвующие во взаимодействии с помощью соответствующих линий жизни, а также входные сигналы, которыми они обмениваются. Эти сигналы собраны во временную последовательность. В отличие от диаграммы сотрудничества, последовательная диаграмма включает временные последовательности, но не содержит объектных отношений.
Последовательная диаграмма может существовать в общей форме (описывать все возможные сценарии) и в форме экземпляра (описывать один действительный сценарий). Последовательные диаграммы и диаграммы сотрудничества выражают подобную информацию, однако используют различные способы. Последовательная диаграмма имеет две размерности:
Общее понятие — доступные ресурсы обеспечения жизненного цикла ПС — включает реальные финансовые, временные, кадровые и аппаратурные ограничения затрат, в условиях которых происходит создание и совершенствование комплексов программ. В зависимости от характеристик объекта разработки на ее выполнение выделяются ресурсы различных видов и размеров. В результате доступные ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов разработки Наиболее общим видом ресурсов, используемых в жизненном цикле ПС, являются допустимые финансово-экономические затраты или эквива-лентные им величины трудоемкости соответствую-щих работ Затраты в жизненном цикле ПС определяются не только этапами разработки, но и этапами эксплуатации и сопровождения
Разработка сложного ПС требует во много раз больших затрат, чем производство каждого экземпляра при массовом тиражировании. Поэтому далее производство базового образца программ не выделяется в самостоятельный этап, а рассматривается совместно с процессом разработки ПС. Производство серийных образцов программного продукта включается в этап эксплуатации.
При выделении составляющих затрат на разработку программ целесообразно учитывать их относительный вес в суммарных затратах и возможность локализации групп специалистов, влияющих на величину этих затрат. Поэтому для измерения затрат наиболее универсальной единицей стала трудоемкость в человеко-месяцах или человеко-годах. Доступные разработчикам ПС вычислительные ресурсы объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС.
Разработка ПС характеризуется высокой долей творческого труда, особенно на начальных и завершающих этапах. Поэтому трудоемкость и длительность отдельных операций, частных работ и качество результатов при проектировании существенно зависят от индивидуальных особенностей относительно небольшого числа руководителей и исполнителей, а также от характеристик конкретного проекта.
Отсюда принципиальной особенностью создания сложных комплексов программ является необходимость активного участия руководителей и заказчиков проекта в системном анализе, итерационном экономическом оценивании затрат ресурсов и уточнении планов на базе прототипов завершенных разработок ПС и их личного опыта.
Важнейшим ресурсом при создании программных средств являются люди — специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество комплексов программ привели к появлению новых требований к специалистам программной инженерии, обеспечивающим все этапы жизненного цикла ПС.
Теперь недостаточно навыков процедурного программирования небольших компонентов, а необходимы глубокие знания системотехники, технологии проектирования, методов обеспечения и контроля качества сложных комплексов программ в определенной области применения. Эти специалисты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество ЖЦ программных средств, а также контроль, испытания и удостоверение реального достигнутого качества на каждом этапе разработки и совершенствования программ.
С другой стороны, разработчики должны иметь в своем составе квалифицированных менеджеров, проблемно-ориентированных системных архитекторов (рис.2), способных переводить функциональные требования заказчика в конкретные спецификации и технические требования к комплексу программ и его компонентам.
Специалисты по проектированию сложных ПС (системные архитекторы) должны иметь, прежде всего, хорошую подготовку по системному анализу алгоритмов и пакетов прикладных программ, по методам оценки эффективности проектов, организации и планированию крупномасштабных разработок программ и баз данных. Им необходима высокая квалификация по архитектурному построению, комплексной отладке и испытаниям ПС определенных классов, умение организовать коллектив для решения общей целевой задачи системы. Это позволит на ранних этапах исключать или сокращать дефекты, обусловленные различием представления ими целей и задач проектов, а также их показателей качества.
Однако в программной инженерии неуклонно повышается сложность создаваемых ПС, что вызывает возрастание затрат творческого труда на единицу размера программ. В перспективе, несмотря на автоматизацию и повышение инструментальной оснащенности технологии разработки программ, доля творческого труда при создании полностью новых крупномасштабных ПС возрастает.
Для реализации сложных проектов ПС наиболее часто применяются две схемы организации коллективов специалистов:
— формирование для выполнения каждого проекта жесткой организационной структуры целостного коллектива с полным составом необходимых специалистов под единым, централизованным руководством лидера проекта;
— выделение руководителя (главного конструктора) и небольшой группы интеграторов, по заданиям которых выполняются частные работы узкими специалистами по компонентам, не входящими организационно в единый коллектив для реали-зации каждого конкретного крупного проекта.
Первая схема предпочтительна, когда фирма реализует небольшое число особенно крупных проектов-заказов и имеет возможность для каждого из них скомплектовать полноценную, организационно замкнутую, «команду». Она полностью реализует проект и несет ответственность за его качество. Однако при этом возможны простои отдельных специалистов из-за несинхронного ожидания заданий или результатов последовательных этапов проектирования компонентов другими специалистами.
Практически в каждом успешном проекте должен быть или был лидер. Лидером продукта может быть: менеджер продукта, менеджер проектирова-ния, руководитель проекта
Таблица 1. Характеристики и влияние коллективизма разработчиков программных средств на трудоемкость
При проектировании ПС необходимо учитывать, что экономические, временные, вычислительные и другие ресурсы на разработку и весь ЖЦ программ всегда ограниченны и используемые затраты для улучшения каждой характеристики должны учитывать эти ограничения. Для рационального распределения этих ресурсов необходимо знать, как отращивается изменение затрат на улучшении каждой характеристики качества ПС.
Обеспечение функциональной пригодности является основной целью при использовании финансовых, трудовых, вычислительных и других ресурсов в жизненном цикле ПС. Однако это не значит, что затраты на решение этой основной задачи всегда являются доминирующими по величине. Необходимость выполнения ряда требований к остальным, конструктивным характеристикам качества часто приводит к тому, что использование ресурсов на их реализацию может превышать базовые затраты на обеспечение функциональной пригодности.
Для анализа затрат ресурсов в жизненном цикле ПС при проектировании их целесообразно разделить на две части:
— затраты на создание программных компонентов, обеспечивающих базовые свойства функциональной пригодности комплекса программ для его применения по прямому назначению пользователями, в соответствии с требованиями контракта и технического задания;
— основные составляющие дополнительных затрат, обеспечивающие требуемые конструктивные характеристики качества для улучшения функциональной пригодности ПС в соответствии с целями и сферой его применения.
Затраты на обеспечение функциональной пригодности зависят, в первом приближении, от сложности алгоритмов, объема комплекса программ и баз данных, которые определяют затраты труда и длительность полного цикла их разработки. Основные затраты идут на овеществленный, преимущественно интеллектуальный, труд специалистов различных категорий. Поэтому для их измерения наиболее универсальной единицей стали трудозатраты специалистов в человеко-днях или человеко-месяцах, которые обычно достаточно просто могут преобразовываться в стоимость процесса разработки.
наиболее сильно отличающиеся затратами на функциональную пригодность, при одном и том же общем размере полностью новых программ и информации баз данных, которые характеризуются:
— максимальной трудоемкостью — ПС систем управления динамическими объектами или процессами в реальном времени (СРВ);
— средней трудоемкостью — ПС административных, организационных и информационно-поисковых систем (ИПС);
— минимальной трудоемкостью создания — пакеты автономных расчетных прикладных программ (ППП).
Крупные затраты, достигающие 30% от полных затрат на разработку сложных ПС, могут приходиться на верификацию и тестирование программных компонентов, что должно обеспечивать корректность и надежность ПС в целом
Затраты на квалификационное тестирование и испытания ПС в целом обычно могут быть достаточно четко выделены из остальных ресурсов, так как в этих процессах непосредственно участвуют заказчик и пользователи. Величина этих затрат, без учета ресурсов, необходимых для имитации внешней среды, может составлять около 10% от общих затрат на разработку
Затраты на обеспечение безопасности и надежности функционирования ПС
Затраты на обеспечение высокой надежности в составе разработки ПС
Затраты на создание достаточно полного комплекта документации
— дополнительные затраты на обеспечение высокой надежности ПС могут достигать 2—3-кратного увеличения затрат относительно функциональной пригодности при требованиях наработки на отказ в десятки тысяч часов, а для минимального обеспечения автоматического рестарта в ординарных системах составляют порядка 10—20%;
— для повышения эффективности использования ресурсов ЭВМ затраты могут быть относительно невелики (несколько процентов) и их трудно выделить из затрат на решение основных, функциональных задач;
— затраты на обеспечение практичности зависят в основном от сложности применения ПС, от качества и количества эксплуатационной документации и электронных учебников и могут составлять до 20% затрат на решение основных, функциональных задач.
Поэтому необходим системный анализ распределения и использования ресурсов на разработку программ с учетом всего их жизненного цикла, включая сопровождение и перенос на другие платформы.
Сопровождаемость ПС можно оценивать потребностью трудовых и временных ресурсов для ее обеспечения и для реализации.
Мобильность и затраты конкретных ресурсов для переноса программ и данных на иные аппаратные и операционные платформы при проектировании могут быть учтены только очень приблизительно.
В ряде случаев целесообразна настройка — адаптация готовых компонентов на новые условия применения.
В пределе при построении нового ПС на 80—90% из готовых компонентов суммарные затраты могут сокращаться в 3—5 раз. В этом случае, кроме 10—20% затрат на создание новых программных компонентов, необходимы ресурсы на комплексирование нового ПС, его квалификационное тестирование, испытания и документирование.
Практически всегда необходимы время и трудоемкость на системный анализ и оценивание целесообразности разработки комплекса программ из готовых компонентов с учетом стоимости приобретения и адаптации переносимых программ.
При создании крупных ПС одной из больших составляющих могут быть необходимые ресурсы на генерацию тестов.
Анализ эффективности программной имитации внешней среды при разработке и определении качества ПС целесообразно разделить на две части: оценка факторов, определяющих эффективность средств имитации тестов, и оценка экономического выигрыша при моделировании внешней среды на ЭВМ по сравнению с натурными экспериментами в реальных системах.
Таким образом, затраты на натурные эксперименты для оценивания характеристик ПС определяются использованием всей реальной внешней среды, в которой предстоит в дальнейшем функционировать программам, а также затратами на средства измерения характеристик этой среды и проверяемого ПС в процессе разработки, испытаний и определения качества.
Затраты на программную имитацию тестовых данных определяются ресурсами, необходимыми на проек-тирование и эксплуатацию сложных комплексов про-грамм для этих целей, и следующими составляющими:
— затратами на разработку комплекса программ для имитации информации внешних объектов и среды их функционирования;
— затратами на эксплуатацию программ имитации за время проведения тестирования, испытаний и/или определения характеристик качества тестируемого ПС;
— затратами на первичную установку и эксплуата-цию моделирующей ЭВМ и вспомогательного оборудования, используемого в имитационном стенде.
Источниками ошибок в ПС являются специалисты — конкретные люди с их индивидуальными особеннос-тями, квалификацией, талантом и опытом. При этом можно выделить предсказуемые модификации, расширения и совершенствования ПС и изменения, обусловленные выявлением случайных, непредсказуемых дефектов и ошибок. Вследствие этого плотность потоков и размеры необходимых корректировок в модулях и компонентах при разработке и сопровождении ПС могут различаться в десяток раз.
Однако в крупных комплексах программ статистика и распределение типов выполняемых изменений для коллективов разных специалистов нивелируются и проявляются достаточно общие закономерности
Риски проявляются, как негативные последствия дефектов функционирования и применения ПС, которые способны нанести ущерб системе, внешней среде или пользователю в результате отклонения характеристик объектов или процессов от заданных требованиями заказчика, согласованными с разработчиками.
Риски характеризуют возможные негативные последствия дефектов или ущерб пользователей при применении и функционировании ПС и системы, и задача разработчиков сводится к сокращению
дефектов и ликвидации рисков
Различия между ожидаемыми и полученными результатами функционирования программ могут быть следствием ошибок не только в созданных программах, но и ошибок в первичных требованиях спецификаций, явившихся базой при создании эталонов-тестов.
На практике в процессе ЖЦ ПС исходные требования поэтапно уточняются, модифицируются, расширяются и детализируются по согласованию между заказчиком и разработчиком. Базой таких уточнений являются неформализованные представления и знания специалистов-заказчиков и разработчиков, а также результаты промежуточных этапов проектирования. Однако установить некорректность таких эталонов еще труднее, чем обнаружить дефекты в сопровождаемых программах, так как принципиально отсутствуют формализованные данные, которые можно использовать как исходные.
Важной особенностью процесса выявления ошибок в программах является отсутствие полностью определенной программы-эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы.
Небольшими ошибками называют такие, на которые средний пользователь не обратит внимания при применении ПС вследствие отсутствия их проявления и последствия которых обычно так и не обнаруживаются.
Умеренными ошибками называют те, которые влияют на конечного пользователя, но имеются слабые последствия или обходные пути, позволяющие сохранить достаточную функциональность ПС.
Критические ошибки останавливают выпуск версии программного продукта. Это могут быть ошибки с высоким влиянием, которые вызывают сбой в системе или потерю данных, отражаются на надежности и безопасности применения ПС, с которыми никогда не передается комплекс программ пользователю. По десятибалльной шкале — от 8 до 10-го приоритета.
Изменения характеристик системы и внешней среды, принятые в процессе разработки ПС за исходные, могут быть результатом аналитических расчетов, моделирования или исследования аналогичных систем. В ряде случаев может отсутствовать полная адекватность предполагаемых и реальных характеристик, что является причиной сложных и трудно обнаруживаемых системных ошибок и дефектов развития проекта. Ситуация с такими ошибками дополнительно усложняется тем, что эксперименты по проверке взаимодействия ПС с реальной внешней средой во всей области изменения параметров зачастую сложны и дороги, а в отдельных случаях, при создании опасных ситуаций, недопустимы.
В этих случаях приходится использовать моделирование и имитацию внешней среды с заведомым упрощением ее отдельных элементов и характеристик, хотя степень упрощения не всегда удается оценить с необходимой точностью.
— сложность ошибок изменяемых программных компонентов и модулей определяется конструктивной сложностью модификации оформленного компонента программы и может быть оценена с позиции сложности внутренней структуры и преобразования данных в каждом модуле, а также интегрально по некоторым внешним статистическим характеристикам размеров модулей;
— сложность ошибок корректировок структуры комплекса или компонентов и связей между модулями по передачам управле-ния и по обмену информацией определяется глубиной взаимодействия модулей и регулярностью структуры межмодульных связей;
— сложность ошибок изменения структуры данных определяется количеством и структурой глобальных и обменных переменных в базе данных, регулярностью их размещения в массивах, а также сложностью доступа к этим данным.
Масштаб —размер комплексов программ и их изменяемой части наиболее сильно влияет на количество ошибок, а также на требования к качеству ПС.
Ошибки структуры можно разделить на три категории: пропуски, конфликты и ошибки перевода.
Пропуски означают неспособность включить изменения одного или более требований в окончательную структуру ПС. Когда пропуск новой функции или компонента попадает в окончательную структуру, он станет ошибкой в конечном программном продукте.
Конфликты возникают, когда модификация двух различных, конструктивных свойств имеют конфликтующую структуру. Это может происходить в случае явного конфликта, когда в структуре установлено, что файл может быть открыт двумя разными людьми в одно и то же время, тогда как в базовом классе определяется только однопользовательский доступ. Ошибки, которые основаны на конфликтах на этом уровне, часто невозможно исправить без полного переписывания модулей версии ПС.
Ошибки перевода — наиболее коварные среди всех ошибок структурного уровня. Они проявляются, когда требования заказчика интерпретируются неправильно, по крайней мере, с точки зрения конечного пользователя. Если разработчик структуры либо неверно прочитает требования, либо не увидит содержание требования, так же как конечный пользователь, появится ошибка разработки структуры данного компонента или ПС.
Системные ошибки в ПС определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации.
Алгоритмические ошибки программ трудно поддаются обнаружению методами статического автоматического контроля.
К алгоритмическим ошибкам следует отнести также ошибки интерфейса модулей и функциональных групп программ, когда информация, необходимая для функционирования некоторой части программы, оказывается не полностью подготовленной программами, предшествующими по времени включения, или неправильно передаются информация и управление между взаимодействующими модулями.
Ошибки реализации спецификаций компонентов — это программные дефекты, возможно, ошибки требований, структуры или программные ошибки компонентов
Первую категорию составляют дефекты, которые приводят к отображению для пользователя сообщений об ошибках при точном следовании порядку выполнения требуемых функций. Хотя эти сообщения могут быть вполне законны, пользователи могут посчитать это ошибкой, поскольку они делали все правильно и, тем не менее, получили сообщение об ошибке. Часто ошибки этого типа вызваны либо проблемами с ресурсами, либо специфическими зависимостями от данных.
Вторая категория модификаций может содержать ошибки, связанные с дефектами в графическом интерфейсе пользователя. Такие ошибки могут являться либо нестандартными модификациями пользовательского интерфейса, которые приводят к тому, что пользователь совершает неверные действия, либо они могут быть стандартными компонентами пользовательского интерфейса, используемыми иначе, чем ожидает конечный пользователь.
Третья категория может содержать пропущенные на стадии реализации функции, что всегда считается ошибкой, возможно, с большим риском. Многие тестировщики и пользователи бета-версий сообщают об ошибках, которые на самом деле являются желательными улучшениями. В данном случае можно не замечать обнаруженные таким образом отсутствия функций, которых не было в спецификациях.
Программные ошибки модифицированных компонентов по количеству и типам в первую очередь определяются степенью автоматизации программирования и глубиной статического контроля текстов программ
Ошибки в документации модификаций состоят в том, что система делает что-то одним образом, а документация отражает сценарий, что она должна работать иначе.
Технологические ошибки документации и фиксирования программ в памяти ЭВМ составляют иногда до 10% от общего числа ошибок, обнаруживаемых при тестировании.
Причинами возникновения и проявления рисков могут быть: злоумышленные, активные воздействия заинтересованных лиц или случайные негативные проявления дефектов внешней среды, системы или пользователей.
Специфические факторы обеспечения информационной безопасности и риски, характерные для сложных информационных систем, — целостность, доступность и конфиденциальность информационных ресурсов, а также ряд типовых процедур систем защиты — криптографическая поддержка, идентификация и аутентификация, защита и сохранность данных пользователей при предумышленных атаках из внешней среды далее не рассматриваются.
Риски при случайных, дестабилизирующих воздействиях дефектов программных средств и отсутствии предумышленного негативного влияния на системы, ПС или информацию баз данных существенно отличаются от предшествующих задач. Эти риски объектов и систем зависят от отказовых ситуаций, отрицательно отражающихся на работоспособности и реализации их основных функций, причинами которых могут быть дефекты и аномалии в аппаратуре, программах, данных или вычислительных процессах. При этом катастрофически, критически или существенно искажается процесс функционирования систем, что может наносить значительный ущерб при их применении.
Процессы анализа и сокращения рисков должны сопутствовать основным этапам разработки и обеспечения ЖЦ сложных программных средств в соответствии с международными стандартами, а также методам систем обеспечения качества ПС. Эти процессы могут быть отражены пятью этапами работ и процедур
Таким образом, в жизненном цикле программных средств ущерб — риски могут проявляться
Управления рисками предполагает ясное понимание внутренних и внешних причин и реальных источников угроз, влияющих на качество проекта ПС, которые могут привести к его провалу или большому ущербу. В результате анализа следует создавать план отслеживания изменения рисков в жизненном цикле ПС, который должен регулярно рассматриваться и корректироваться.
Главной целью управления рисками является обнаружение, идентификация и контроль за редко встречающимися ситуациями и факторами, которые приводят к негативным — рисковым результатам проекта. Это должно отражаться на применении регламентированных процессов, в которых факторы и угрозы рисков систематически идентифицируются, оцениваются и корректируются.
Одной из самых распространенных причин и опасных источников рисков являются ошибки при оценке масштаба —размера проекта или программного продукта. Эти ошибки чаще всего бывают случайными — непредумышленными, вследствие недостаточной компетентности заказчика или разработчика-поставщика.
Для продолжения разработки проекта после оценки рисков масштаба комплекса программ необходимо выполнить цикл поэтапного определения и формирования совокупности спецификаций требований к проекту ПС. Первым этапом является создание концепции проекта ПС и комплекса первичных требований к иерархическому набору функций, на которые могут быть разбиты предполагаемые фактические компоненты ПС.
Для устранения или снижения рисков до допустимых пределов может быть необходимо изменение требований к функциональной пригодности, к конструктивным характеристикам и доступным ресурсам. Поэтому на этапах проектирования последовательно должны определяться:
— при проектировании концепции и первичной оценке масштаба проекта — предварительные требования к назначению, функциональной пригодности и к номенклатуре необходимых конструктивных характеристик качества ПС;
— при предварительном проектировании — уточненная оценка масштаба проекта, требования к функциональным и конструктивным характеристикам качества с учетом общих ограничений ресурсов, перечень источников угроз и величины возможных рисков;
— при детальном проектировании — подробные спецификации требований к функциональным и конструктивным характеристикам качества с детальным учетом и распределением реальных ограниченных ресурсов, а также интегральные риски при их оптимизация по критерию качество/затраты.
На этапе создания концепции и системного анализа формируются цели разработки проекта ПС, выбираются методы и алгоритмы решения основных, функциональных задач, а также формулируются предварительные критерии качества создаваемых программ. При этом, естественно, встает вопрос о ресурсах, которые потребуются для достижения целей, и о возможности их реализации. Целенаправленная и методичная экспертная оценка возможного масштаба и ресурсов проекта уменьшает величину риска, однако обычно она остается все-таки довольно большой.
Разработку и утверждение спецификаций требований к функциональным характеристикам и качеству ПС с учетом анализа рисков целесообразно проводить итерационно на этапах предварительного и детального проектирования.
Поэтому при средней и относительно невысокой сложности ПС во многих случаях можно удовлетвориться подготовкой требований к комплексу программ с подробностью анализа, соответствующего предварительному проектированию. Для крупных и особо сложных проектов необходим более детальный анализ факторов и рисков при разработке требований и их оптимизация по критерию качество/затраты.
В зависимости от сложности проекта окончательным результатом работ при предварительном или детальном проектировании должны быть детализированные и утвержденные требования к номенклатуре, свойствам и значениям качества и допустимым рискам проекта ПС, которые достаточны для его полноценного рабочего проектирования и последующей эффективной эксплуатации.
Для этого необходим мониторинг масштаба проекта, требований и реализаций характеристик и рисков в течение всего ЖЦ ПС.
Обычно заказчики и разработчики первоначально устанавливают требования к каждой характеристике ПС без учета относительных затрат на их достижение, а также без детального анализа их совместного влияния на полную функциональную пригодность и риски у потребителей. Это может приводить к значительным перекосам и несбалансированным значениям требований к отдельным, взаимосвязанным характеристикам, на которые нерационально используются ограниченные ресурсы ЖЦ ПС, или к неадекватно низким их значениям.
В проектах крупномасштабных ПС это может угрожать значительным повышением стоимости и рисков и/или снижением конкурентоспособности создаваемого программного продукта из-за недостаточного уровня отдельных показателей качества.
Для управления рисками и детального сопоставительного оценивания выбранных характеристик качества целесообразно каждому из них присваивать коэффициент или приоритет влияния на функциональную пригодность. Группа квалифицированных экспертов из состава заказчиков, потенциальных пользователей и/или разработчиков должны оценивать и устанавливать значения таких коэффициентов —рисков (приоритетов) в пределах унифицированной шкалы, например, от единицы до десяти, для конкретного проекта ПС. Точность определения коэффициентов вряд ли может превышать 10%, поэтому количество градаций шкалы целесообразно не больше десяти.
На основе анализа и оценивания характеристик масштаба, набора требований, возможных затрат ресурсов и значений рисков в ЖЦ ПС следует определять:
— целесообразно ли продолжать работы над конкретным проектом ПС или следует его прекратить вследствие больших рисков, недостаточных ресурсов специалистов, времени или трудоемкости (бюджета) разработки;
— при наличии достаточных ресурсов, следует ли провести маркетинговые исследования для определения рентабельности полного выполнения проекта ПС и создания программного продукта для поставки на рынок;
— достаточно ли полно и корректно формализованы концепция и требования к проекту ПС, на основе которых проводились оценки затрат и рисков, или их следует откорректировать и выполнить повторный анализ с уточненными исходными данными;
— есть ли возможность применить готовые повторно используемые компоненты ПС, в каком относительном объеме комплекса программ и рентабельно ли их применять в конкретном проекте ПС или весь проект целесообразно разрабатывать как полностью новый.