ТЕМА 2. Технологии проектирования информационных систем Лекция 5-6. Классификация технологий проектирования ИС. - презентация

1 ТЕМА 2. Технологии проектирования информационных систем Лекция 5-6. Классификация технологий проектирования ИС

2 План лекции 1. Понятие технологии проектирования. 2. Классы методов и технологий проектирования. 1. Технология канонического проектирования. 2. Технология индустриального автоматизированного проектирования. 3. Технология типового проектирования. 3. Современные технологии проектирования. 1. RUP 2. CDM 3. MSF 4. SCRUM 4. Подходы к внедрению ИС. 2

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

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

5 5 – это относительно самостоятельный фрагмент технологического процесса проектирования, в котором определены: Технологическая операция проектирования – это относительно самостоятельный фрагмент технологического процесса проектирования, в котором определены: вход; выход; преобразователь; ресурсы; средства.

6 6 Требования, предъявляемые к технологии проектирования ИС Технология должна поддерживать полный жизненный цикл системы; Технология должна поддерживать полный жизненный цикл системы; технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время; технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем; технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем; технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами; технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами;

7 7 Требования, предъявляемые к технологии проектирования ИС технология должна обеспечивать минимальное время получения работоспособной ИС; технология должна обеспечивать минимальное время получения работоспособной ИС; технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта; технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС; технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС; технология должна быть поддержана комплексом согласованных CASE-средств. технология должна быть поддержана комплексом согласованных CASE-средств.

8 8 Технологии проектирования Каноническое проектирование Индустриальное проектирование Автоматизированное проектирование Типовое проектирование Параметрически- ориентированное Модельно- ориентированное Классы технологий проектирования ИС

9 9 Методы проектирования По степени автоматизации проектных работ Ручное проектирование Автоматизированное проектирование По степени использования ТПР Оригинальное проектирование Типовое проектирование По степени адаптивности проектных решений Методы реконструкции Методы параметризации Методы реструктуризации модели

10 10 Соответствие технологий и методов проектирования Технология проектирова- ния Степень автоматиза ции Степень типизации Степень адаптивности КаноническоеРучное Оригиналь- ное Реконструкция Индустриальное автоматизиро- ванное Компьютер ное Оригиналь- ное Реструктуризация модели (генерация ИС) Индустриальное типовое Компьютер ное Типовое (сборочное) Параметризация и реструктуризация модели

11 11 Каноническое проектирование Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких- либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких- либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Область применения: для небольших локальных ИС. Область применения: для небольших локальных ИС. Модель жизненного цикла ИС: каскадная. Модель жизненного цикла ИС: каскадная. Проектная документация: в соответствии с ГОСТ 34. Проектная документация: в соответствии с ГОСТ 34.

12 12 Технологическая сеть канонического проектирования Д 1.1. предметная область; Д 1.2. материалы обследования; Д 1.3. ТЭО; Д 1.4. техническое задание (ТЗ) на проектирование; Д 1.1. предметная область; Д 1.2. материалы обследования; Д 1.3. ТЭО; Д 1.4. техническое задание (ТЗ) на проектирование; Д 2.1. техно-рабочий проект (ТРП); Д 2.1. техно-рабочий проект (ТРП); Д 3.1. исправленный ТРП, переданный в эксплуатацию; Д 3.2. акт о приемке проекта в промышленную эксплуатацию; Д 3.1. исправленный ТРП, переданный в эксплуатацию; Д 3.2. акт о приемке проекта в промышленную эксплуатацию; Д 4.1. модернизированный ТРП. Д 4.1. модернизированный ТРП.

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

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

15 15 Технологическая сеть проектирования стадии предпроектного обследования

16 16 П 1 предварительное изучение предметной области: Д 1.1. общие сведения об объекте; Д 1.2. примеры разработок проектов ИС для аналогичных объектов; П 2 выбор технологии проектирования: U 2.1. универсум технологий проектирования; Д 2.1. список ресурсов; Д 2.2. oписаниe выбранной технологии, методов и средств проектирования; П 3 выбор метода проведения обследования: U 3.1. универсум методов проведения обследования; Д 3.1. описание выбранного метода; П 4 выбор метода сбора материалов обследования: U 4.1. универсум методов сбора материалов обследования; Д 4.1. описание выбранных методов; П 5 разработка программы обследования: Д 5.1. программа обследования; П 6 разработка плана-графика сбора материалов обследования: Д 6.1. план-график выполнения работ на предпроектной стадии; П 7 сбор и формализация материалов обследования: U 7.1. универсум методов формализации; Д 7.1. общие параметры (характеристики) экономической системы; Д 7.2. организационная структура экономической системы; Д 7.3. методы и методики управления (алгоритм расчета экономических показателей); Д 7.4. параметры информационных потоков; Д 7.5. параметры материальных потоков.

