Этапы Классический жизненный цикл

Билет

1. Критерии качества программного средства. Определение качества ПО в стандарте ISO 9126. Многоуровневая модель качества ПО. Оценочные характеристики качества программного продукта

Ответ

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

Совместно используемые утилиты объединяются в системы автоматизированной разработки ПО

 Такие системы принято называть CASE-средствами (Computer Aided Software Engineering)

Качество ПО – это вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц (стандарт ISO 9126)

Основными критериями качества ПО:

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

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

- эффективность (Соотношение уровня услуг, предоставляемых ПО пользователю при заданных условиях, и объема используемых для этого ресурсов.

-эргономичность (Характеристики ПО, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПО и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя)

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

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

 

Стандарт ISO 9126 - Международный стандарт, определяющий оценочные характеристики качества программного обеспечения.

Разделяется на 4 части, описывающие следующие вопросы:

-модель качества;

-внешние метрики качества;

-внутренние метрики качества;

-метрики качества в использовании.

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

Различаются понятия:

-внутреннего качества,

-внешнего качества,

-качества ПО при использовании

Три аспекта качества ПО

-Внутреннее качество связано с характеристиками ПО самого по себе, без учета его поведения;

-Внешнее качество характеризующего ПО с точки зрения его поведения;

-Качества ПО при использовании – это то качество, которое ощущается пользователями при конкретных сценариях работы ПО.

Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель.

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

Билет

1. Жизненный цикл программного продукта, фазы жизненного цикла.
2. Этапы классического жизненного цикла, их содержание.

Ответ

Жизненным циклом программного обеспечения называется весь период времени от начала его разработки до завершения использования

Жизненный цикл ПО состоит из фазы разработки, фазы использования и фазы продолжающейся разработки (модификации),

Модель процесса разработки ПО выделяет конкретные наборы видов деятельности, артефактов, ролей и их взаимосвязи, а также дает рекомендации по организации процесса в целом

Отдельные модели соответствуют одной из стратегий разработки – линейной (предполагает однократное прохождение всех этапов разработки ПО

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

Этапы Классический жизненный цикл

· Анализ относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс. Здесь же завершается решение задачи планирования проекта.

·, проектирование Состоит из: ( архитектуры ПО, модульной структуры ПО, алгоритмической структуры ПО, структуры данных, входного и выходного интерфейса (входных и выходных форм данных))

·, кодирование состоит в переводе результатов проектирования в текст на языке программирования.

·, тестирование выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

· Сопровождение- это внесение изменений в эксплуатируемое ПО(исправление ошибок, усовершенствование По по требованиям заказчика)

· Выпуск системы

Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Билет

Фаза разработки, этапы процесса разработки.

Стратегии конструирования ПО: линейная, инкрементная, эволюционная

Ответ

Модель процесса разработки ПО выделяет конкретные наборы видов деятельности, артефактов, ролей и их взаимосвязи, а также дает рекомендации по организации процесса в целом

Отдельные модели соответствуют одной из стратегий разработки – линейной (предполагает однократное прохождение всех этапов разработки ПО

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

Билет

1. Стандарт ISO/IEC 12207-95: основные определения – система, модель жизненного цикла, квалификационные требования. Основные процессы, их содержание, работы и задачи процесса разработки.

Ответ

ISO/IEC 12207 – определяет процессы жизненного цикла ПО.

По определению, ISO/IEC 12207-95 — базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, куда ПО входит как часть

- Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

-Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО

-Он определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО …-ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны — из одной организации

Определения стандарта:

Система — это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей

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

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

Основные процессы ЖЦ

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

Включает такие работы, как

-инициация приобретения,

-подготовка запроса предложений,

-подготовка контракта,

-анализ поставщиков,

-получение ПО.

Процесс передачи (поставки). Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.

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

Включает следующие работы:

-развертывание процесса разработки,

-анализ системных требований,

-проектирование (программно-аппаратной) системы в целом,

-анализ требований к ПО,

-проектирование архитектуры ПО,

-детальное проектирование,

-кодирование,

-отладочное тестирование,

-интеграцию ПО,

-квалификационное тестирование ПО,

-системную интеграцию,

-квалификационное тестирование системы,

-развертывание (установку или инсталляцию) ПО.

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

Включает такие работы, как:

-консультирование пользователей,

-получение обратной связи и др.

Билет

1. Стандарт ISO/IEC 15504 (SPICE): оценка возможностей разработчика. Связь этого стандарта с моделью зрелости предприятия SEI CMM.

Ответ

Ориентирован на оценку процессов и возможностей их улучшения; определяет правила такого оценивания

В основу этого стандарта положена концепция аттестации (assessment) процессов, в отличие от типового для других стандартов ISO понятия " аудит"

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

Определяются 5 категорий, включающих 35 процессов и 201 вид деятельности

Например, приобретение ПО включает такие виды деятельности, как:

n определение потребности в ПО,

n определение требований,

n подготовку стратегии покупки,

n подготовку запроса предложений,

n выбор поставщика

Стандарт ISO/IEC 15504 опирается на стандарт SEI Модель зрелости возможностей CMM 

Этот стандарт предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня

Билет

1. Прогностические модели процесса разработки: каскадная, RAD, спиральная.

Ответ

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

 Спиральная модель определяет четыре действия:

-Планирование(заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений)

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

-конструирование(это основное действие, заключающееся в создании следующей версии ПО)

-оценивание.( оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований)

Данная модель отображает процесс разработки ПО в наиболее реальном виде; позволяет явно учитывать риски на каждом витке эволюционного процесса и принимать различные управленческие решения вплоть до прекращения работ

Недостатки модели:

-повышенные требования к заказчику;

-трудности контроля и управления временем разработки

Каскадная модель Предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким определением границ между этапами

Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа

Достоинства модели:

-упорядоченность процесса разработки

-возможность его строгого планирования во времени.

Недостатки модели:

-необходимость точной и полной формулировки требований к ПС перед началом разработки

-невозможность изменения решений, принятых на предыдущих этапах

-результаты проекта становятся доступны заказчику только по завершении работ.

RAD-модель Модель быстрой разработки приложений..

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

Ее основной недостаток заключается в наличии риска увеличения срока разработки из-за подготовки большого числа версий

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

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

Основным достоинством модели является уменьшение сроков разработки

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

Билет

Ответ

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

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

Экстремальное программирование ( XP-процесс) адаптивная модель- ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований

Основная идея XP- процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций.

Базовыми действиями являются:

-кодирование,

-тестирование,

-выслушивание заказчика,

-проектирование

Принципы разработки:

-непрерывная связь с заказчиком,

-простота выбираемых решений,

-быстрая обратная связь на основе оперативного тестирования,

-профилактика рисков

Реализация этих принципов достигается за счет использования следующих методов:

Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система

Простое проектирование – принимаются наиболее простые из возможных проектные решения

Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант

Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения

Парное программирование – код пишется двумя программистами на одном компьютере

Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы

Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований

Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика

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

Scrum-модель пример адаптивного процесса разработки

Основная идея: Экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды

Главные действующие роли:

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

- Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон,

- Команда, которая включает разработчиков

Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно, 15-30 дней) 

Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ

Планирование спринта Запросы на выполнение работ определяются на этапе совета по планированию спринта

На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены

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

Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта

На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта

Билет

1. Руководство программным проектом. Предварительные оценки проекта. Системный анализ и анализ требований. Анализ рисков. Планирование процесса разработки. Типовая структура распределения работ.

Ответ

Начало проекта

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

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

· выявить технические и управленческие ограничения.

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

Процесс оценки. При планировании программного проекта надо оценить людские ресурсы, продолжительность (в календарных датах), стоимость

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

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

Трассировка и контроль

 

Билет

1. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей.
2. Методология IDEF0, синтаксис IDEF0-моделей.

Ответ

Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называется анализом предметной области или бизнес-моделированием,

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы.

В результате

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

- выявить цели их деятельности;

- определить набор решаемых ими задач;

-определить набор сущностей, с которыми приходится иметь дело при решении этих задач

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

Анализом предметной области занимаются системные аналитики или бизнес-аналитики

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

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

Под системой подразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними

Моделью M некоторой системы S называется информационный объект, который может быть использован для получения ответов на некоторый круг вопросов относительно S

Характеристики модели

К ним относятся:

-цель моделирования,

-объект моделирования,

-точка зрения модели,

-средство моделирования

Модель должна быть адекватна целям и объекту моделирования

Цель моделирования

-Получение ответов на эту совокупность вопросов

-Цель моделирования формулируется на самом раннем этапе разработки модели

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

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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

-модели, зависящие от подхода к разработке (структурного или объектно-ориентированного)

-модели, не зависящие от подхода к разработке

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

Объектный подход

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

процедуры + структуры данных = классы

Классификация моделей

◦ . IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);

Синтаксис IDEF0-моделей

Основной формой представления IDEF0-модели является диаграмма

Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки).

