Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ответы по ТРПС 12-24.docx
Скачиваний:
4
Добавлен:
25.11.2018
Размер:
113.94 Кб
Скачать
    1. Модели жц ис.

Модели жизненного цикла ПО ИС. Под моделью ЖЦ ИС понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ИС. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.

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

Итерационная модель (поэтапная модель с промежуточным контролем, рис. 2.4). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

Спиральная модель. Виток спирали определяет очередную версию продукта, в которой уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

    1. Основные функции и назначение АИС.

    1. Этапы разработки АИС

Этапы проектирования аис и их характеристики

Наименование этапа

Основные характеристики

1.

Разработка и анализ бизнес-модели

Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции, с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС).

Метод решения: Функциональное моделирование.

Результат: 1. Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2. Аппаратно-технический состав создаваемой АИС.

2.

Формализация бизнес-модели, разработка логической модели бизнес-процессов

Разработанная концептуальная модель формализуется в виде логической модели АИС.

Метод решения: Разработка диаграммы «сущность-связь» (ER (Entity-Relationship) – CASE- диаграммы).

Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.

Наименование этапа

Основные характеристики

3.

Выбор лингвистического обеспечения, разработка программного обеспечения АИС.

Разработка АИС: выбирается лингвистическое обеспечение (среда разработки – инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы – в пользовательские формы и приложения.

Метод решения: Разработка программного кода с использованием выбранного инструментария.

Результат: Работоспособная АИС.

4.

Тестирование и отладка АИС

На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п.

Результат: Оптимальный состав и эффективное функционирование АИС.

Комплект документации: разработчика, администратора, пользователя.

5.

Эксплуатация и контроль версий

Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то, как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20–30%.

Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

Замечание. На обнаружение ошибок, допущенных на стадии системного проектирования (2-я и 3-я стадии), расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных стадиях проекта разработку следует выполнять особенно тщательно. Наиболее часто на начальных фазах допускаются следующие ошибки:

  • ошибки в определении интересов заказчика;

  • концентрация на маловажных, сторонних интересах;

  • неправильная интерпретация исходной задачи;

  • неправильное или недостаточное понимание деталей;

  • неполнота функциональных спецификаций (системных требований);

  • ошибки в определении требуемых ресурсов и сроков;

  • редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

Последовательность трансформации бизнес-модели в объекты базы данных

Последовательность работ

Разработка и анализ бизнес-модели. Определение и назначение функций ИС

Моделирование процессов предметной области

Разработка модели сущность-связь. Разработка CASE-диаграммы

Исследование бизнес-процессов аналогичной модели

Формирование объектов БД

Методы функционального анализа

Oracle Designer, Power Designer, Power Soft и др.

Oracle Designer, Erwin, BPwin и др.

Oracle Designer, Silverun-RDM и др.

SQL и др.средства выполнения SQL-скриптов

Средства разработки

Порядок выполнения практических работ по проектированию ИС может быть следующим.

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

  • Предварительная информация. Предполагается, что в начале обследования проведен предварительный сбор информации о компании, по итогам которого получены следующие данные:

  • краткая информация о компании (профиль клиента);

  • цели проекта;

  • подразделения и пользователи системы.

На основе предварительной информации сформировано и согласовано с заказчиком общее представление о проекте:

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

  • Отчет об обследовании содержит следующие разделы:

  1. Анализ существующего уровня автоматизации: составляется список программного обеспечения, используемого в компании, и приводятся данные об использовании этих пакетов в каждом из подразделений организации.

  2. Общие требования к ИС: формулируются общие требования к функциональности разрабатываемой системы.

  3. Формы документов: устанавливается перечень и структура документов, которые должны формироваться системой.

  4. Описание системы учета включает в себя следующие документы:

  • учетная политика компании;

  • план счетов и используемых аналитик;

  • список типовых хозяйственных операций и их отражение в проводках.

  1. Описание справочников: по каждому справочнику, проектируемому в системе, дается описание необходимой иерархической структуры.

  2. Организационная диаграмма: используется для отражения организационной структуры подразделений предприятия и их зон ответственности.

  3. Описание состава автоматизируемых бизнес-процессов: все бизнес-процессы компании должны быть перечислены в общем списке и каждый должен иметь свой уникальный номер.

  4. Диаграммы прецедентов: для выделения автоматизируемых бизнес-процессов и их основных исполнителей используются диаграммы прецедентов.

  5. Физическая диаграмма: служит для того, чтобы описать взаимодействие организации на верхнем уровне с внешними контрагентами.

  6. Описания бизнес-процессов (книга бизнес-процессов содержит подробное описание автоматизируемых бизнес-процессов. Модели бизнес-процессов позволяют выделить отдельные операции, выполнение которых должно поддерживаться разрабатываемой ИС).

  1. На последнем этапе осуществляется отображение модели предметной области на функциональность типовой системы – выбираются модули системы для поддержки выделенных операций, определяются особенности их настройки, выявляется необходимость разработки дополнительных программных элементов.

    1. Классификация ИС.

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.