Участники проекта по разработке информационной системы поддержки (ИСП) и используемые ими модели. Этапы разработки ИСП. — КиберПедия 

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

Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...

Участники проекта по разработке информационной системы поддержки (ИСП) и используемые ими модели. Этапы разработки ИСП.

2017-08-23 1640
Участники проекта по разработке информационной системы поддержки (ИСП) и используемые ими модели. Этапы разработки ИСП. 0.00 из 5.00 0 оценок
Заказать работу

Разработка ПО - это бизнес-процесс в компании, занимающейся созданием ПП.

Построение ИС - это процесс, описывающий различные стороны этой системы. Подобно разработке бизнес-системы, разработка ИС тоже имеет своих участников.

Участник – это некто, выдвигающий требования к ИС или просто заинтересован в ее освоении.

Наиболее важные участники разработки ИСП - это заказчики и пользователи. Их не интересует как будут реализована ИС, для них самое важное то, что система может делать и как её использовать. Для этого необходимо разработать различные сценарии использования системы. Эти сценарии должны быть представлены в терминах прецедентной модели. Субъекты в таких моделях отображают разнообразные роли, которые могут играть участники бизнес-процессов и пользователи ИС.

Конечные пользователи. Для них важно, что может система делать, и не интересно, как это реализовано. Модели использования/прецедентные.

Системные аналитики. Необходима модель, на основе которой они будут создавать гибкие системы. Важно выделить независимые функциональные группы, такие, чтобы внесение изменений в приложение не воздействовало на всю систему в целом, чтобы удовлетворить этому требованию целесообразно разрабатывать идеальные объектные модели информационной системы. Системные аналитики работают над созданием идеальной объектной модели, которые абстрагированы от конкретной реализации.

Проектировщикам нужны модели, позволяющие описывать различные способы выполнения системы вплоть до создания программного кода. Им необходимо знать, как взаимодействуют классы при реализации прецедентов. Они нуждаются в реальной объектной модели, которая представляет собой некоторую абстракцию программного кода. В этой модели принимаются во внимание такие важные технические аспекты, как среда разработки и её ограничения. Результатом проектирования приложения являются исходные тексты программ, которые образуют модель реализации системы. Проектировщик создает программный код.

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

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

Этапы разработки ИСП:

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

2. Анализ требований. Цель в проверке полноты и непротиворечивости спецификации требований. Далее строится П-модель ИС. Может быть разработан прототип графического интерфейса пользователя.

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

4. Реальное проектирование. Разрабатывается модель, служащая базисом для реализации ИС. Результат - реальная объектная модель информационной системы.

5. Реализация. На этом этапе создается программный код ИС.

6. Тестирование. Проверяется соответствие ИС предъявляемым к ней требованиям. Результатом этого этапа должны быть корректные результаты прогона системы на тестовых задачах.


16. П-модель и О-модель информационной системы

В П-модели субъекты представляют роли, которые могут исполнять пользователи системы, а прецеденты - те действия, которые они могли бы производить над ней. Каждый прецедент - это завершенный поток событий в ИС, рассматриваемый с точки зрения пользователя.

Прецеденты в информационной системе играют две важные роли:

1. естественным образом описывают функциональные требования к ИСП. П-модель должна быть дополнена одной или несколькими объектными моделями;

2. прецеденты структурируют каждую О-модель. Каждая О-модель соответствует одному прецеденту ИС. Один объект может использоваться разными прецедентами.

Чтобы справится со сложностью реальной ИС полезно структурировать О-модели таким образом, чтобы каждая из них представляла некоторый отдельный аспект её использования. В описываемом подходе каждый аспект соответствует одному прецеденту и его описание включает только те объекты, которые участвуют в этом прецеденте. Разумеется, один объект может использоваться разные прецеденты.

При описании О-модели объекты представляют участников процессов и различные сущности (предметы, задачи), используемые в ходе выполнения процессов. Имена уникальные (существительные). Типы объектов:

Интерфейсные объекты - поддерживают (экраны (окна), протоколы связи, интерфейсы с датчиками и устройствами вывода на печать)

Объекты-сущности (документация, хранящаяся в БД)

Управляющие объекты - используются для описания поведения системы, задаваемого прецедентами, обычно они управляют другими объектами и выполняют роль координаторов в модели (посредники между интерфейсными объектами и объектами сущностями).

Интерфейсные объекты:

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

 

 


17. Анализ требований к ИСП

 

Задача – установить границы ИС и определить, какие функции она должна выполнять.

 

На основании списка требований формируется спецификация:

· требования в ней непротиворечивы;

· определена взаимосвязь и взаимозависимость требований;

· установлены приоритеты требований;

· сделана оценка сроков реализации.

 

На основании этого строится прецедентная модель.



Поделиться с друзьями:

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

Состав сооружений: решетки и песколовки: Решетки – это первое устройство в схеме очистных сооружений. Они представляют...

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого...

Типы оградительных сооружений в морском порту: По расположению оградительных сооружений в плане различают волноломы, обе оконечности...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.011 с.