Методические указания по выполнению практических работ по профессиональному модулю
IEEE 1219-1992 Стадия сопровождения 1: определение задачи
жүктеу/скачать 5.65 Mb.
|
- Бұл бет үшін навигация:
- IEEE 1219-1992 Стадия сопровождения 2: анализ задачи
| IEEE 1219-1992 Стадия сопровождения 1: определение задачи
Стадия анализа задачи в процессе обработки запросов на сопровождение описана в табл. 3. Таблица 3. Анализ запроса на сопровождение IEEE 1219-1992 Стадия сопровождения 2: анализ задачи Стадия проектирования запроса на сопровождение описана в табл. 4. Например, разработка запроса 162 выполняется с применением образца проектирования Abstract Factory и состоит в модификации исходного пакета EncounnterEnvi ronment (Среда Встречи). Таблица 4. Проектирование запроса на сопровождение Для перехода от старого проекта к новому нужен отдельный план. Этот план приведен на рис. 6. Он начинается с существующего проекта и состоит в добавлении и тестировании компонентов, не нарушающих имеющуюся реализацию. Перед последним шагом все готово к реализации образца проектирования Abstract Factory, причем все компоненты уже протестированы. На последнем шаге происходит окончательная реализация и тестирование. Стадия реализации запросов на сопровождение описывается в табл. 5. Таблица 5. Реализация запроса на сопровождение Рисунок 6. План перехода на многоуровневую версию Встречи Обработка запросов на сопровождение может потребовать разработки большого объема кода, в результате чего могут возникнуть новые дефекты. Процент ошибок — это количество дефектов, созданных в рамках трудозатрат по данной теме, в расчете на единицу измерения трудозатрат (например, человеко-месяц). Необходимо точно определить методику измерения количества новых дефектов. Можно, например, подсчитать «количество дефектов, найденных в течение трех месяцев с даты поставки». Предположим, что на обработку запроса 162 ушло 20 человеко-дней, за которые было создано 10 новых дефектов. Процент ошибок в этом случае будет составлять 10/20 = 0,5 дефекта/человеко-день. Оставшиеся стадии процесса сопровождения — системное тестирование, приемка и обновление проектной документации — практически полностью аналогичны соответствующим фазам обычной разработки. План сопровождения (maintenance plan) регламентирует поток запросов на сопровождение внутри организации. Типичный план сопровождения приведен на рис. 7. Жирной линией на нем отмечена номинальная последовательность обработки запросов. В этом плане отдел сопровождения принимает от пользователей (заказчиков) жалобы и предложения. Они оформляются как запросы на сопровождение. Специальное подразделение, которое может быть как одним человеком, так и целым комитетом, принимает решение о реализации запросов и присваивает им приоритеты. Такой комитет иногда называется Советом по контролю изменений (ССВ). После этого запросы обслуживаются техническим персоналом службы сопровождения. Тонкими линиями показаны другие последовательности появления и исчезновения запросов. Оптимальная организация работ по сопровождению зависит от масштабов приложения: процесс реализации запросов может быть достаточно растянутым. С реализацией запросов связаны две проблемы. Первая — доставка подготовленного кода пользователям. Вторая — борьба с дефектами в целом. Дефект может повлиять на длительность тестирования, подготовка которого может недопустимо затянуться. Исключительным примером является военное приложение, в работах над которым довелось принять участие автору. Между определением задачи и полной реализацией запроса в этом проекте проходило до 9 месяцев! В таких ситуациях прибегают к выпуску исправлений или заплат (patch). Исправления — это изменения кода, которые либо устраняют дефект, либо позволяют обойти его. Исправления считаются временными. Часто они выпускаются в виде набора файлов, заменяющих уже написанный объектный код. Преимущества и недостатки исправлений рассматриваются в табл. 6. Рисунок 7. Типичная последовательность работ по сопровождению жүктеу/скачать 5.65 Mb. Достарыңызбен бөлісу:
|