17 17 Технологическая сеть стадии технического проектирования Разработка общесистемных проектных решений Разработка локальных проектных решений

18 18 Технологическая сеть стадии рабочего проектирования

19 19 Стадия внедрения Методы внедрения: Методы внедрения: последовательный последовательный параллельный параллельный смешанный смешанный Этапы внедрения: Этапы внедрения: подготовка экономического объекта к внедрению ИС; подготовка экономического объекта к внедрению ИС; опытное внедрение; опытное внедрение; сдача проекта в промышленную эксплуатацию. сдача проекта в промышленную эксплуатацию.

20 20 Автоматизированное проектирование CASE-технология – совокупность методов анализа, проектирования, разработки и сопровождения ИС, поддержанных комплексом взаимосвязанных средств автоматизации. CASE-технология – совокупность методов анализа, проектирования, разработки и сопровождения ИС, поддержанных комплексом взаимосвязанных средств автоматизации. Цель CASE-технологии – отделить процесс проектирования ИС от ее кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки и функционирования систем. Цель CASE-технологии – отделить процесс проектирования ИС от ее кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки и функционирования систем. Характеристики CASE-средств: Характеристики CASE-средств: мощная графика для описания и документирования систем; мощная графика для описания и документирования систем; интеграция, обеспечивающая легкость передачи данных и позволяющая управлять всем процессом проектирования и разработки системы непосредственно через процесс планирования проекта; интеграция, обеспечивающая легкость передачи данных и позволяющая управлять всем процессом проектирования и разработки системы непосредственно через процесс планирования проекта; использование репозитория для хранения всей информации о проекте. использование репозитория для хранения всей информации о проекте.

21 21 Оценка трудозатрат по фазам жизненного цикла ИС Каноническое проектирование Автоматизированное проектирование

22 22 Технология канонического проектирования Технология автоматизированного проектирования Основные усилия – на кодирование и тестирование Основные усилия – на анализ и проектирование "Бумажные" спецификации Быстрое итеративное макетирование Ручное кодирование Автоматическая генерация машинного кода Тестирование ПО Автоматический контроль проекта Сопровождение программного кода Сопровождение проекта

23 23 Компоненты интегрированного CASE-средства 1.Средства централизованного хранения информации о проектируемой ИС в течение всего ЖЦ (репозиторий) 2.Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм. 3.Средства разработки приложений, предназначенные для автоматизированной кодогенерации и тестирования. 4.Средства документирования, управления проектом и реинжиниринга.

