Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
TSPP Ekzamen - Otveti na voprosi 2.0.docx
Скачиваний:
5
Добавлен:
17.04.2019
Размер:
511.02 Кб
Скачать
  1. Системный подход к разработке по (определение системы, свойства и виды систем).

Введение в дисциплину. Системный подход к разработке ПО

В начале 70-х гг. XX в. большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов. В числе причин неудач:

  • нечеткая и неполная формулировка требований к ПО;

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

  • неудовлетворительное планирование;

  • частое изменение требований и спецификаций;

  • новизна используемых технологий; и пр.

Свойства, виды систем

Система — совокупность взаимосвязанных и, часто, взаимодействующих элементов.

Элемент (вообще) — это нечто (предмет, единица, сущность), обладающее следующими свойствами:

  • внутренне связное;

  • имеющее четко очерченные границы с внешней средой;

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

  • часто, обладающее определенным поведением;

  • часто, имеющее себе подобных.

Типизация — образование и использование типов объектов, предназначенное для защиты от использования объектов одного типа вместо другого.

Декомпозиция системы — выделение объектов, частей, подсистем из целого.

Внутренняя связь объектов выше связи между объектами. Чем больше это различие, тем лучше выполнена декомпозиция.

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

  1. Системный подход к разработке по (сложность программных систем и пути её преодоления).

Сложность систем и ее причины

Cложность программных систем (ПС) может быть обусловлена:

  • сложностью реальной предметной области;

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

  • неудовлетворительными способами описания систем;

  • неудовлетворительными или неподходящими средствами реализации систем;

  • нечеткостью формулирования требований;

  • взаимными противоречиями предъявляемых требований;

  • отсутствием аналогов, типовых проектных решений;

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

  • функционированием в неоднородной;

Нечеткость формулировки могут быть вызваны:

  • смутностью представлений заказчика о предмете разработки;

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

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

  1. Жизненный цикл по (определение, этапы жизненного цикла по)

Жизненным циклом ПО называется период времени с момента принятия решения о необходимости создания ПО до момента его полного изъятия из эксплуатации.

Разработка ПО включает в себя, анализ, проектирование и реализацию.

Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию и непосредственно эксплуатацию.

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

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

Стратегии, модели и процессы конструирования ПО

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

Существуют три стратегии конструирования ПО:

  • однократный проход (каскадная стратегия) — линейная последовательность этапов конструирования;

  • инкрементная стратегия — итерационное повторение проходов с целью наращивания функциональности ПО;

  • эволюционная стратегия — то же, что инкрементная, плюс постепенное уточнение требований.

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

В состав жизненного цикла ПО входят стадии:

  1. формирование требований;

  2. проектирование;

  3. реализация;

  4. тестирование;

  5. ввод в действие (внедрение);

  6. эксплуатация и сопровождение;

  7. снятие с эксплуатации.

Существуют мо­дели:

  • каскадная модель;

  • спиральная модель;

  • модель формальной разработки;

  • модель разработки ПО на основе ранее созданных компонентов.

Интернет

Основные:

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

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

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

-Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

Вспомогательные

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

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

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

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

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

-Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

-Аудит (определение соответствия требованиям, планам и условиям договора)

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]