- •Лекция 2. Программный продукт. Проектирование компьютерных информационных систем
- •Программный продукт
- •Классификация программных продуктов по категориям пользователей
- •Правовые методы защиты программных продуктов и баз данных
- •Жизненный цикл, процессы и модели жизненного цикла программного продукта
- •Каскадная модель
- •Итерационная модель
- •Спиральная модель
- •Инкрементальная модель
- •Развитие инкрементального подхода. Технология использования xp-процессов.
- •Выбор модели жц программного проекта
- •Насколько стабильны требования?
- •Кто же является конечным пользователем системы?
- •Временные рамки проекта агрессивны или консервативны?
- •Где расположены команды проекта?
- •Какие ресурсы являются критическими?
- •Case - средства
- •Разработка информационных систем
- •Типовые уровни решений по построению единой аис
- •Разработка информационных систем под конкретную организацию
- •Понятие бизнес-процесса.
- •Реинжиниринг бизнес-процессов.
- •Разработка ис с помощью прототипирования
- •Основные принципы проектирования макета системы
- •Достоинства прототипного подхода к построению аис
- •Недостатки прототипного подхода к построению аис
- •Быстрое прототипирование технических систем
- •Быстрая разработка программных приложений (rad-метод) для организационно – административных систем
- •Axure rp (Rapid Prototyping) Pro – средство для прототипирования
- •Скорость разработки первой версии
- •Cкорость внесения изменений
- •Эстетичность
- •Просмотр прототипа заказчиком без установки дополнительных программ
- •Минимальная интерактивность
- •Разработка ис на основе готовых программных продуктов
- •Основные черты тпр и их классификация
- •Достоинства разработки информационных систем на базе ппп по сравнению с оригинальным проектированием:
- •Недостатки разработки информационных систем на базе ппп по сравнению с оригинальным проектированием
- •Информационная система, построенная на основе аутсорсинга (наиболее распространенная форма построения ис)
- •Исходные положения
- •Существует три больших плюса аутсорсинга.
- •Меньшая плата за квалифицированную работу.
- •Инвестирование развивающихся рынков.
- •Расширение бизнес-служб.
- •Почему аутсорсинг – зло?
- •Сложности взаимодействия.
- •Методы определения целесообразности аутсорсинга
- •Матрицы bcg
- •Недостатки представления ситуации в виде Матрицы бкг
- •К преимуществам Матрицы бкг относятся:
- •Правила построения матрицы бкг
- •Матрица аутсорсинга
- •Преимущества и недостатки аутсорсинга
- •Критерии выбора поставщиков по аутсорсингу
- •Виды аутсорсинга
- •Решение компании об использовании услуг it-аутсорсинга
- •Понятие и особенности it-консалтинга Понятие консалтинга.
- •Цели разработки консалтинговых проектов.
- •Этапы разработки консалтинговых проектов.
- •Особенности консалтинговых структур:
- •Основные виды консалтинговых услуг:
Разработка ис с помощью прототипирования
Самые дорогие ошибки — это ошибки, допущенные в начале проекта, так как именно на начальных этапах принимаются наиболее важные решения.
По мере развития проекта, стоимость ошибки снижается.
В то же время, начальный уровень контроля качества является минимальным и повышается по мере продвижения процесса разработки. Полноценное тестирование начинается только на поздних этапах.
Результатом часто является слишком позднее выявление самых дорогих ошибок и последующая дорогостоящая переработка системы либо ее отдельных частей. На первый взгляд может показаться, что некоторые проекты одинаковы по своей сути и содержанию. Скажем, типовым проектом для вас является интернет-магазин на базе существующей у вас системы. Но индивидуальность каждого проекта заложена даже в самом его определении.
Бытует мнение о том, что разработка однотипных проектов (например, создание интернет – магазинов) может проходить без этапа проектирования. Можно разделить задачу проектирования на создание типовых стандартных решений, которые кочуют из проекта в проект и творческие задачи, которые необходимо решать в каждом новом проекте.
Очевидно, что пользователи интернет-магазина по продаже удобрения и сельскохозяйственной техники будут сильно отличаться от пользователей магазина по продаже одежды и гламурных аксессуаров, как и будет отличаться их поведение на сайте, объекты внимания и т.д. Способно ли ваше стандартное решение учесть различия пользователей?
Стандартное решение — это набор компонентов, оттестированных и опробованных в различных проектах.
Понимание необходимости их адаптации (кастомизации) часто возникает в конце, когда происходит полноценное тестирование, а свободных ресурсов уже нет.
Это и есть та самая дорогая ошибка (перерасход проектного времени, приводящий к авралу, ухудшение качества). Парадокс новой экономики, о которой написал Купер — чтобы сэкономить, нужно заплатить (инвестировав в проектирование).
Любая создаваемая интегрированная система должна включать значительное количество объектов, обрабатывать большой объем информации и запросов в приемлемые сроки. Именно поэтому обоснованная выработка концепции построения системы требует проведения моделирования процессов, протекающих в реальной системе, и реализации МАКЕТА системы, на котором могут быть смоделированы наиболее важные свойства разрабатываемой системы, в том числе и альтернативные.
С учетом сложности, распределённости и разнообразия задач, для решения которых предназначается МАКЕТ, его системная среда функционирования должна удовлетворять следующим требованиям:
открытость и переносимость, упрощающие адаптацию к требованиям конкретного потребителя и обеспечивающие наращивание функциональной и интеллектуальной мощности в процессе эксплуатации без тотального перепрограммирования, т. е. в кратчайшие сроки и с минимальными затратами на разработку и сопровождение;
быстрая разработка приложений за счет интеграции в программную среду современных технологий: объектно-ориентированного подхода, технологии экспертных систем, CASE-технологии, имитационного моделирования, средств быстрой разработки приложений;
хранение значительных объемов данных и оперативный доступ к ним.
Рассмотрение взаимодействия даже небольшого количества объектов управления во времени и пространстве настолько повышает сложность практически значимых задач, что традиционные технологии и средства программирования мало пригодны для их решения. Недостатки традиционного подхода к созданию программных продуктов, состоящего из пяти последовательных этапов (анализ, проектирование, программирование, тестирование и интеграция), общеизвестны:
лавинообразное нарастание сложности,
непригодность для разработки сложных программных систем реального времени,
высокая стоимость внесения в систему последующих изменений,
обязательное последовательное выполнение всех этапов разработки,
несовместимость с эволюционным подходом и перспективными методами разработки.
Кроме того, при разработке большой и сложной системы, зачастую невозможно сформулировать строгие, детальные спецификации окончательного программного продукта на этапе анализа из-за инновационного характера разрабатываемой системы.
Проблемы создания МАКЕТА связаны с преодолением следующего ряда трудностей объективного характера:
высокая стоимость ошибок, которые могут быть допущены на ранних стадиях проектирования МАКЕТА, когда в будущую систему закладываются основные требования и определяются спецификации ее работы в действующей организационно-технологической среде;
неприемлемость длительной разработки программно-информационного обеспечения МАКЕТА, поскольку исходные требования к системе за это время могут существенно трансформироваться;
необходимость адекватной оценки эксплуатационных характеристик МАКЕТА и проверки удовлетворения требований к нему еще до окончательной реализации всего МАКЕТА, т.к. затраты на переделку сложной системы могут выходить за рамки финансовых ограничений;
необходимость и высокая трудоемкость моделирования процессов принятия решений с учетом всех особенностей решаемых задач;
принципиальная необходимость создания наращиваемого, развиваемого и переносимого программного продукта, жизненный цикл которого не должен заканчиваться с первыми сколько-нибудь существенными изменениями технологии работы, требований пользователей (требования пользователя ИМЕЮТ ПРАВО изменяться) и обновлением вычислительной базы;
минимизация количества несовместимых альтернативных программных платформ и инструментальных средств, используемых при создании МАКЕТА, поскольку в противном случае его будет слишком дорого либо невозможно сопровождать.