24 24 Технология внедрения CASE-средств Технология внедрения CASE-средств базируется на стандартах IEEE (Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Этапы внедрения CASE-средств: 1.Определение потребностей в CASE- средствах 2.Оценка и выбор CASE-средств 3.Выполнение пилотного проекта 4.Полномасштабное внедрение CASE-средств

25 25 Факторы, влияющие на выбор CASE-средств Относительная простота или сложность средства; Относительная простота или сложность средства; степень согласованности с существующими в организации бизнес-процессами; степень согласованности с существующими в организации бизнес-процессами; требуемая степень интеграции с другими программными средствами; требуемая степень интеграции с другими программными средствами; опыт и квалификация пользователей. опыт и квалификация пользователей.

26 26 I этап – Определение потребностей в CASE- средствах

27 27 Анализ возможностей организации Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994 ISO 9001: 1994 ISO : 1991 ISO : 1991 ISO :1991 ISO :1991 ГОСТ Р ИСО , гр. Т59 «Рекомендации по улучшению деятельности». ГОСТ Р ИСО , гр. Т59 «Рекомендации по улучшению деятельности». Неформальные подходы базируются на использовании анкетирования сотрудников и руководства по вопросам текущей практики использования ПО, технологии и персонала. Для удобства составления анкет эти вопросы могут быть разбиты на 5 групп. Неформальные подходы базируются на использовании анкетирования сотрудников и руководства по вопросам текущей практики использования ПО, технологии и персонала. Для удобства составления анкет эти вопросы могут быть разбиты на 5 групп.

28 28 Группа 1 - Общие вопросы Используемая модель ЖЦ разработки ИС (каскадная или спиральная); Используемая модель ЖЦ разработки ИС (каскадная или спиральная); используемые методы (структурные, объектно- ориентированные); используемые методы (структурные, объектно- ориентированные); квалификация сотрудников; квалификация сотрудников; наличие документированных стандартов (формальных или неформальных) по анализу требований, спецификациям и проектированию, кодированию и тестированию; наличие документированных стандартов (формальных или неформальных) по анализу требований, спецификациям и проектированию, кодированию и тестированию; виды документации, выпускаемой в процессе ЖЦ ПО. виды документации, выпускаемой в процессе ЖЦ ПО.

29 29 Группа 2 – проекты, ведущиеся в организации Средняя продолжительность проекта в человеко- месяцах; Средняя продолжительность проекта в человеко- месяцах; среднее количество специалистов, участвующих в проектах различных категорий; среднее количество специалистов, участвующих в проектах различных категорий; средний размер проектов различных категорий в терминах кодовых метрик (например, в строках исходных кодов или функциональных точках). средний размер проектов различных категорий в терминах кодовых метрик (например, в строках исходных кодов или функциональных точках).

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

31 31 Группа 4 – персонал Реакция сотрудников организации на внедрение новой технологии (наличие опыта успешных или неуспешных внедрений); Реакция сотрудников организации на внедрение новой технологии (наличие опыта успешных или неуспешных внедрений); наличие лидеров, способных серьезно повлиять на отношение к новым средствам; наличие лидеров, способных серьезно повлиять на отношение к новым средствам; наличие стремления у рядовых сотрудников к совершенствованию средств и технологии; наличие стремления у рядовых сотрудников к совершенствованию средств и технологии; объем обучения, необходимого для ориентации пользователей в новой технологии; объем обучения, необходимого для ориентации пользователей в новой технологии; стабильность и уровень текучести кадров. стабильность и уровень текучести кадров.

32 32 Группа 5 – готовность Поддержка проекта со стороны высшего руководства; Поддержка проекта со стороны высшего руководства; готовность организации к долгосрочному финансированию проекта; готовность организации к долгосрочному финансированию проекта; готовность организации к выделению необходимых специалистов для участия в процессе внедрения и к их обучению; готовность организации к выделению необходимых специалистов для участия в процессе внедрения и к их обучению; готовность персонала к существенному изменению технологии своей работы; готовность персонала к существенному изменению технологии своей работы; степень понимания персоналом масштаба изменений; степень понимания персоналом масштаба изменений; готовность технических специалистов и менеджеров к возможному снижению продуктивности своей работы; готовность технических специалистов и менеджеров к возможному снижению продуктивности своей работы; готовность руководства к долговременному ожиданию отдачи от вложенных средств. готовность руководства к долговременному ожиданию отдачи от вложенных средств.

33 33 Определение потребностей организации Цель организации: использовать CASE-технологию для достижения определенного уровня CMM или сертификации в соответствии с ISO Потребности, соответствующие цели: поддержка технологического процесса разработки ПО; поддержка технологического процесса разработки ПО; выпуск нормативной и технологической документации. выпуск нормативной и технологической документации. Матрица соответствия потребностей организации возможностям CASE-средств поможет определиться с выбором конкретного программного продукта.

34 34 Реалистичные ожидания Ускорение и повышение согласованности разработки ИС; Ускорение и повышение согласованности разработки ИС; снижение доли ручного труда в процессе разработки и эксплуатации; снижение доли ручного труда в процессе разработки и эксплуатации; более точное соответствие ИС требованиям пользователей; более точное соответствие ИС требованиям пользователей; повышение качества проектирования и документирования; повышение качества проектирования и документирования; улучшение коммуникации между пользователями и разработчиками; улучшение коммуникации между пользователями и разработчиками; возможность повторного использования разработок; возможность повторного использования разработок; кратковременное возрастание затрат, связанное с деятельностью по внедрению CASE-средств кратковременное возрастание затрат, связанное с деятельностью по внедрению CASE-средств

35 35 Нереалистичные ожидания понимание проектных спецификаций неподготовленными пользователями; понимание проектных спецификаций неподготовленными пользователями; сокращение персонала, связанного с ИТ; сокращение персонала, связанного с ИТ; уменьшение степени участия в проектах высшего руководства и менеджеров; уменьшение степени участия в проектах высшего руководства и менеджеров; немедленное повышение продуктивности деятельности организации; немедленное повышение продуктивности деятельности организации; достижение абсолютной полноты и непротиворечивости спецификаций; достижение абсолютной полноты и непротиворечивости спецификаций; автоматическая генерация ИС из проектных спецификаций; автоматическая генерация ИС из проектных спецификаций; немедленное снижение затрат, связанных с информационной технологией; немедленное снижение затрат, связанных с информационной технологией; снижение затрат на обучение. снижение затрат на обучение.

36 36 Статьи затрат на внедрение CASE-средств Затраты на специалистов по планированию внедрения CASE-средств; Затраты на специалистов по планированию внедрения CASE-средств; технические средства; технические средства; приобретение, настройка CASE-средств и обучение пользователей; приобретение, настройка CASE-средств и обучение пользователей; интеграция с другими средствами и существующими данными; интеграция с другими средствами и существующими данными; подготовка документации, стандартов и процедур использования средств; подготовка документации, стандартов и процедур использования средств; обновление версий. обновление версий.

37 37 Типовое проектирование Необходимость типизации проектных решений связана с: сложностью обеспечения высокого научно-технического уровня разработки при индивидуальном проектировании; сложностью обеспечения высокого научно-технического уровня разработки при индивидуальном проектировании; существенным снижением затрат на проектирование при внедрении типовой системы. существенным снижением затрат на проектирование при внедрении типовой системы. : Требования к экономическому объекту : управление предприятием осуществляется на основе единых положений; управление предприятием осуществляется на основе единых положений; структура системы управления во всех подразделениях предприятия одинакова и зависит только от размера предприятия; структура системы управления во всех подразделениях предприятия одинакова и зависит только от размера предприятия; технические средства ИС стандартизированы; технические средства ИС стандартизированы; возможность декомпозиции проектируемой ИС на множество составляющих компонентов. возможность декомпозиции проектируемой ИС на множество составляющих компонентов.

38 38 Классификация ТПР по уровню декомпозиции Элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному) Подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; Модельные (объектные) ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

