Навигация по лекциям
1
Лекция 1. Общие требования к проектированию ИС и технологий
2
Лекция 2. Методологии разработки ПО ИС и ИТ
Презентации:
ТПИС_лекция 2.pdf
3
Лекция 3. Управление ЖЦ ИС И ИТ в контексте проектной деятельности
4
Лекция 5. Паттерны архитектуры ПО. Инструментарий управления проектами ИС и ИТ
5
Лекция 6. Объектно-ориентированный анализ и проектирование
6
Лекция 8. Объектно-ориентированный анализ и проектирование, часть 2
7
Лекция 4. Гибкая разработка программного обеспечения

Лекция 2. Методологии разработки ПО ИС и ИТ

**Первый учебный вопрос. Каноническое проектирование, типовое проектирование, модельно-ориентированное проектирование.** ***Каноническое проектирование*** Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС, которая подразумевает полное завершение некоторого типа работ перед переходом к следующему этапу, на котором выполняется другой тип работ. Каноническое проектирование ИС характеризуется следующими особенностями: * отражает особенности ручной технологии проектирование, * предполагает выполнение индивидуального (оригинального) проектирования, * не предполагает использования средств интеграции, * соответствует каскадной модели ЖЦ ИС. На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС. При каноническом подходе выделяются следующие этапы: Стадия 1. Формирование требований к ИС. На начальной стадии проектирования выделяют следующие этапы работ: - обследование объекта и обоснование необходимости создания ИС; - формирование требований пользователей к ИС; - оформление отчета о выполненной работе и технического задания на разработку Стадия 2. Разработка концепции ИС. - изучение объекта автоматизации, проведение необходимых научно-исследовательских работ; - разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей; - оформление отчета и утверждение концепции. Стадия 3. Техническое задание. - разработка и утверждение технического задания на создание ИС. Стадия 4. Эскизный проект. - разработка предварительных проектных решений по системе и ее частям; - разработка эскизной документации на ИС и ее части. Стадия 5. Технический проект. - разработка проектных решений по системе и ее частям; - разработка документации на ИС и ее части; - разработка и оформление документации на поставку комплектующих изделий; - разработка заданий на проектирование в смежных частях проекта. Стадия 6. Рабочая документация. - разработка рабочей документации на ИС и ее части; - разработка и адаптация программ. Стадия 7. Ввод в действие. - подготовка объекта автоматизации; - подготовка персонала; - комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями); - строительно-монтажные работы; - пусконаладочные работы; - проведение предварительных испытаний; - проведение опытной эксплуатации; - проведение приемочных испытаний. Стадия 8. Сопровождение ИС. - выполнение работ в соответствии с гарантийными обязательствами; - послегарантийное обслуживание. Основная задача первого этапа обследования — оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. На стадии «Формирование требований к АС» на этапе «Обследование объекта и обоснование необходимости создания АС» проводят сбор данных об объекте и видах его деятельности. Оценивают качество функционирования объекта и его составляющих. Выявляют проблемы и задачи, которые можно решать с помощью средств автоматизации. Дают технико-экономическую, социальную и другие виды оценок целесообразности создания системы. На этапе «Формирование требований пользователей к АС» готовят исходные данные для формирования требований к АС, формулируют и оформляют требования пользователей. Готовят такие документы как характеристика объекта автоматизации, допустимые затраты ка разработку, ввод в действие и эксплуатацию системы, ожидаемый эффект, условия создания и функционирования системы. На этапе «Составление отчета о выполненной работе и заявки на разработку системы (тактико-технического задания — ТТЗ) оформляют отчет о выполненных на 1-й стадии работах и заявку на разработку ТТЗ или аналогичного по содержанию другого документа. На стадии «Разработка концепции АС» на этапе «Изучение объекта» детально изучают объект автоматизации. На этапе «Проведение необходимых научно-исследовательских работ» (НИР) выполняют поиск путей и оценки возможности реализации всех требований пользователей, оформляют и утверждают отчеты по НИР. На этапе «Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя» проводят разработку альтернативных вариантов концепции АС, планов и ресурсов их реализации, оценку достоинств и недостатков и выбирают из нескольких разработанных оптимальный вариант. Определяют порядок и условия приемки системы, ее эффективность. На этапе «Оформление отчета о выполненной работе» составляют и оформляют отчет, в котором содержится описание выполненных работ на данной стадии, обоснование и описание выбранного варианта концепции системы. На стадии «Разработка и утверждение технического задания на создание АС» разрабатывают, оформляют, согласовывают и утверждают техническое задание на создание АС, при необходимости — и на части системы. На стадии «Эскизный проект» на этапе «Разработка предварительных проектных решений по системе и ее частям» определяют функции АС и ее подсистем, состав решаемых в них задач, концепцию и структуру информационной базы, функции СУБД и основных программных средств, состав вычислительной системы. На этапе «Разработка документации на АС и ее части» выполняют разработку, оформление, согласование и утверждение документации, определенной в стандарте и полностью описывающей принятые проектные решения. На стадии «Технический проект» на этапе «Разработка проектных решений по системе и се частям» осуществляют общие решения по системе и ее частям, разрабатывают функционально-алгоритмическую структуру системы, алгоритмы решения задач. Выбирают языки программирования и принимают решения по ведению информационной базы, системе классификации и кодирования, программному обеспечению. Определяют функции персонала АС и ее организационную структуру, комплекс технических средств. На этапе «Разработка документации на АС и ее части» выполняют работы, аналогичные 2-му этапу предыдущей стадии. На этапе «Разработка и оформление документации на поставку изделий для комплектования АС и технических требований на их разработку» готовят и оформляют документацию на поставку изделий для комплектования АС. Определяют технические требования и составляют ТЗ на разработку изделий, которые серийно не изготовляются. На этапе «Разработка заданий на проектирование в смежных частях проекта объекта автоматизации» выполняют разработку, оформление, согласование и утверждение заданий на проектирование и выполнение работ (строительных, электротехнических, санитарно-технических и других, проектирование в смежных частях, связанных с созданием, АС. На стадии «Ввод в действие» на этапе «Подготовка объекта автоматизации к вводу АС в действие» осуществляют организационную подготовку, включающую реализацию решений по организационной структуре АС, обеспечение подразделений инструктивно-методическими материалами, внедрение классификаторов информации. На этапе «Подготовка персонала» обучают персонал и проверяют его способность обеспечить функционирование АС. На этапе «Комплектация АС поставляемыми изделиями» обеспечивают получение и входной контроль качества комплектующих изделий серийного и несерийного производства, материалов и монтажных изделий. На этапе «Строительно-монтажные работы» строят специализированные здания (помещения) для размещения технических средств и персонала АС, сооружают кабельные каналы, осуществляют монтаж технических средств и линий связи, испытывают их и сдают для выполнения пусконаладочных работ. На этапе «Пусконаладочные работы» выполняют автономную наладку технических и программных средств, загружают информацию в базу данных, проверяют систему ее ведения, налаживают все средства системы. На этапе «Проведение предварительных испытаний» в соответствии с программой и методикой проводят испытания на работоспособность системы и соответствие ТЗ. Далее устраняют выявленные неисправности и вносят необходимые изменения в документацию на АС. Оформляют акт о приемке системы в опытную эксплуатацию. На этапе «Проведение опытной эксплуатации» осуществляют эксплуатацию и ее анализ, при необходимости дорабатывают программное обеспечение, дополнительно налаживают технические средства и оформляют акт о завершении опытной эксплуатации системы. На этапе «Проведение приемочных испытаний» в соответствии с программой и методикой выполняют испытания на соответствие ТЗ, анализируют результаты и устраняют недостатки, выявленные при испытаниях, оформляют акт о приемке системы в постоянную эксплуатацию. На стадии «Сопровождение АС» на этапе «Выполнение работ в соответствии с гарантийными обязательствами» устраняют недостатки, выявленные при эксплуатации АС в течение гарантийных сроков, и вносят необходимые изменения в документацию. На этапе «Послегарантийное обслуживание» осуществляют анализ работы системы, выявляют отклонения от проекта, устанавливают причины этих отклонений и устраняют их, вносят необходимые изменения в документацию на АС, Приведенные стадии и этапы разработки систем не всегда могут быть реализованы полностью. Разработка проходит только все необходимые для конкретной системы стадии и этапы. ***Типовое проектирование*** Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия. Типовое проектное решение (ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение. Выделяются следующие классы ТПР: - элементные ТПР — типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному); - подсистемные ТПР — в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; - объектные ТПР — типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС. Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование. Параметрически-ориентированное проектирование включает следующие этапы: - определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач; - анализ и оценка доступных ППП по сформулированным критериям; - выбор и закупка наиболее подходящего пакета; - настройка параметров (доработка) закупленного ППП. Критерии оценки ППП делятся на следующие группы: - назначение и возможности пакета; - отличительные признаки и свойства пакета; - требования к техническим и программным средствам; - документация пакета; - факторы финансового порядка; - особенности установки пакета; - особенности эксплуатации пакета; - помощь поставщика по внедрению и поддержанию пакета; - оценка качества пакета и опыт его использования; - перспективы развития пакета. Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок. На их основе формируются групповые оценки и комплексная оценка пакета. Нормированные взвешивающие коэффициенты также получаются экспертным путем. ***Модельно-ориентированное проектирование*** Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия. Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства. Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий. Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС. Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench). Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы. Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы. Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС"). Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Eventdriven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия. Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов. Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала. Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации. Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN). Реализация типового проекта предусматривает выполнение следующих операций: - установку глобальных параметров системы; - задание структуры объекта автоматизации; - определение структуры основных данных; - задание перечня реализуемых функций и процессов; - описание интерфейсов; - описание отчетов; - настройку авторизации доступа; - настройку системы архивирования. **Второй учебный вопрос. CASE-средства в проектировании.** Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО. Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами. Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями: - мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; - интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС; - использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты: - репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; - графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; - средства разработки приложений, включая языки 4GL и генераторы кодов; - средства конфигурационного управления; - средства документирования; - средства тестирования; - средства управления проектом; - средства реинжиниринга. Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам: - применяемым методологиям и моделям систем и БД; - степени интегрированности с СУБД; - доступным платформам. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы: - средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works)); - средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; - средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; - средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun; - средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают: - средства планирования и управления проектом (SE Companion, Microsoft Project и др.); - средства конфигурационного управления (PVCS (Intersolv)); - средства тестирования (Quality Works (Segue Software)); - средства документирования (SoDA (Rational Software)).