Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Спиральная модель ЖЦ ПО и ИС. Основные преимущества и недостатки.

Читайте также:
  1. I. Основные богословские положения
  2. II Основные источники загрязнений гидросферы.
  3. II. Модель
  4. II. Основные положения учения Ф. де Соссюра о языке.
  5. II. Основные теории по анализу международных отношений.
  6. II.1.1 Основные источники информации для оценки эффективности строительной организации
  7. III. Назовите основные последствия прямохождения человека (т.е. изменения в строении, физиологии, поведении) в опорно-двигательной системе.
  8. III. Основные положения лингвистической концепции В. фон Гумбольдта.
  9. III. Основные положения синтетической теории эволюции
  10. III. ОСНОВНЫЕ ПРИНЦИПЫ МАТЕРИАЛИСТИЧЕСКОГО УЧЕНИЯ К. МАРКСА И Ф. ЭНГЕЛЬСА.

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

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

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

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

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

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

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

7. Стандарт жизненного цикла ПО (ИСО/МЭК 12207).Содержание процесса разработки (состав работ).

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

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) анализ требований к системе;

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

3) проектирование системной архитектуры;

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

4) анализ требований к программным средствам;

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

5) проектирование программной архитектуры;

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

6) техническое проектирование программных средств;

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

7) программирование и тестирование программных средств;

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

8) сборка программных средств;

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

9) квалификационные испытания программных средств;

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

10) сборка системы;

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

11) квалификационные испытания системы;

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

12) ввод в действие программных средств;

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

13) обеспечение приемки программных средств.

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

8. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процесс разработки. Содержание работ «анализ требований» и «проектирование архитектуры» в применении к системе и ПО

Анализ требований к системе

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

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

a) учет потребностей заказчика;

b) соответствие потребностям заказчика;

c) тестируемость;

d) выполнимость проектирования системной архитектуры;

e) возможность эксплуатации и сопровождения.

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

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

Системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):

a) учет требований к системе;

b) соответствие требованиям к системе;

c) соответствие используемых стандартов и методов проектирования;

d) возможность программных объектов архитектуры выполнять установленные для них требования;

e) возможности эксплуатации и сопровождения.

9. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процесс разработки. Содержание работы по детальному проектированию ПО.

Техническое проектирование программных средств

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

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

Разработчик должен разработать и документально оформить технический проект базы данных.

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

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

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

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

a) учет требований к программному объекту;

b) внешнее соответствие спроектированной архитектуре;

c) внутренняя согласованность между компонентами программного объекта и программными модулями;

d) соответствие методов проектирования и используемых стандартов;

e) возможность тестирования;

f) возможность эксплуатации и сопровождения.

10. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процесс разработки. Содержание работ по интеграции и квалификационному тестированию ПО

Сборка программных средств

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

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

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

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

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

a) учет требований к системе;

b) внешнее соответствие требованиям к системе;

c) внутренняя согласованность между программными объектами;

d) тестовое покрытие требований к программному объекту;

e) соответствие используемых испытательных стандартов и методов испытаний;

f) соответствие ожидаемым результатам;

g) выполнимость квалификационного испытания программного объекта;

h) возможность эксплуатации и сопровождения.

Квалификационные испытания программных средств

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

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

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

a) тестовое покрытие требований к программному объекту;

b) соответствие ожидаемым результатам;

c) возможность сборки и тестирования системы (при их проведении);

d) возможность эксплуатации и сопровождения.

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

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

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

b) определить состояние конфигурации (базовую линию) проекта и программ данного программного объекта.

11. Стандарт жизненного цикла ИС (ИСО/МЭК 15288). Перечислить и описать процессы предприятия.

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

Процессы предприятия включают в себя:

a) процесс управления средой предприятия;

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

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

b) процесс управления инвестициями;

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

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

c) процесс управления процессами жизненного цикла системы;

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

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

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

d) процесс управления ресурсами;

Цель процесса управления ресурсами состоит в обеспечении проектов необходимыми ресурсами.

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

e) процесс управления качеством.

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

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

12. Стандарт жизненного цикла ИС (ИСО/МЭК 15288). Перечислить и описать процессы проекта.

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

Процессы проекта состоят из следующих процессов:

a) процесс планирования проекта;

Цель состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана проекта.

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

b) процесс оценки проекта;

Цель заключается в определении статуса проекта.

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

c) процесс контроля проекта;

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

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

d) процесс принятия решений;

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

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

e) процесс управления рисками;

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

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

f) процесс управления конфигурацией;

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

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