39 39 Элементный метод типового проектирования Достоинство применение модульного подхода к проектированию и документированию ИС. Недостатки: необходимость разработки недостающих компонентов ИС вручную; большие затраты времени на доработку и сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР; плохая адаптивность элементов к особенностям предприятия.

40 40 Подсистемный метод типового проектирования Достоинства: модульное проектирование; параметрическая настройку программных компонентов на различные объекты управления; сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации. Недостатки: адаптивность ТПР недостаточна с позиции непрерывного инжиниринга бизнес-процессов; проблемы в обеспечении комплексного использования разных функциональных подсистем от нескольких производителей программного обеспечения

41 41 Объектный (модельный) метод типового проектирования Достоинства: возможность комплексного использования всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости; открытость архитектуры; масштабируемость; конфигурируемость. Недостатки: проблемы привязки типового проекта к конкретному объекту управления, связанные с изменением организационно-экономической структуры объекта автоматизации

42 42 Параметрически-ориентированное типовое проектирование заключается в выборе ТПР, наиболее подходящих объекту управления по своим параметрам. заключается в выборе ТПР, наиболее подходящих объекту управления по своим параметрам. Применяется в случае проектирования ИС на базе элементных и подсистемных ТПР Применяется в случае проектирования ИС на базе элементных и подсистемных ТПР Состав ТПР

43 43 Этапы параметрически- ориентированного проектирования 1. 1.Определение критериев оценки пригодности ТПР для решения поставленных задач 2. 2.Анализ и оценка доступных ТПР по сформулированным критериям 3. 3.Выбор и закупка наиболее подходящего ТПР 4. 4.Настройка параметров (доработка) закупленного ТПР 5. 5.Интеграция нескольких ТПР (при необходимости) Обучение персонала Эксплуатация и адаптация (при необходимости).

44 44 Перечень критериев выбора ТПР зависит от: срока разработки ИС, финансовых возможностей организации, технической оснащенности объекта управления, существующих и функционирующих ИС; программного и сетевого оснащения; квалификации персонала.

45 45 Критерии оценки ТПР 1. 1.Назначение и возможности ТПР 2. 2.Отличительные признаки и свойства ТПР 3. 3.Требования к техническим и программным средствам 4. 4.Документация ТПР 5. 5.Стоимость (включая стоимость настройки и обучения) 6. 6.Особенности установки ТПР 7. 7.Особенности эксплуатации ТПР 8. 8.Помощь поставщика по внедрению и поддержанию ТПР 9. 9.Оценка качества ТПР и опыт его использования Перспективы развития ТПР.

46 46 Модельно-ориентированное типовое проектирование заключается в адаптации структуры, состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. 1 вариант: создание системы на основе построения модели объекта автоматизации с использованием специального программного инструментария и поиск типовой ИС, удовлетворяющей данной модели. 2 вариант: создание системы на базе типовой модели объекта автоматизации из репозитория (специальной базы метаинформации), который поставляется вместе с программным продуктом.

47 47 Модель ИС конкретного предприятия строится: путем выбора фрагментов типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler); путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench). Репозиторий Базовая модель ИС Типовые модели определенных классов ИС Модели ИС конкретных предприятий Описание объектов, функций, бизнес-правил, орг. структуры, которые поддерживаются программными модулями типовой ИС Описание конфигурации ИС для определенных отраслей или типов производства.

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

49 49 Внедрение типовой ИС Установка глобальных параметров системы; задание структуры объекта автоматизации; определение структуры основных данных; задание перечня реализуемых функций и процессов; описание интерфейсов; описание отчетов; настройка авторизации доступа; настройка системы архивирования.

50 ТЕМА 3. Технологии проектирования ИС. Лекция 8. Современные технологии проектирования ИС.

51 51 Современные технологии проектирования НазваниеСокращениеРазработчик Rational Unified Process RUP IBM (Rational Software) Custom Development Method CDMOracle Microsoft Solutions Framework MSFMicrosoft

52 52 Технология Rational Unified Process RUP соответствует стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций- разработчиков (ISO 12207, ISO 9000, CMM и др.). Основные принципы: Итерационный и инкрементный (наращиваемый) подход к созданию ПО. Итерационный и инкрементный (наращиваемый) подход к созданию ПО. Планирование и управление проектом осуществляется на основе функциональных требований к системе (вариантов использования). Планирование и управление проектом осуществляется на основе функциональных требований к системе (вариантов использования).

