48783 (666088), страница 2

Файл №666088 48783 (Реинжиниринг программного обеспечения) 2 страница48783 (666088) страница 22016-07-31СтудИзба
Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Задачи, решаемые при реинжиниринге, включают:

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

  • определение актеров существующей системы;

  • определение функциональности существующей системы;

  • определение логической структуры системы;

  • восстановление реляционной модели данных.

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


Проблемы при реинжиниринге

Как правило утверждается, что "легче разработать новый программный продукт". Это связано со следующими проблемами:

  1. Обычному программисту сложно разобраться в чужом исходном коде

  2. Реинжиниринг чаще всего дороже разработки нового программного обеспечения, т.к. требуется убрать ограничения предыдущих версий, но при этом оставить совместимость с предыдущими версиями

  3. Реинжиниринг не может сделать программист низкой и средней квалификации. Даже профессионалы часто не могут качественно реализовать его. Поэтому требуется работа программистов с большим опытом переделки программ и знанием различных технологий.

В то же время, если изначально программа обладала строгой и ясной архитектурой, то провести реинжиниринг будет на порядок проще. Поэтому при проектировании как правило анализируется, что выгоднее провести реинжиниринг или разработать программный продукт "с нуля".


Управление требованиями


Требования к ПС

Требование – это характеристика или условие, которому должна удовлетворять ПС.

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

  • таких требований к системе обычно много,

  • заказчик не всегда способен четко сформулировать, чего он хочет от системы,

  • требования в итоговом документе должны быть изложены так, чтобы они одинаково понимались заказчиком и исполнителем и не допускали неоднозначности,

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

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

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

Управление требованиями – это достаточно сложный и растянутый во времени процесс. Он продолжается в течение большей части жизненного цикла, поскольку изменения могут вноситься как во время разработки, так и после сдачи системы на этапе опытной эксплуатации и при сопровождении. Причины этого заключаются в том, что требования:

  • неочевидны,

  • исходят из многих источников,

  • трудно формулируются (язык неоднозначен),

  • состоят из множества различных деталей,

  • неравнозначны,

  • связаны друг с другом,

  • лежат не только в функциональной области.

  • могут изменяться в течение разработки и при сопровождении.

Цели анализа и моделирования требований

Целями анализа и моделирования требований являются:

  • достижение соглашения между разработчиками, заказчиками и пользователями о том, что должна делать ПС;

  • достижение лучшего понимания разработчиками того, что должна делать система;

  • ограничение системной функциональности;

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

  • определение пользовательского интерфейса;

  • составление спецификации требований.

Роли

  • Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований.

  • Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований.

  • Заинтересованные лица – люди, предоставляющие информацию.

  • Эксперт – представитель заказчика, участвующий в разработке модели требований.

  • Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС.

Артефакты