g) процесс управления информацией.

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

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

13. Стандарт жизненного цикла ИС (ИСО/МЭК 15288). Перечислить и описать технические процессы.

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

Технические процессы включают в себя:

a) процесс определения требований правообладателей;

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

Процесс позволяет определить правообладателей или классы правообладателей, которые связаны

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

b) процесс анализа требований;

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

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

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

c) процесс проектирования архитектуры;

Цель состоит в синтезе решения, которое бы удовлетворяло

системным требованиям.

Этот процесс выделяет и устанавливает области решения, представленные в виде набора различных

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

d) процесс реализации элементов системы;

Цель состоит в создании заданных (специфицированных)

элементов системы.

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

e) процесс комплексирования;

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

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

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

f) процесс верификации;

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

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

g) процесс передачи;

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

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

h) процесс валидации;

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

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

i) процесс функционирования;

Цель состоит в использовании системы для выполнения заданных функций.

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

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

j) процесс технического обслуживания;

Цель процесса обслуживания состоит в поддержании способности системы выполнять заданные

функции.

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

k) процесс изъятия и списания.

Цель процесса изъятия и списания состоит в прекращении существования системного объекта.

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

14. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процессы, обеспечивающие качество создаваемой системы или программного продукта.

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) обеспечение продукта;

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

3) обеспечение процесса;

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

4) обеспечение систем качества.

Должно быть обеспечено проведение дополнительных работ по управлению качеством в соответствии с разделами ГОСТ Р ИСО 9001, указанными в договоре.

15. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процесс управления конфигурацией. Состав и содержание работ.

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) определение конфигурации;

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

3) контроль конфигурации;

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

4) учет состояний конфигурации;

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

5) оценка конфигурации;

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

6) управление выпуском и поставка.

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

16. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процесс верификации. Состав и содержание работ.

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

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) верификация.

Договор должен быть верифицирован по следующим критериям: a) возможности поставщика удовлетворить установленным требованиям; b) непротиворечивости требований и охвату ими потребностей пользователя; c) наличия соответствующих процедур для внесения изменений в установленные требования и решения проблем; d) наличия процедур и правил их применения по взаимодействию и кооперации между участниками договора, включая права собственности, гарантии, авторские права и конфиденциальность; e) наличия соответствующих критериев и процедур, предусмотренных в соответствии с установленными требованиями.

Процесс должен быть верифицирован по следующим критериям: a) соответствие и своевременность установления проектных требований к планированию; b) пригодность, реализуемость, выполнимость в соответствии с планом и условиями договора выбранных для проекта процессов; c) применимость стандартов, процедур и условий к процессам проектирования; d) укомплектованность и обученность персонала в соответствии с условиями договора.

Требования должны быть верифицированы по следующим критериям: a) непротиворечивость, выполнимость и тестируемость требований к системе; b) распределение требований к системе между объектами технических и программных средств и ручных операций в соответствии с проектом; с) непротиворечивость, выполнимость, тестируемость и точность отражения требований к системе в требованиях к программным средствам; d) правильность, подтвержденная соответствующими методами, требований к программным средствам по безопасности, защите и критичности.

Проект должен быть верифицирован по следующим критериям: a) правильность проекта, его соответствие установленным требованиям и учет этих требований в проекте; b) реализуемость в проекте соответствующей последовательности событий, исходных данных, выходных результатов, интерфейсов, логики, распределения временных и материальных средств, а также обнаружения, локализации и восстановления ошибок; c) возможность выбора проекта, исходя из установленных требований; d) правильность, подтвержденная соответствующими методами, реализации в проекте требований безопасности, защиты и других критических требований.

Программа должна быть верифицирована по следующим критериям: a) учет в программе условий проекта и установленных требований; ее тестируемость, правильность и соответствие установленным требованиям и стандартам программирования; b) реализуемость в программе: соответствующей последовательности событий, соответствующих интерфейсов, правильных данных и логики управления; распределения временных и матери­альных ресурсов; обнаружения, локализации и восстановления ошибок, а также ее завершенность; c) возможность выбора программы, исходя из проекта или установленных требований; d) правильность, подтвержденная соответствующими методами, реализации в программе требований безопасности, защиты и других критических требований.

Сборка должна быть верифицирована по следующим критериям: a) полнота и правильность сборки программных компонентов и модулей каждого программного объекта в соответствующий программный объект; b) полнота и правильность сборки технических и программных объектов и ручных операций в систему; c) выполнение задач сборки в соответствии с планом сборки.

