СиППО (46-53) (987682)

Файл №987682 СиППО (46-53) (Ответы на все вопросы)СиППО (46-53) (987682)2015-08-02СтудИзба
Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла





46. Процесс определения требований к программным средствам. Документирование требований с помощью диаграмм.

47. Процесс анализа и структурирования требований при разработке программных средств.

48. Процесс проектирования при разработке программных средств. Основные отличия моделей анализа и проектирования.

Проектирование архитектуры

Проектирование вариантов использования

Проектирование классов и подсистем

49. Процесс реализации при создании программных средств.

50. Особенности тестирования программных средств, построенных по объектно-ориентированной методике. Тестирование классов.

51. Тестирование взаимодействия классов. Тестирование иерархии классов.

52. Тестирование целостности и системное тестирование.

53. Сравнение объектно-ориентированного и процедурного программирования.



46. Процесс определения требований к программным средствам. Документирование требований с помощью диаграмм.

Анализ состоит из двух подфаз:

· Определение требований.

· Уточнение и структурирование требований.

Цель определения требований - ответить на вопрос: что должна делать система для каждого пользователя? Правильный и исчерпывающий ответ на этот главный вопрос позволит направить процесс разработки на получение правильной системы. Определением требований занимаются системные аналитики. Основное внимание следует обратить на то, что клиенты, с которыми мы работаем (которые являются главным нашим источником информации и, как правило, не являются специалистами по информационным технологиям) должны быть способны прочесть и понять результаты определения требований. Для выполнения этого условия для описания требований следует использовать язык клиента. Типовой рабочий процесс определения требований включает следующие тесно взаимосвязанные шаги:

· Перечисление возможных требований.

· Описание контекста системы.

· Определение функциональных требований.

· Определение нефункциональных требований.

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

· Состояние предложения (предложено, одобрено, включено в план работ).

· Сметная стоимость реализации.

· Приоритет (критический, важный, вспомогательный).

· Уровень риска, связанного с реализацией предложения.

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

Описание контекста системы может быть выполнено двумя способами:

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

· Бизнес – моделирование.

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

В более сложных случаях модель предметной области можно описать диаграммой классов (в относительно простых предметных областях 10-50 классов). Напомним, что модель предметной области должна описывать именно контекст (т.е. окружение) разрабатываемой системы, а не ее внутреннюю структуру. Глоссарий и модель предметной области обеспечат единообразное применение терминов всеми участниками разработки. Также они могут в дальнейшем помогать при определении внутренних классов. Эта модель описывает статику предметной области.

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

Бизнес – модель является надмножеством над моделью предметной области и ее составление - более сложный процесс. Целесообразность создания упомянутых моделей решается каждый раз отдельно руководителем проекта.

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

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

Таблица 4.1.

Операция

Результат

Перечисление кандидатов в требования

Список предложений

Разобраться в контексте системы

Бизнес – модель и/или модель предметной области

Определить функциональные требования

Модель вариантов использования

Соответствуют традиционному техническому заданию

Определить нефункциональные требования

Дополнительные требования

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

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

· отделения системы от окружения;

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

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

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

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

Выделенные действующие лица должны быть идентифицированы и снабжены кратким описанием.

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

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

2. Какие существуют пути реализации варианта использования: выбираемые действующим лицом или зависящие от хода выполнения?

3. Как заканчивается выполнение варианта использования? Какие имеются конечные состояния? Как о результате узнает действующее лицо?

4. Какие существуют запрещенные пути выполнения? Как предотвращается их запуск? Должно ли передаваться сообщение о попытке их запуска?

5. Что в процессе выполнения делает действующее лицо и что делает программа?

6. Какие исходные данные (пока на качественном уровне) требуются от действующего лица?

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

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

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

1. Какие элементы пользовательского интерфейса необходимы ему для выполнения его вариантов использования?

2. Какие действия он может производить?

3. Какую информацию он должен вводить при запуске различных вариантов использования?

4. Каким образом он будет информирован о результатах выполнения (с учетом того, что ход выполнения и результат могут быть различными)?

Заканчивается эта подфаза структурированием модели вариантов использования, в ходе которого:

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

· извлекаются дополнительные и необязательные описания функциональности;

· проводят классификацию действующих лиц.

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

Подведем итоги. В результате выполнения работ по определению требований должны быть получены (программа-минимум):

1. Модель вариантов использования (одна или несколько диаграмм).

2. Эскизы интерфейсов пользователей для всех действующих лиц.

3. Описания вариантов использования.

4. Основные нефункциональные требования.



47. Процесс анализа и структурирования требований при разработке программных средств.

Анализ состоит из двух подфаз:

· Определение требований.

· Уточнение и структурирование требований.

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

Таблица 4.2.

Модель вариантов использования

Аналитическая модель

Использует язык заказчика

Использует язык разработчика

Представляет внешний вид системы

Представляет внутренний вид системы

Структурирована по вариантам использования

Структурирована по стереотипам классов и пакетам

Используется в первую очередь как соглашение между заказчиком и разработчиком (что должна делать система)

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

Может содержать избыточность, несовместимые требования

Не должен содержать избыточности, несовместимостей

Определяет функциональность системы

Описывает реализацию функциональности

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

Определяет реализации вариантов использования.

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

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

Тип файла
Документ
Размер
80,63 Kb
Высшее учебное заведение

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов ответов (шпаргалок)

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