Для достижения поставленных целей предусматривается создание следующих документов:

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

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

  • Спецификация требований (Software Requirements Specification) – основной документ, используемый при проектировании и разработке ПС. Она включает модель требований и дополнительные спецификации, которые представляют собой текстовое описание требований к конечному продукту, но не к процессу его разработки и не содержат деталей реализации требований.

  • Прототип пользовательского интерфейса обеспечивает визуальное представление интерфейса пользователя с ПС.

  • Глоссарий – текстовый документ, содержащий определения основных понятий и терминов, которые должны одинаково пониматься заказчиком и разработчиком. Источниками данных для создания перечисленных артефактов могут, в частности, служить артефакты, созданные при бизнес-анализе (см. статью «RUP. Обследование организации (бизнес-анализ)».


Процесс


В процессе анализа и моделирования требований можно выделить несколько основных этапов (см. рис.1).

Рис.1 Технологический процесс управления требованиями.

Начало анализа.

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

Результаты. Должен быть составлен документ «Предварительное соглашение», который будет являться отправной точкой для выполнения всех последующих работ. На этом этапе начинается создание глоссария. Если глоссарий был создан при бизнес-анализе, то он используется как отправной документ. Поскольку здесь речь идет о выявлении требований к ПС, в глоссарий могут включаться термины, относящиеся к реализации (например, броузер, сервер и др.). Определения этих терминов должны способствовать лучшему пониманию системы заинтересованными лицами.

Построение модели требований

Эта работа предполагает выявление актеров, ВИ и взаимодействий между ними. Если было проведено обследование организации, то в качестве источника для определения актеров и ВИ может служить бизнес-модель.

Если число ВИ слишком велико, то для упрощения читаемости и поддержки модели целесообразно разделить их по пакетам. Это также упрощает понимание модели и распределение ответственности путем назначения разработчиков, ответственных за пакеты ВИ. Пакеты позволяют организовать иерархию требований. Верхний уровень иерархии обычно определяется, исходя из основных видов деятельности организации. Если был выполнен бизнес-анализ, то основные виды деятельности уже представлены в бизнес-модели в виде пакетов, и они могут быть просто скопированы в модель требований. Пакетов верхнего уровня не должно быть много. Целесообразно выделить пакет администрирования и пакет вспомогательных действий, и 2 – 4 пакета, основных видов деятельности. В свою очередь, пакеты верхнего уровня могут включать пакеты следующего уровня и т. д.

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

Детализация модели требований

Цели данной деятельности:

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

  • обнаружение новых абстрактных актеров, которые играют роли, разделяемые несколькими актерами;

  • реструктуризация модели требований;

  • детальное описание потоков событий для ВИ;

  • задание приоритетов ВИ.

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

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

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

Составление дополнительных спецификаций

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

Проектирование пользовательского интерфейса

Этот процесс выполняется для того чтобы заказчик мог более точно представить себе работу и возможности будущей ПС и выдать свои замечания и уточнения требований. В зависимости от сложности проекта и уровня подготовленности заказчика результаты этих работ могут быть представлены в различных формах:

  • программная реализация, воспроизводящая точный вид экранных окон;

  • альбом экранных форм;

  • модель навигации экранов в виде диаграмм классов с указанием атрибутов – полей и операций – кнопок.

Создание спецификации требований

Характеристики

Тип файла
Документ
Размер
2,48 Mb
Тип материала
Учебное заведение
Неизвестно

Список файлов реферата

Свежие статьи
Популярно сейчас
А знаете ли Вы, что из года в год задания практически не меняются? Математика, преподаваемая в учебных заведениях, никак не менялась минимум 30 лет. Найдите нужный учебный материал на СтудИзбе!
Ответы на популярные вопросы
Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.
Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.
Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!
Да! На равне с готовыми студенческими работами у нас продаются услуги. Цены на услуги видны сразу, то есть Вам нужно только указать параметры и сразу можно оплачивать.
Отзывы студентов
Ставлю 10/10
Все нравится, очень удобный сайт, помогает в учебе. Кроме этого, можно заработать самому, выставляя готовые учебные материалы на продажу здесь. Рейтинги и отзывы на преподавателей очень помогают сориентироваться в начале нового семестра. Спасибо за такую функцию. Ставлю максимальную оценку.
Лучшая платформа для успешной сдачи сессии
Познакомился со СтудИзбой благодаря своему другу, очень нравится интерфейс, количество доступных файлов, цена, в общем, все прекрасно. Даже сам продаю какие-то свои работы.
Студизба ван лав ❤
Очень офигенный сайт для студентов. Много полезных учебных материалов. Пользуюсь студизбой с октября 2021 года. Серьёзных нареканий нет. Хотелось бы, что бы ввели подписочную модель и сделали материалы дешевле 300 рублей в рамках подписки бесплатными.
Отличный сайт
Лично меня всё устраивает - и покупка, и продажа; и цены, и возможность предпросмотра куска файла, и обилие бесплатных файлов (в подборках по авторам, читай, ВУЗам и факультетам). Есть определённые баги, но всё решаемо, да и администраторы реагируют в течение суток.
Маленький отзыв о большом помощнике!
Студизба спасает в те моменты, когда сроки горят, а работ накопилось достаточно. Довольно удобный сайт с простой навигацией и огромным количеством материалов.
Студ. Изба как крупнейший сборник работ для студентов
Тут дофига бывает всего полезного. Печально, что бывают предметы по которым даже одного бесплатного решения нет, но это скорее вопрос к студентам. В остальном всё здорово.
Спасательный островок
Если уже не успеваешь разобраться или застрял на каком-то задание поможет тебе быстро и недорого решить твою проблему.
Всё и так отлично
Всё очень удобно. Особенно круто, что есть система бонусов и можно выводить остатки денег. Очень много качественных бесплатных файлов.
Отзыв о системе "Студизба"
Отличная платформа для распространения работ, востребованных студентами. Хорошо налаженная и качественная работа сайта, огромная база заданий и аудитория.
Отличный помощник
Отличный сайт с кучей полезных файлов, позволяющий найти много методичек / учебников / отзывов о вузах и преподователях.
Отлично помогает студентам в любой момент для решения трудных и незамедлительных задач
Хотелось бы больше конкретной информации о преподавателях. А так в принципе хороший сайт, всегда им пользуюсь и ни разу не было желания прекратить. Хороший сайт для помощи студентам, удобный и приятный интерфейс. Из недостатков можно выделить только отсутствия небольшого количества файлов.
Спасибо за шикарный сайт
Великолепный сайт на котором студент за не большие деньги может найти помощь с дз, проектами курсовыми, лабораторными, а также узнать отзывы на преподавателей и бесплатно скачать пособия.
Популярные преподаватели
Добавляйте материалы
и зарабатывайте!
Продажи идут автоматически
6521
Авторов
на СтудИзбе
302
Средний доход
с одного платного файла
Обучение Подробнее