53 53 Общее представление RUP

54 54 Начальная стадия RUP : Результаты: общее описание системы: основные требования к проекту, его характеристики и ограничения; общее описание системы: основные требования к проекту, его характеристики и ограничения; начальная модель вариантов использования (степень готовности – 10-20%); начальная модель вариантов использования (степень готовности – 10-20%); начальный проектный глоссарий (словарь терминов); начальный проектный глоссарий (словарь терминов); начальный бизнес-план; начальный бизнес-план; план проекта, отражающий стадии и итерации; план проекта, отражающий стадии и итерации; один или несколько прототипов. один или несколько прототипов.

55 55 Стадия разработки RUP : Результаты: модель вариантов использования (завершенная на 80%), определяющая функциональные требования к системе; модель вариантов использования (завершенная на 80%), определяющая функциональные требования к системе; перечень дополнительных (нефункциональных) требований; перечень дополнительных (нефункциональных) требований; описание базовой архитектуры будущей системы - модель предметной области и технологическую платформу; описание базовой архитектуры будущей системы - модель предметной области и технологическую платформу; работающий прототип; работающий прототип; уточненный бизнес-план; уточненный бизнес-план; план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации. план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.

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

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

58 58 Статический аспект RUP 1.Роль (role) – определяет поведение и ответственность личности (член проектной команды). 2.Вид деятельности (activity) – единица выполняемой работы (технологическая операция), сопровождается набором руководств (guidelines), представляющих собой методики выполнения технологических операций. 3.Рабочий продукт (artifact) – модель, элемент модели, документ, исходный код или план, являющийся результатом вида деятельности. 4.Дисциплина (discipline) – последовательность действий, приводящая к получению значимого результата (технологический процесс).

59 59 Дисциплины RUP Основные дисциплины: 1)построение бизнес-моделей; 2)определение требований; 3)анализ и проектирование; 4)реализация; 5)тестирование; 6)развертывание. : Вспомогательные дисциплины: 1)управление конфигурацией и изменениями; 2)управление проектом; 3)создание инфраструктуры.

60 60 Компоненты RUP Описание всех элементов динамического и статического аспекта RUP; Описание всех элементов динамического и статического аспекта RUP; навигатор по всем элементам RUP, глоссарий и средство быстрого обучения технологии; навигатор по всем элементам RUP, глоссарий и средство быстрого обучения технологии; руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО; руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО; рекомендации по использованию инструментальных средств, входящих в состав Rational Suite; рекомендации по использованию инструментальных средств, входящих в состав Rational Suite; примеры и шаблоны проектных решений для Rational Rose; примеры и шаблоны проектных решений для Rational Rose; шаблоны проектной документации для SoDa; шаблоны проектной документации для SoDa; шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО; шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО; планы в формате Microsoft Project, отражающие итерационный характер разработки ПО. планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

61 61 Инструментальные средства для поддержки RUP RUP опирается на интегрированный комплекс инструментальных средств. Он существует в следующих вариантах: RUP опирается на интегрированный комплекс инструментальных средств Rational Suite. Он существует в следующих вариантах: Rational Suite AnalystStudio – предназначен для определения и управления полным набором требований к разрабатываемой системе; Rational Suite AnalystStudio – предназначен для определения и управления полным набором требований к разрабатываемой системе; Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО; Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО; Rational Suite TestStudio – представляет собой набор продуктов, предназначенных для автоматического тестирования приложений; Rational Suite TestStudio – представляет собой набор продуктов, предназначенных для автоматического тестирования приложений; Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков. Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков.

62 62 Состав IBM Rational Suite IBM Rational RequisitePro – средство управления требованиями; IBM Rational RequisitePro – средство управления требованиями; IBM Rational Rose – средство визуального моделирования; IBM Rational Rose – средство визуального моделирования; IBM Rational XDE – средство генерации объектного кода; IBM Rational XDE – средство генерации объектного кода; IBM Rational RapidDeveloper – средство разработки; IBM Rational RapidDeveloper – средство разработки; IBM Rational ClearCase – средство конфигурационного управления; IBM Rational ClearCase – средство конфигурационного управления; IBM Rational ClearQuest – средство управления изменениями; IBM Rational ClearQuest – средство управления изменениями; IBM Rational SoDA – средство автоматизированного документирования; IBM Rational SoDA – средство автоматизированного документирования; IBM Rational Quantify – средство количественного определения узких мест, влияющих на общую эффективность работы программы; IBM Rational Quantify – средство количественного определения узких мест, влияющих на общую эффективность работы программы; IBM Rational TestManager – средство планирования функционального и нагрузочного тестирования; IBM Rational TestManager – средство планирования функционального и нагрузочного тестирования; IBM Rational Robot – средство записи и воспроизведения тестовых сценариев; IBM Rational Robot – средство записи и воспроизведения тестовых сценариев; IBM Rational TestFactory – средство тестирования надежности; IBM Rational TestFactory – средство тестирования надежности; IBM Rational Quality Architect – средство генерации кода для тестирования. IBM Rational Quality Architect – средство генерации кода для тестирования.

