6.4.4 Фаза «детальное проектирование и разработка код-программ»

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

2. Детальное проектирование и производство ПО должны основываться на следующих принципах:

   1. Декомпозиция сверху-вниз;

   2. Параллельность разработки ПО и документации.

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

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

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

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

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

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

9. После производства в обзоре результатов детального проектирования должен быть проведен анализ результатов верификации и принято решение о передаче ПО заказчику.

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

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

6.4.5 Фаза «тестирование и передача по в эксплуатацию»

1. В тестах приемки должны участвовать представители заказчика, операторы и пользователи.

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

3. Процессы тестирования должны быть выполнены в соответствии с ранее определенными планами.

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

5. Тесты приемки, необходимые для предварительной приемки, должны быть отражены в соответствующих документах.

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

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

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

6.4.6. Фаза «эксплуатации и сопровождения»

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

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

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

4. Должны быть определены процедуры для внесения изменений в ПО.

5. Должно быть отслежено соответствие между код-программой и документацией ПО.

6. Ресурсы на сопровождение продукта следует выделять до тех пор, пока продукт не будет изъят из обращения.

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

ВЫВОДЫ

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

2. Необходимым условием является использование CASE-средств: Rational Rose, ERWin, BPWin, Microsoft Project.

Риски

Риск – это возможность опасности, неудачи.

Риск – это действие наудачу в надежде на счастливый исход. Т.е. понятие «риск» включает в себя два по сути противоположных толкования: одно со знаком минус, второе со знаком плюс.

Риск проекта – это всякое событие или условие, которое может оказать как негативное, так и позитивное влияние на итоги проекта.

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

Выполняют определение и анализ рисков (финансовые, технические, организационные, конкуренции, спроса, критические условия и поведение ПО в такой ситуации).

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

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

понедельник, 17 сентября 2012 г.

Отладка и тестирование

Контроль – попытка найти ошибку в моделируемой среде.

Испытание – попытка найти ошибку в реальной среде.

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

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

Отладка – установка природы ошибки и ее устранения.

Тестирование – метод обнаружения ошибки при отладке модуля.

Дейкстра.

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

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

Отладка и тестирование это два четко различаемых и не похожих друг на друга этапа. Выполнение которых требует определенных затрат.

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

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