◦ Блоки изображают функции моделируемой системы.

◦ Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками 

Билет

1. Диаграммы потоков данных (DFD-диаграммы) и диаграммы потоков работ (IDEF3-диаграммы), их использование при моделировании предметной области.

Ответ

Эти диаграммы (Data flow diagramming, DFD) хорошо дополняют функциональные диаграммы модели, описывая потоки данных

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

Используются для описания документооборота, обработки информации

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

Главная цель декомпозиции DFD-функций- продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами

На DFD-диаграммах могут присутствовать следующие элементы:

-функциональные блоки (процессы);

-стрелки (данные);

-хранилища данных;

-внешние ссылки

Билет

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

Ответ

Этап анализа (analysis) состоит в исследовании системных требований и проблемы,

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

. Задачи:

1) Понять проблему или проблемы, которые программная (или иная) система должна решить.

2) Задать значимые вопросы о проблеме и о системе.

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

4) Определить, что система должна делать.

5) Определить, что система не должна делать.

6) Убедиться, что система удовлетворит потребности ее пользователей и определить критерии ее приемки. Это особенно важно, когда система разработана по контракту для внешнего клиента.

7) Обеспечить основу для разработки системы.)

Предметная область: Что делается Как делаетсяГде делается Кто делает Когда делаетсяЗачем делается

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

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

