Требования к программному обеспечению
жүктеу/скачать 114,5 Kb.
|
- Бұл бет үшін навигация:
- Классификация изменяемых требований
Управление требованиямиТребования к большим системам ПО неизбежно будут изменяться в процессе разработки. Причины этого многочисленны и разнообразны. Одной из причин является то, что во время процесса создания ПО понимание разработчиками поставленных перед ними задач будет неизбежно меняться, что вызывает необходимость возвращения к требованиям. Кроме того, для больших программных систем, которые приходят на смену действующим, должна быть обеспечена преемственность. Хотя проблемы в работе со старой системой известны, трудно предсказать, какой эффект «улучшения» система даст для организации. Управление требованиями - это процесс управления изменениями системных требований. Процесс управления требованиями выполняется совместно с другими процессами разработки требований. Начало этого процесса планируется на то же время, когда начинается процесс первоначального формирования требований, непосредственно процесс управления требованиями должен начаться сразу после того, как черновая версия спецификации требований будет готова. С точки зрения разработки требования можно разделить на два класса. Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются непосредственно предметной области, где будет эксплуатироваться система. Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода её в эксплуатацию. Классификация изменяемых требований
Процесс управления изменениями состоит из трёх основных этапов. Анализ проблем изменения спецификации. Процесс начинается с определения проблем в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определённые предложения относительно изменений в требованиях. Анализ осуществимости и расчёт их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему. Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде. Если требуется срочно внести изменения в требования, всегда существует соблазн сделать сначала изменения в системе, а затем задним числом изменить спецификацию. Это почти всегда приводит к тому, что готовая система не будет согласована с требованиями. жүктеу/скачать 114,5 Kb. Достарыңызбен бөлісу:
|