Учебно-методический комплекс дисциплины
Скачать 2.15 Mb.
|
| Тема: «Жизненный цикл проекта. Модели жизненного цикла» Основные вопросы:
Одним из базовых понятий методологии проектирования ППП является понятие их жизненного цикла (ЖЦ ППП). ЖЦ ППП – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ППП, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет струк-туру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ППП. Структура ЖЦ ППП по стандарту ISO/IEC 12207 базируется на трех группах процессов: • (1 группа) основные процессы ЖЦ ППП (приобретение, поставка, разработка, эксплуатация, сопровождение); • (2 группа) вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); • (3 группа) организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение). Среди основных процессов (1 группа) особое место занимают разработка и эксплуатация. Разработка включает в себя все работы по созданию ППП и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и качества программных продуктов, материалы, необходимые для организации обучения персонала и т.д. Также разработка ППП включает в себя, как правило, анализ, проектирование и реализацию (программирование). Эксплуатация включает в себя работы по внедрению компонентов ППП в эксплуатацию и общую эксплуатацию комплекса. К работам по внедрению компонентов относятся: конфигурирование базы данных и рабочих мест пользователей, обеспечение персонала организации эксплуатационной документацией, проведение обучения персонала и т.д. К общей эксплуатации относятся следующие работы: локализация проблем и устранение причин их возникновения, модификация ППП в рамках установленного регламента, подготовка предложений по совершенствованию, развитию и модернизации системы и пр. Среди вспомогательных процессов (2 группа) существует тесная связь. Кроме того, их осуществление влияет на основные процессы. Обеспечение качества проекта связано с проблемами верификации, проверки, тестирования ППП и управления конфигурацией проекта. Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого в данный момент времени, широкому спектру требований и задач этого этапа. Проверка – это процесс, позволяющий оценить соответствие параметров разработки исходным требованиям. Проверка частично совпадает с тестированием. Но этот процесс не рассматривает конечных результатов. Тестирование – это процесс, который связан с идентификацией различий между действительными и ожидаемыми результатами работы системы. Управление конфигурацией проекта является процессом, поддерживающим основные процессы, и, прежде всего, разработку и сопровождение ППП. При создании проектов сложных информационных систем (ИС), состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ППП на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ППП отражены в стандарте ISO 12207-2. Среди организационных процессов (3 группа) ключевое положение занимает процесс управления проектом. Управление проектом – это процесс, в ходе которого осуществляются планирование и организация работ, создание коллективов разработчиков; контроль сроков и качества выполняемых работ. Также в этом процессе осуществляется: техническое и организационное обеспечение проекта, выбор методов и инструментальных средств для его реализации, определение методов описания промежуточных состояний разработки, разработка методов и средств испытаний ППП, обучение персонала и т.п. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, могут являться модели, описывающие структуру проекта. ЖЦ ППП носит итерационный (пошагово-циклический) характер, т.е. результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах. Для описания жизненного цикла существуют различные модели. Стандарт ISO/IEC 12207 предлагает наиболее общий подход к моделированию ЖЦ. Его регламенты являются общими для любых моделей ЖЦ, любых методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ППП, но не конкретизирует в деталях как реализовать или выполнить действия и задачи, включенные в эти процессы. Решение конкретных задач моделирования ЖЦ предоставляется проектировщикам и разработчикам информационной системы в конкретных условиях. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ППП и специфики условий, в которых он – ППП – создается и функционирует. К настоящему времени наибольшее распространение получили основные модели ЖЦ: каскадная (70-85 гг.) и спиральная (86-90 гг.).
В изначально существовавших однородных ППП каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе (рис. 1.4). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем: • на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; • выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении ППП, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд недостатков, вызванных прежде всего тем, что реальный процесс создания ППП никогда полностью не укладывался в такую жесткую схему. Анализ Проектирование Реализация Внедрение Сопровождение Рис. 1.4. Каскадная схема проектирования ПО В процессе создания ППП постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений (рис. 1.5). Анализ Проектирование Реализация Внедрение Сопровождение Рис. 1.5. Реальный процесс проектирования ПО по каскадной схеме Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ППП «заморожены» в виде технического задания на все время его создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ППП пользователи получают систему, не удовлетворяющую их потребностям. Модели автоматизируемого объекта могут устареть одновременно с их утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 1.6), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Прототип – это действующий фрагмент или версия ППП, которые можно проверить в работе. Рис. 1.6. Спиральная модель жизненного цикла Каждый виток спирали соответствует созданию фрагмента или версии ППП, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации (практического применения). Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача – как можно быстрее показать пользователям системы работоспособный продукт, активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Лекция 4 (4 часа) Тема: «Технология проектирования программных комплексов» Основные вопросы:
Технология проектирования ПО определяется как совокупность технологических операций проектирования, их последовательность и взаимосвязь, приводящей к разработке проекта ПО. Это основное определение соответствует общетехническому представлению о технологиях. В соответствии с этим определением любые работы, включая материальное производство, рассматриваются как последовательное выполнение действий – технологических операций, результатом которых должен стать конечный продукт определенного качества. На производственных предприятиях контроль соблюдения технологий возлагается на специальные технологические отделы и службы. Технологии формально представляются в виде документов, имеющих название «Технологические процесс». В этом документе имеется подробное описание работ, указываются цель (необходимость получения конкретного результата), объект работ, предмет работ, последовательность операций. В перечне операций указывается специальность и квалификация исполнителя, время на выполнение операции, а также стоимость выполнения операции в соответствии с ЕТКС (Единым тарифно-квалификационным справочником) и тарифами в данной отрасли. На основе технологических процессов на предприятиях разрабатываются специальные документы – «Нормы рабочего времени» – на проведение работ с перечнем операций, указанием времени на каждую операцию, ее стоимости, и итоговых показателей (общего времени и общей стоимости). На основе «Норм» осуществляется планирование деятельности предприятия, т.е. разрабатывается общий «Техпромфинплан». Все сказанное в полной мере касается и информационных технологий (ИТ). Разработка проекта ПО – это организованный и строго упорядоченный процесс, имеющий конкретный результат (в виде экономического программного комплекса), временные и стоимостные характеристики. Кроме основного, наиболее общего, определения, технологию проектирования следует рассматривать с позиций практической реализации и используемых средств и ресурсов. С этой точки зрения, технология проектирования – это совокупность методологии и средств проектирования ПО, а также методов и средств организации самого процесса проектирования. В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Так, технологический процесс проектирования экономических программных комплексов (ЭПК) в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет. Действия, которые выполняются при проектировании ЭПК, могут быть определены как неделимые технологические операции, или подпроцессы технологических операций. Все действия могут быть собственно проектировочными, которые формируют или модифицируют результаты проектирования, и оценочными, которые позволяют выработать по установленным критериям оценки результатов проектирования. Таким образом, технология проектирования задается регламентированной последовательностью технологических операций, выполняемых в процессе создания проекта на основе того или иного метода, в результате чего становиться ясно, не только ЧТО должно быть сделано для создания проекта, но и КАК, КОМУ и в КАКОЙ ПОСЛЕДОВАТЕЛЬНОСТИ. Предметом любой выбираемой технологии проектирования должны служить взаимосвязанные процессы проектирования на всех стадиях жизненного цикла ЭПК. К основным требованиям, предъявляемым к выбираемой технологии проектирования, относятся следующие: • созданный с помощью этой технологии проект должен отвечать требованиям заказчика; • выбранная технология должна максимально отражать все этапы цикла жизни проекта; • технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей); • технология должна обеспечивать гарантированное достижение целей разработки ПО с заданным качеством и в установленное время; • технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей; • технология должна обеспечивать минимальное время получения работоспособного ППП. Речь идет не о сроках готовности всего ППП, а о сроках реализации отдельных подсистем; • технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; • технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ППП (систем управления базами данных, операционных систем, языков и систем программирования). Впрочем, это требование не всегда применимо. Оно не касается ППП, создаваемых на языках-интерпретаторах, таких как VBA на базе MS Office при разработке АРМ (автоматизированных рабочих мест); • технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ; • выбираемая технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта; • технология должна быть основой связи между проектированием и сопровождением проекта; • технология должна способствовать росту производительности труда проектировщика; • технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта; • технология должна способствовать простому ведению проектной документации. Опыт разработки крупных ППП показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций. Реализация ППП в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта внедрение идет последовательно по отдельным подсистемам. Технология проектирования рассматривается как совокупность трех составляющих: • пошаговой процедуры, определяющей последовательность техно-логических операций проектирования; • критериев и правил, используемых для оценки результатов выполнения технологических операций; • нотаций (графических и текстовых средств), используемых для описания проектируемой системы. Основное содержание технологии составляют технологические инструкции. Они должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Реальное применение любой технологии проектирования, разработки и сопровождения ЭПК в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся: • стандарт проектирования; • стандарт оформления проектной документации; • стандарт пользовательского интерфейса. Стандарт проектирования должен устанавливать: • набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации; • правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т.д.; • требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т.д.; • механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т.д. Стандарт оформления проектной документации должен устанавливать: • комплектность, состав и структуру документации на каждой стадии проектирования; • требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.); • правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; • требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; • требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями. Стандарт интерфейса пользователя должен устанавливать: • правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; • правила использования клавиатуры и мыши; • правила оформления текстов помощи; • перечень стандартных сообщений; • правила обработки реакции пользователя.
Суть проблемы, определенной заказчиком, сформулированные им требования к ЭПК обусловливают характер используемых технологий проектирования, среди которых выделяются два основных класса: каноническая и индустриальная технологии (табл. 2.1). Индустриальная технология проектирования, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE-технологий) и типовое (параметрически-ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий проектирования не исключает использования в отдельных случаях канонической технологии. Для конкретных видов технологий проектирования свойственно применение определенных средств разработки ПО, которые поддерживают выполнение как отдельных проектных работ, этапов, так и их совокупностей, поэтому перед разработчиками ПО, как правило, стоит задача выбора средств проектирования, которые по своим характеристикам в наибольшей степени соответствуют требованиям конкретного предприятия. Таблица 2.1 Характеристики классов технологий проектирования
Средства проектирования должны быть: • в своем классе инвариантными к объекту проектирования; • охватывающими в совокупности все этапы жизненного цикла ЭПК; • технически, программно и информационно совместимыми; • простыми в освоении и применении; • экономически целесообразными. Средства проектирования ПО можно разделить на два класса: • без использования ЭВМ • с использованием ЭВМ. Средства проектирования без использования ЭВМ применяются на всех стадиях и этапах проектирования ЭПК. Как правило, это средства организационно-методического обеспечения операций проектирования, и в первую очередь, различные стандарты, регламентирующие процесс проектирования систем. Сюда же относятся единая система классификации и кодирования информации, унифицированная система документации, модели описания и анализа потоков информации и т.п. Средства проектирования с использованием ЭВМ могут применяться как на отдельных, так и на всех стадиях и этапах процесса проектирования экономических информационных систем (ЭИС) и соответственно поддерживают разработку элементов проекта системы, разделов проекта системы, проекта системы в целом. Все множество средств проектирования с использованием ЭВМ делят на четыре подкласса. Первый подкласс. Операционные средства, которые поддерживают проектирование операций обработки информации. К данному подклассу средств относятся алгоритмические языки, библиотеки стандартных подпрограмм и классов объектов, макрогенераторы, генераторы программ типовых операций обработки данных и т.п., а также средства расширения функций операционных систем (утилиты). В данный класс включаются также такие простейшие инструментальные средства проектирования как средства для тестирования и отладки программ, поддержки процесса документирования проекта и т.п. Особенность последних программ заключается в том, что с их помощью повышается производительность труда проектировщиков, но не разрабатывается законченное проектное решение. Таким образом, средства данного подкласса поддерживают отдельные операции проектирования ПО и могут применяться независимо друг от друга. Второй подкласс. Средства, поддерживающие проектирование отдельных компонентов проекта ЭПК. К данному подклассу относятся средства общесистемного назначения: • системы управления базами данными (СУБД); • методо-ориентированные ППП (решение задач дискретного про-граммирования, математической статистики и т.п.); • табличные процессоры; • статистические ППП; • оболочки экспертных систем; • графические редакторы; • текстовые редакторы; • интегрированные ППП (интерактивная среда с встроенными диалоговыми возможностями, позволяющая интегрировать вышеперечисленные программные средства). Перечисленные средства проектирования используются для разработки технологических подсистем ЭПК: ввода информации, организации хранения и доступа к данным, вычислений, анализа и отображения данных, принятия решений. Третий подкласс. Средства, поддерживающие проектирование разделов проекта ЭПК. В этом подклассе выделяют функциональные средства проектирования, направленные на разработку автоматизированных систем, реализующих функции, комплексы задач и задачи управления. Разнообразие предметных областей порождает многообразие средств данного подкласса, ориентированных на тип организационной системы (например, промышленная, непромышленная сферы), уровень управления (например, предприятие, цех, отдел, участок, рабочее место), функцию управления (например, планирование, учет и т.п.). К функциональным средствам проектирования систем обработки информации относятся типовые проектные решения, функциональные пакеты прикладных программ, типовые проекты. Четвертый подкласс. Средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования. К данному классу относится подкласс средств автоматизации проектирования ЭПК (CASE-средства). Эти инструментальные средства проектирования составляют основу проекта любого ППП. Под термином «CASE-средства» понимаются программные средства, поддерживающие процессы создания и сопровождения ППП, включая анализ и формулировку требований; проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ППП. Современные CASE-средства, в свою очередь, классифицируются в основном по двум признакам: • по охватываемым этапам процесса разработки ЭПК; • по степени интегрированности: отдельные локальные средства (tools), набор неинтегрированных средств, охватывающих большинство этапов разработки ЭПК (toolkit) и полностью интегрированные средства, связанные общей базой проектных данных – репозиторием (workbench). В наиболее общем виде технологию проектирования можно представить в виде последовательного выполнения основных проектных процессов (рис. 2.2). Если данную технологическую последовательность шагов создания ЭПК сопоставить с этапами (стадиями) ЖЦ, то первые два блока (определение архитектуры и построение организационной и функциональной структур) соответствуют стадии анализа, третий блок (выявление и описание предметной области) соответствуют стадии проектирования, а третий блок (реализация) соответствует стадии реализации, на которой пишется код программы и непосредственно создается программный комплекс. Ключевым моментом технологии функционального проектирования является определение и описание предметной области. Причины этого следующие: • предметная область отражает именно ту сферу жизни и деятельности предприятия, которую желает автоматизировать заказчик; • правильное определение предметной области позволяет выделить из общей функциональной структуры именно те функции, которые должны быть автоматизированы при создании программного комплекса. Реализация той или иной технологии возможна только на основе применения соответствующего методического подхода. Методология проектирования характеризует инструментарий, с помощью которого осуществляется проектирование ПО и его практическое применение. Определение архитектуры будущего программного комплекса Выявление и описание предметной области проекта Построение организационной и функциональной структур Реализация (кодирование) проекта Рис. 2.1. Основные технологические процессы проектирования ЭПК Лекция 5 (4 часа) |
Похожие:
 | Учебно-методический комплекс составлен в соответствии с требованиями государственного образовательного стандарта высшего профессионального... | | Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |
| Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... | | Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |
| Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... | | Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |
| Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... | | Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |
| Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |  | Учебно-методический комплекс дисциплины составлен в соответствии с требованиями государственного образовательного стандарта высшего... |