63 63 Технология Custom Development Method Методическая основа технологии создания ПО корпорации Oracle – комплекс методов, охватывающий большинство процессов ЖЦ ПО. Методическая основа технологии создания ПО корпорации Oracle – комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят: В состав комплекса входят: () – разработка прикладного ПО; CDM () – разработка прикладного ПО; PJM (Project Management Method) – управление проектом; PJM (Project Management Method) – управление проектом; AIM (Application Implementation Method) – внедрение прикладного ПО; AIM (Application Implementation Method) – внедрение прикладного ПО; BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов; BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов; OCM (Organizational Change Management) – управление изменениями. OCM (Organizational Change Management) – управление изменениями.

64 64

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

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

67 67 ХарактеристикиКлассический подход (каскадный) Подход быстрой разработки (итерационный) Количество этапов 54 Характеристики проекта Высокая сложность Высокая сложность Большой масштаб Большой масштаб Нечетко определенная задача Нечетко определенная задача Несложная архитектура системы Несложная архитектура системы Небольшие и средние по масштабу проекты Небольшие и средние по масштабу проекты Четкая постановка задачи Четкая постановка задачи Характеристики исполнителей Невысокая квалификация исполнителей, неподготовленные пользователи Высококвалифицированные универсальные исполнители, хорошо подготовленные пользователи Продолжительность проекта 8 – 36 месяцев 4 – 16 месяцев

68 68 Процессы PJM для разработки ПО в CDM 1.Управление проектом и предоставление отчетности (Control and Reporting). 2.Управление работой (Work Management). 3.Управление ресурсами (Resource Management). 4.Управление качеством (Quality Management). 5.Управление конфигурацией (Configuration Management).

69 69 Комплекс Oracle Developer Suite для быстрой разработки Oracle Designer - средство моделирования и генерации приложений; Oracle Designer - средство моделирования и генерации приложений; Oracle Forms - средство быстрой разработки приложений; Oracle Forms - средство быстрой разработки приложений; Oracle Reports - визуальное средство разработки отчетов; Oracle Reports - визуальное средство разработки отчетов; Oracle JDeveloper - средство визуального программирования на языке Java; Oracle JDeveloper - средство визуального программирования на языке Java; Oracle Discoverer - средство для разработки аналитических приложений; Oracle Discoverer - средство для разработки аналитических приложений; Oracle Warehouse Builder - система для построения хранилищ данных; Oracle Warehouse Builder - система для построения хранилищ данных; Oracle Portal - средство разработки информационного портала организации. Oracle Portal - средство разработки информационного портала организации.

70 70 Технология Microsoft Solution Framework Microsoft Solutions Framework представляет собой согласованный набор концепций, моделей и правил. : Состав MSF: Модель процессов; Модель процессов; Модель проектной группы; Модель проектной группы; Дисциплина управления проектами; Дисциплина управления проектами; Дисциплина управления рисками; Дисциплина управления рисками; Дисциплина управления подготовкой. Дисциплина управления подготовкой.

71 71 Модель процессов MSF

72 72 Создание общей картины приложения Определение состава команды; определение структуры проекта; определение бизнес-целей; оценка существующей ситуации; создание документа общей картины и области действия проекта; определение требований и профилей пользователей; разработка концепции решения; оценка риска; закрытие этапа.

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

74 74 Контрольные точки этапа планирования Функциональная спецификация; Функциональная спецификация; план управления рисками; план управления рисками; определение среды разработки и тестирования; определение среды разработки и тестирования; генеральный план и календарный график проекта. генеральный план и календарный график проекта.

75 75 Этап разработки Задачи: создание прототипа приложения; разработка программных компонентов приложения; создание решения из подготовленных компонентов; закрытие разработки (реализация всех функций, готовность кода и документации). Результаты: исходный текст кода и исполняемые файлы; сценарии установки и конфигурации для развертывания; окончательная функциональная спецификация; элементы поддержки решения; спецификации и сценарии тестирования. Контрольная точка – окончательное утверждение области действия проекта

76 76 Стабилизация : Задачи: тестирование компонентов; тестирование компонентов; тестирование баз данных; тестирование баз данных; тестирование инфраструктуры; тестирование инфраструктуры; тестирование защиты; тестирование защиты; тестирование интеграции; тестирование интеграции; анализ удобства работы с продуктом; анализ удобства работы с продуктом; нагрузочное тестирование (включая анализ ресурсоемкости и производительности); нагрузочное тестирование (включая анализ ресурсоемкости и производительности); ведение отчетности по тестированию. ведение отчетности по тестированию. : Результат: подтверждение готовности продукта к выпуску и полноценному развертыванию в промышленной среде. подтверждение готовности продукта к выпуску и полноценному развертыванию в промышленной среде.