Документация должна быть верифицирована по следующим критериям: a) соответствие, полнота и непротиворечивость документации; b) своевременность подготовки документации; c) соблюдение установленных процедур управления конфигурацией документов.

17. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Процессы аттестации, совместной оценки и аудита.

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

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) аттестация.

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

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) анализы управления проектом;

Состояние проекта должно быть оценено на соответствие проектным планам, графикам, стандартам и руководствам. Итоговый результат анализа должен быть обсужден между двумя участвующими сторонами и должен включать: a) предложения по активизации работ в соответствии с планом, основанные на оценке состояний работ или программных продуктов; b) предложения по проведению общего контроля проекта посредством соответствующего перераспределения ресурсов; c) предложения по изменению хода проекта или определению потребности в перепланировании проекта; d) предложения по оценке и управлению критическими ситуациями, могущими угрожать успешному ходу проекта.

3) технические анализы.

Должны быть проведены технические анализы для оценки создаваемых программных продуктов или услуг с точки зрения их просмотра и представления доказательств того, что: a) они полностью реализованы на данный момент; b) они соответствуют принятым стандартам и техническим требованиям; c) изменения к ним выполнены должным образом и влияют только на те области, которые определены процессом управления конфигурацией; d) они полностью придерживаются установленных графиков работ; e) они готовы к последующим работам; f) их разработка, эксплуатация или сопровождение проводятся в соответствии с проектными планами, графиками, стандартами и руководствами.

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

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

2) аудиторская проверка.

Аудиторские проверки должны проводиться для обеспечения того, чтобы: a) запрограммированные программные продукты (такие, как программный объект) отражали проектную документацию; b) подготовка приемки и требования к тестированию, установленные в документации, были пригодны для приемки программных продуктов; c) тестовые данные соответствовали установленным техническим требованиям; d) программные продукты были успешно протестированы и соответствовали установленным к ним требованиям; e) отчеты об испытаниях (тестировании) были правильны и расхождения между фактическими и ожидаемыми результатами были устранены; f) документация пользователя соответствовала установленным стандартам; g) работы были выполнены в соответствии с утвержденными требованиями, планами и договором; h) стоимости и графики проведения работ соответствовали утвержденным планам.

18. Стандарт жизненного цикла ПО (ИСО/МЭК 12207. Группа организационных процессов. Категория управленческих процессов.

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

Список работ. Данный процесс состоит из следующих работ:

1) подготовка и определение области управления;

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

2) планирование;

Администратор должен подготовить планы для выполнения процесса. Планы, связанные с выполнением процесса, должны содержать описания соответствующих работ и задач и обозначения создаваемых программных продуктов. Планы должны охватывать (но не ограничиваться) следующие вопросы: a) установление графиков своевременного решения задач; b) оценка необходимых трудозатрат; c) определение ресурсов, необходимых для выполнения задач; d) распределение задач по исполнителям; e) определение обязанностей исполнителей; f) определение критических ситуаций, связанных с задачами или самим процессом; g) установление используемых в процессе критериев управления качеством; h) определение затрат, связанных с реализацией процесса; i) обеспечение условий и определение инфраструктуры выполнения процесса.

3) выполнение и контроль;

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

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

4) проверка и оценка;

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

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

5) завершение.

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

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

19. Стандарт жизненного цикла ПО (ИСО/МЭК 12207). Группа организационных процессов. Категория организационных процессов

Данная категория включает в себя следующие процессы:

· Процесс создания инфраструктуры

· Процесс усовершенствования

· Процесс обучения

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

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

1) подготовка процесса;

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

2) создание инфраструктуры;

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

3) сопровождение инфраструктуры.

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

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

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

1) создание процесса;

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

2) оценка процесса;

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

3) усовершенствование процесса.

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

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

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

1) подготовка процесса;

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

2) разработка учебных материалов;

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

3) реализация плана обучения.

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

20. Методология и технология разработки ПО и ИС. Какие основные проблемы они решают?

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

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

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

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

Технология определяет конкретные инструменты и подробное описание каждого этапа разработки.

Обычно выделяют следующие этапы создания ИС:

1. формирование требований к системе,

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

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

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

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

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

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

Этап тестирования обычно оказывается распределенным во времени.

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

5. ввод в действие,

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

21. Описать понятия «модель» и «моделирование».




Дата добавления: 2015-01-30; просмотров: 58 | Поможем написать вашу работу | Нарушение авторских прав




lektsii.net - Лекции.Нет - 2014-2024 год. (0.071 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав