Разработка ПО основывается на следующих основных принципах:
1. Объектно-ориентированный подход к проектированию
и разработке ПО
Успех ОО методологии определяется ее преимуществами по сравнению
с традиционной структурной, среди которых особо выделяются следующие.
- Повторное использование (reuse). ОО методология позволяет накапливать опыт
проектных решений в виде библиотек классов и использовать его на основе
механизма наследования. При наличии развитых библиотек классов проектирование и программирование
будет в значительной степени сводиться к сборке системы из готовых
фрагментов;
- Упрощение внесения изменений. В тех случаях, когда изменение носит характер
уточнения, детализации, вводятся новые классы, наследующие поведение ранее созданных.
Наследование позволяет не только не пересматривать ранее созданные объекты
и классы, но даже обойтись без их повторной компиляции. В более
сложных случаях, когда меняются методы, определяющие интерфейс классов, изменения
в проекте будут более значительными, но и тогда они будут локализованы,
затрагивая лишь классы, использующие эти методы;
- Распараллеливание работ. Программирование и тестирование отдельных компонент
системы возможно до завершения проектирования ПО, что экономит время разработки.
2. Разработка на основе моделей
В основе проектирования ПО лежит построение модели, которая используется на всех
этапах жизненного цикла. Модели позволяют свести высокую сложность программной системы
до уровня, понимаемого человеком. Достигается это за счет иерархического
принципа их построения и применения наглядной графической нотации (технология
предусматривает использование языка UML). Иерархия уровней описания системы дает
возможность резко сократить количество элементов, которые должен анализировать человек.
При этом на верхних уровнях иерархии опускаются детали реализации, которые
проявляются на более низких уровнях.
Построенные модели уточняются и развиваются в течение всего жизненного
цикла. Причин тому может быть много — изменения требований к системе,
устранение программных ошибок, выявленных при тестировании, развитие системы и т. д. При
этом обязательно соблюдение соответствия между моделями и программными кодами.
3. Итеративная инкрементная разработка
Итеративный инкрементный подход основывается на базовом формальном описании
системы, дающем возможность достаточно быстро создать первую исполняемую функциональную
модель (прототип ПО). Прототип проверяется на соответствие требованиям к ПО, а затем
расширяется далее, последовательно преобразуясь в новые модели, в которых
отражается увеличение требований и уточнение деталей их реализации. Цель
каждой итерации — получение работающей версии (релиза) ПО, включающей
функциональность всех предыдущих и текущей итерации. Результат финальной итерации
содержит всю требуемую функциональность продукта. Таким образом, с завершением
каждой итерации, продукт развивается инкрементно.
Такая организация процесса имеет целый ряд преимуществ.
- Изменения и уточнения требований выявляются уже в ранний период разработки,
когда объем программного кода сравнительно небольшой, поэтому трудоемкость внесения
изменений существенно ниже;
- Уже на ранней стадии процесса разработки имеется возможность привлечения специалистов
заказчика для оценки промежуточных версий (прототипов) ПС. Как результат —
значительно более высокая вероятность того, что конечный продукт будет делать именно
то, чего ждет от него заказчик, то есть, гарантируется высокое качество
ПО;
- Снижаются архитектурные и интеграционные риски. При итеративном подходе создается
устойчивая архитектура, которая прорабатывается на стадиях исследования, а затем
проверяется и уточняется в нескольких начальных итерациях. Каждая итерация
предполагает интеграцию новых элементов в систему, то есть, количество
интегрируемых элементов в каждой итерации невелико и легче прослеживается,
чем при глобальной интеграции всех разработанных элементов ПО;
- Итеративный подход способствует более полному повторному использованию программных
элементов. Анализ результатов каждой итерации позволяет архитекторам ПО выделить
фрагменты, потенциально подлежащие повторному использованию, а в следующей
итерации оформить их как повторно используемые коды. Это свойство очень хорошо
сочетается с идеями ОО и компонентно-базированного проектирования.
Число прототипов определяется на основе учета разных параметров —
размера проекта, анализа рисков, пожеланий Заказчика и т. д. Традиционно
разрабатываются 3 прототипа.
Первый прототип содержит реализацию пользовательского интерфейса с нулевой
функциональностью. Такой прототип может быть создан за сравнительно короткое
время, после чего он предъявляется Заказчику. Это дает возможность собрать
замечания Заказчика и после их устранения утвердить у него экранные
и отчетные формы. У Заказчика появляется уверенность в том, что система
будет делать именно то, что ему требуется, и ему будет удобно с ней
работать.
Второй прототип содержит реализацию основной функциональности ПО. Анализируя
прототип, Заказчик видит, как реализованы требования к ПО, одновременно
контролируя реализацию уже известной ему функциональности и обучаясь работе
с новыми функциями системы. На этой стадии Заказчик составляет список
замечаний по реализации функциональности, которые учитываются в следующем
прототипе. При этом, возможно, могут измениться требования к ПО, что является
предметом дополнительного соглашения Разработчика и Заказчика.
Третий прототип содержит полностью реализованную функциональность в соответствии
с требованиями к ПО и дополнительными соглашениями об их изменении.
Он анализируется Заказчиком, а сделанные им замечания учитываются
в версии ПО, которая является конечным результатом разработки.
4. Групповая разработка
Технология разработки предусматривает выполнение работ небольшими группами (4-6 человек).
Это позволяет минимизировать накладные расходы на руководство и передачу
информации, дает возможность оптимально разделить обязанности между участниками
команды, позволяет эффективно управлять проектом.
Если проект разработки ПО сложный, то для него может быть выделено несколько
групп. При этом каждая подсистема разрабатывается отдельной группой. Ключ к успеху —
правильное разбиение системы на подсистемы. Команды должны использовать одинаковые
ресурсы и стандарты. Обязательно финальное тестирование полной системы.
Технология предусматривает наличие отдельной независимой группы тестирования, в обязанность
которой входит тестирование разрабатываемого ПО. Группа должна быть оснащена
инструментальными средствами, автоматизирующими процесс тестирования.
Главный принцип организации групповой работы заключается в том, что все действия
участников проекта документируются. В этом случае руководители разных уровней
могут оценить состояние работ по проекту в целом, а также работу
отдельных исполнителей и принять необходимые решения. Для этой цели технология
предусматривает применение методов и средств управления конфигурацией.
5. Привлечение заинтересованных к работе над проектом
Привлечение заказчика и конечного пользователя к работе над проектом в качестве
экспертов должно осуществляться на всех этапах жизненного цикла Это позволит
формулировать требования к системе, одинаково понимаемые как Разработчиком,
так и Заказчиком, а также оценивать выходные результаты прототипирования.
Эффективная обратная связь с командой разработчиков является гарантией того,
что созданная система будет делать то, что требуется заказчику.
6. Уточнение и развитие модели путем реинжиниринга
Технология разработки должна обеспечивать соответствие модели и программного
кода. Для достижения этой цели по завершении каждого прототипа выполняется
автоматический реинжиниринг программного кода и коррекция модели ПО. В модель
могут добавляться новые классы и отношения, уточняется состав атрибутов и методов,
При этом могут быть внесены необходимые изменения и в те диаграммы
модели, которые описывают функционирование ПО.
7. Управление конфигурацией (УК) на всех этапах
жизненного цикла
УК решает две основные задачи:
- организацию архивов для версионного хранения всех документов, вырабатываемых на всех
этапах жизненного цикла;
- управление изменениями на основе наблюдаемости и управляемости всех процессов
жизненного цикла;
Для каждого проекта создается репозиторий, включающий архив проекта и базу
данных управления изменениями. В архиве проекта хранится вся информация, относящаяся
к разработке (сопровождению) конкретной версии. В базе данных управления
изменениями хранятся все задания на выполнение работ по проекту. Она обеспечивает
наблюдаемость хода выполнения работ, а также управление ими на основе
распределения и перераспределения ресурсов.
Цели создания и внедрения КУ — повышение производительности процессов
жизненного цикла ПО, снижение трудозатрат, обеспечение качества конечного продукта
и предоставляемых услуг. Достижение этих целей осуществляется за счет:
- предоставления информации, необходимой для принятия обоснованных решений;
- обеспечения управления ресурсами на всех этапах;
- обеспечения взаимодействия Заказчика и Разработчика;
- обеспечения информационной связи между основными процессами жизненного цикла;
- сохранения информации всех видов, вырабатываемой в течение всего жизненного
цикла ПО;
- исключения потери информации;
- обеспечения процессов восстановления при возникновении ошибок;
- разграничение прав доступа к документам для различных пользователей;
- обеспечения наблюдаемости хода выполнения работ;
- получения статистической информации по завершении отдельных этапов жизненного
цикла.