77 77 Развертывание : Задачи: установка решения и необходимых компонентов окружения; проведение стабилизации продукта в промышленных условиях; передача проекта группе сопровождения; анализ проекта в целом на предмет уровня удовлетворенности заказчика.

78 78 Модель проектной группы Модель проектной группы MSF (MSF Team Model) описывает подход Microsoft к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Модель проектной группы основана на: 6 принципах 6 концепциях 6 ролевых кластерах

79 79 Основные принципы модели проектной группы 1. 1.Распределение ответственности при фиксации отчетности 2. 2.Наделение членов команды полномочиями 3. 3.Концентрация на бизнес-приоритетах 4. 4.Единое видение проекта 5. 5.Готовность к переменам 6. 6.Свободное общение членов группы

80 80 Ключевые концепции модели проектной группы 1. 1.Проектная группа – команда соратников 2. 2.Сфокусированность на нуждах заказчика 3. 3.Нацеленность на конечный результат 4. 4.Установка на отсутствие дефектов 5. 5.Стремление к самосовершенствованию 6. 6.Заинтересованные команды работают эффективно

81 81 Ролевые кластеры 1. 1.Управление продуктом (product manager) бизнес- приоритеты, маркетинг, представительство интересов заказчика Управление программой (program manager) разработка архитектуры решения, административные службы 3. 3.Разработка (developer) разработка приложений и инфраструктуры, технологические консультации 4. 4.Тестирование (tester) планирование, разработка тестов и отчетности по тестам 5. 5.Управление выпуском (release manager) инфраструктура, сопровождение, бизнес-процессы, выпуск готового продукта 6. 6.Удовлетворение заказчика (user experіence) обучение, эргономика, графический дизайн, техническая поддержка

82 82 Менеджер продукта Менеджер програм- мы Разрабо тчик Тести- ровщик Менеджер по выпуску Спец. по удобству использо- вания Менеджер продукта ––+–/+ Менеджер программы –––/++ Разработ- чик ––––– Тестиров- щик +–/+–++ Менеджер по выпуску –/++–+ Спец. по удобству использова- ния –/+ –+

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

84 84 Основные принципы Scrum Люди и их взаимодействие важнее процессов и инструментов; Люди и их взаимодействие важнее процессов и инструментов; Готовый продукт важнее документации по нему; Готовый продукт важнее документации по нему; Сотрудничество с заказчиком важнее жестких контрактных ограничений; Сотрудничество с заказчиком важнее жестких контрактных ограничений; Реакция на изменения важнее следования плану. Реакция на изменения важнее следования плану.

85 Элементы Scrum Спринт итерация (1-4 недели), в ходе которой обеспечивается функциональный рост ПО. Спринт итерация (1-4 недели), в ходе которой обеспечивается функциональный рост ПО. Резерв проекта список требований к функциональности, подлежащих реализации, упорядоченный по степени важности. Элементы списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). «Будучи пользователем я хочу сделать, чтобы получить ». Резерв проекта список требований к функциональности, подлежащих реализации, упорядоченный по степени важности. Элементы списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items). «Будучи пользователем я хочу сделать, чтобы получить ». Резерв спринта содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Резерв спринта содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. 85

86 86 Основные роли Scrum Скрам-мастер (ScrumMaster) проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Скрам-мастер (ScrumMaster) проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Владелец продукта (Product Owner) представляет интересы конечных пользователей и других заинтересованных в продукте сторон, предоставляет понятные и тестируемые требования команде, отвечает за приемку кода в конце каждой итерации. Владелец продукта (Product Owner) представляет интересы конечных пользователей и других заинтересованных в продукте сторон, предоставляет понятные и тестируемые требования команде, отвечает за приемку кода в конце каждой итерации. Скрам-команда (Scrum Team) команда разработчиков проекта, состоящая из специалистов разных профилей. Размер команды в идеале составляет 7±2 человека. Скрам-команда (Scrum Team) команда разработчиков проекта, состоящая из специалистов разных профилей. Размер команды в идеале составляет 7±2 человека.

87 87 Дополнительные роли Scrum Пользователи (Users) Пользователи (Users) Клиенты, Продавцы (Stakeholders) лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту. Клиенты, Продавцы (Stakeholders) лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту. Управляющие (Managers) люди, которые управляют персоналом. Управляющие (Managers) люди, которые управляют персоналом. Эксперты-консультанты (Consulting Experts) Эксперты-консультанты (Consulting Experts)