Для этого надо ответить на вопросы:

· Кто будет снабжать систему информацией?

· Кто будет получать информацию от системы?

· Кто будет осуществлять поддержку и обслуживание системы?

· Использует ли система внешние ресурсы?

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

Нефункциональные требования к системе, их виды.

Описывают характеристики системы и ее окружения

Эргономичность: Для достижения высокой скорости обслуживания покупателей при его высоком качестве необходимо:

· обеспечить минимальное время отклика системы,

· текст должен быть виден с расстояния 1 м,

· не должно быть мерцания экрана,

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

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

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

— Одна из основных причин задержки – низкая скорость авторизации

— Необходимо обеспечить выполнение авторизации менее, чем за 1 минуту в 90% случаев

 

Билет

1. Функциональные требования к системе. Способ их представления в виде UML-диаграммы. Пример диаграммы с использованием отношений «расширяет» и «включает».
2. Понятие прецедента и сценария

Ответ

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

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

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

 

Билет

1. Концептуальная модель системы: концептуальные классы, системные события и системные операции. Способ их представления в виде UML-диаграмм. Пример концептуального описания прецедента.

Ответ

Концептуальная модель — это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.

Отображает наиболее важные для цели моделирования классы понятий (концептуальные классы) предметной области

Кроме того концептуальная модель может отображать

1. ассоциации между концептуальными классами,
2. атрибуты концептуальных классов

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

Системное событие (systemevent) — это событие высокого уровня, генерируемое внешним исполнителем (событие с внешним входом). Системные события связаны с системными операциями (systemoperation), т.е. операциями, выполняемыми системой в ответ на события.

Билет

1. 
   Диаграммы взаимодействия как элементы концептуальной модели. Синтаксис диаграмм взаимодействия.

Ответ

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

· диаграммы кооперации,

· диаграммы последовательностей

— В обоих случаях взаимодействие объектов представляется в виде обмена сообщениями

Билет

1. Проектирование программных средств. Цели и задачи этапа проектирования. Понятие модели проектирования, ее отличия от концептуальной модели. Стадии проектирования, их краткая характеристика.

Ответ

Проектирование — процесс разработки проекта, то есть комплекта документации, предназначенной для создания определённого объекта, его эксплуатации, ремонта и ликвидации, а также для проверки или воспроизведения промежуточных и конечных решений, на основе которых был разработан данный объект

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

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

этапы процесса проектирования:

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

2)Разбиение большой системы на домены (пакеты)-диаграмма доменов (пакетов), описание доменов (пакетов), описание связей (мостов) между доменами (пакетами);

3)Разбиение большого домена (пакета) на поддомены(диаграмма поддоменов, описаниеподдоменов).

4)Разработка домена(статическая модель домена - диаграмма классов, модели состояний (диаграммы активности, диаграммы состояний, диаграммы взаимодействия, диаграммы последовательностей), описания моделей)

Выделяют три стадии проектирования:

-эскизное проектирование (Разрабатываемый программный продукт рассматривается как часть системы обработки информации, включающей аппаратную и программную составляющие; -набор взаимодействующих подсистем(на этой стадии определяется архитектура системы); Обеспечивает:

-идентификацию подсистем

-определение характера взаимодействия подсистем и принципов управления ими Включает три типа деятельности:

-структурирование системы

-моделирование управления

-декомпозиция подсистем на модули

Результаты эскизного проектирования представляются в виде эскизного проекта

-детальное проектирование (На стадии детального проектирования конкретизируются решения архитектурного уровня и производится:

-разработка иерархии классов и структуры базы данных;

-построение алгоритмов для отдельных подзадач;

-поиск и подбор готовых компонентов для реализации некоторых функций системы)

-Интерфейсное проектирование

Целью интерфейсного проектирование является формирование интерфейса пользователя Пользовательский интерфейс объединяет в себе все элементы и компоненты программы, которые способны оказывать влияние на его взаимодействие с программным обеспечением.ее внедрению.

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

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

 

Билет

123456789Следующая ⇒

Поделиться: