|
Краткий обзор процесса разработки программного обеспечения в компании "Активные Технологии". |
|
|
1. План стадий и проектный график. |
|
|
Стандартный процесс разработки разделен на четыре последовательных стадии: Начало, Уточнение, Разработка и Развитие: |
|
|
1.1. Начало. |
|
|
Целью данной стадии является определение границ системы и сбор высокоуровневых требований к ней. Для достижения поставленной цели анализируются запросы от клиента, создаётся концепция и спецификация требований к системе. При необходимости проводится бизнес-анализ проекта. Также создается начальная версия предложения по архитектуре системы, включая предложение об использовании технологий и аппаратных средств; предварительная версия плана проекта, включающая оценку затрат. |
|
|
1.2. Уточнение |
|
|
Основной целью данной стадии является разработка архитектурного решения. К окончанию этой стадии создаётся каркас системы, на котором впоследствии будет базироваться основная часть системы. При необходимости параллельно с разработкой каркаса могут создаваться прототипы различных модулей системы (пользовательский интерфейс или функциональная часть) для одобрения их клиентом. |
|
|
1.3. Разработка |
|
|
Используя выбранную архитектуру и технологии, проектная команда итерационно разрабатывает систему. Этот подход к реализации позволяет легко вносить изменения (например по запросу от клиента), обе стороны могут с большей точностью создавать планы по проекту. Таким образом клиент может более эффективно контролировать процесс разработки системы. |
|
|
1.4. Развитие |
|
|
На этой стадии происходит обучение людей, которые будут работать с этой системой. Во время обучения рассказываются не только способы администрирования и поддержания системы в рабочем состоянии, но и создаётся понимание о применяемых технологиях и основных путях развития системы. В дополнение к этому гарантируются быстрые ответы на возникающие вопросы. |
|
|
2. План контроля графика и бюджета |
|
|
Для контроля хода работ по проекту определяется набор пунктов. Менеджер проекта отвечает за достижение за своевременное достижение этих пунктов в пределах указанного бюджета. Он регулярно проверяет состояние проектных работ. Клиент своевременно информируется о любых расхождениях реальности и плана. |
|
|
3. План управления рисками |
|
|
Есть множество рисков, которые могут влиять на выполнение проекта. Ключевая задача управления рисками состоит в прогнозировании возможных рисков и определения стратегии уменьшения их влияния на проект. |
|
|
4. Гарантия качества создания продукта |
|
|
Известно, что затраты для идентификации проблемы экспоненциально растут по времени. Например, чтобы установить несоответствие в спецификации требований во время стадии «Начало» - требуется приблизительно в десять раз меньше ресурсов чем, если бороться с последствиями этой проблемы в процессе разработки. Для ранней идентификации проблем, мы используем периодические проверки различных документов и сквозной контроль на протяжении всего жизненного цикла проекта. |
|
|
5. Тестирование |
|
|
5.1. Методология тестирования |
|
|
Тестирование проводится на различных уровнях: внутренняя логика, интерфейс, функции и т.д. на предмет соответствия их спецификации; комбинированное тестирование; системное тестирование (функциональность системы в целом на различных программно – аппаратных платформах, при этом дополнительно могут проверяется (в зависимости от специфики разрабатываемого продукта): производительность (эффективность работы системы при различных рабочих нагрузках); отказоустойчивость, включая работу при загрузках, превышающих нормальные значения и других обстоятельствах (потеря связи, некорректные данные, отказ аппаратуры и т.д.); целостность данных); проверка адекватности описания системы в документации пользователя. По завершении тестирования, формулируется заключение о качестве программы (основываясь на списке выявленных дефектов и предварительно разработанных критериях оценки). |
|
|
5.2. Приемочное тестирование |
|
|
Для оценки удобства использования и эффективности работы системы проводится приёмочное тестирование. Приемочное тестирование базируется на наборах приемочных тестов, которые могут быть самостоятельно выполнены заказчиком. На основании результатов выполнения этих тестов Заказчик делает выводы о готовности программы. Решение относительно принятия программы или ее доработке программы принимается на основании от записанных результатов приемочного тестирования. |
|