88 88 Процессы Scrum Планирование спринта (4-8 ч.) Ежедневное совещание (15 мин.) 1. Что было сделано с предыдущего совещания? 2. Что будет сделано к следующему совещанию? 3. Какие есть проблемы? (скрам-мастер) Скрам над скрамом (после ежедневного совещания в случае параллельной работы нескольких команд). Обзор итогов спринта (4 ч.). Ретроспективное совещание (1-3 ч.).

89 89 Подходы к созданию ИС 1. Разработка (самостоятельно или силами другой компании) 2. Прототипирование 3. Покупка готового решения, его адаптация и настройка под специфику предприятия 4. Покупка ядра ИС и ее модификация 5. Аренда ИС у ASP провайдера (Application Service Provider).

90 90 Собственная разработка ИС ДостоинстваНедостатки возможность разработки АИС для конкретных целей предприятия; возможность разработки АИС для конкретных целей предприятия; отсутствие функциональных, информационных и других ограничений, присущих готовым АИС; отсутствие функциональных, информационных и других ограничений, присущих готовым АИС; повышение степени совместимости АИС с уже использующимися на предприятии системами. повышение степени совместимости АИС с уже использующимися на предприятии системами. большие затраты ресурсов; большие затраты ресурсов; сложность в определении пользователем своих потребностей; сложность в определении пользователем своих потребностей; необходимость в жестком планировании и контроле над разработкой; необходимость в жестком планировании и контроле над разработкой; необходимость адекватной оценки возможностей; необходимость адекватной оценки возможностей; отсутствие необходимой квалификации у сотрудников. отсутствие необходимой квалификации у сотрудников.

91 91 Прототипирование Прототипирование – это подход к разработке ИС, при котором создается ее упрощенная действующая модель (прототип). Прототипирование – это подход к разработке ИС, при котором создается ее упрощенная действующая модель (прототип). Условия использования: Условия использования: небольшая команда проектировщиков- универсалов (от 2 до 10 человек); небольшая команда проектировщиков- универсалов (от 2 до 10 человек); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); использовании спиральной модели ЖЦ ИС; использовании спиральной модели ЖЦ ИС; тесное взаимодействие с заказчиком. тесное взаимодействие с заказчиком.

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

93 93 Границы применимости прототипирования Объем проекта и требования бизнеса четко определены, не изменяются, а сам проект невелик; Объем проекта и требования бизнеса четко определены, не изменяются, а сам проект невелик; проект не зависит от других средств автоматизации бизнеса, количество внешних интерфейсов ограниченно; проект не зависит от других средств автоматизации бизнеса, количество внешних интерфейсов ограниченно; система ориентирована на экранные формы, обработка данных и системные функции составляют незначительную часть, удобство экранных форм является важнейшим фактором успеха проекта; система ориентирована на экранные формы, обработка данных и системные функции составляют незначительную часть, удобство экранных форм является важнейшим фактором успеха проекта; пользователи имеют высокую квалификацию и изначально положительно оценивают идею создания новой системы. пользователи имеют высокую квалификацию и изначально положительно оценивают идею создания новой системы.

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

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

96 96 Аренда ИС у ASP провайдера Application Service Providing – это технология, позволяющая создавать решения по предоставлению в аренду пользователю необходимого набора телекоммуникационных служб и приложений, на основе удаленного доступа к информационному комплексу, на котором установлено специальное программное обеспечение. Application Service Providing – это технология, позволяющая создавать решения по предоставлению в аренду пользователю необходимого набора телекоммуникационных служб и приложений, на основе удаленного доступа к информационному комплексу, на котором установлено специальное программное обеспечение.

97 97 Задачи, решаемые с помощью АSP хостинг web - сайтов, почтовых служб; предоставление в аренду виртуальных торговых площадок для осуществления продаж/покупок через Интернет; обеспечение гибко настраиваемого доступа пользователей к различным функциям приложений; предоставление защищенного доступа к корпоративным данным; поддержка процессов электронного обмена данными; предварительная настройка компонентов ERP - систем на типовые задачи, что позволяет максимально сократить время внедрения таких систем в эксплуатацию; эксплуатация сложных ERP-систем

98 98 Типы ASP-решений Офисные и персональные приложения (Microsoft Office, игры, обучающие программы); Коммуникационные средства – электронная почта, проведение голосовых и видеоконференций, форум и т.д.; Приложения для электронной коммерции – электронные магазины, системы оплаты платежей; ERP-системы и отдельные приложения, например, CRM; Аналитические приложения – исследования и прогнозирование спроса, рисков и т.д.; Группы отраслевых приложений, представляющие собой специфические решения для определенных отраслей промышленности.

99 99 Аренда ИС у ASP провайдера ДостоинстваНедостатки Более низкая стоимость за счет распределения стоимости ASP-решения на нескольких арендаторов; гарантия фиксированной оплаты услуг; круглосуточная техническая поддержка; быстрое обновление оборудования. обеспечение информационной безопасности; обеспечение качественной бесперебойной связи; ответственность провайдера услуг при остановке или сбоях в работе сервера за бизнес своих клиентов