Методика Методология разработки программного обеспечения, так или иначе, строится на некотором цикле реализации требований заказчика. В рамках этого цикла вполне возможны повторы различных операций, например, разработка- тестирование или опытная эксплуатация - доработка. Основная проблема классической схемы разработки состоит в том, что фактический результат, который может оценивать реальный пользователь появляется очень поздно. Менять что-либо существенно на этой стадии или уже поздно, или очень дорого.
Использование CASE инструментов существенно ускоряет фазу разработки, но не спасает от основных разочарований, связанных с тем, что заказчик не всегда точно знает, что ему нужно.
Представим, что заказчик немного ошибается в описании своих требований, проектировщик готовит спецификации, на языке едва ли понятном заказчику, и это естественно, поскольку он пишет документацию для программистов или архитекторов проекта. Чаще всего, заказчик с трудом может оценить детали реализации, о которых говорится в спецификации. На этом этапе тоже есть некоторая вероятность, что проектировщик не полностью погрузился в проблемы заказчика и тоже не заметил ошибки заказчика.
Процесс разработки начался, и результат можно будет показать заказчику, только по завершению стадии разработки. Как правило, разработчики не любят показывать версии программ, которые плохо работают, или не позволяют делать какие-то мелочи заявленные в спецификации. это значит, что первый показ реально состоится даже не после разработки, а после достаточно длительного тестирования.
Итак, мы решаемся показать программу заказчику - и именно тут выявляется ошибка в требованиях!
В зависимости от того, какой была начальная ошибка, события могут развиваться самым непредсказуемым образом. Начиная от увеличения сроков проектов, и до отказа оплачивать всю разработку
Что же можно с этим поделать?
Есть классическое решение, которое часто практикуется на больших проектах - создание проекта прототипа. Проблема состоит в том, что мало кто способен объяснить, чем прототип отличается от окончательной версии проекта. Обычно прототип, это просто плохо оттестированный проект, в котором не реализована часть функций, и делается он не так тщательно, как того хочется. Поскольку, заказчик очень редко анализирует исходный код, то настоящий проект часто вырастает из прототипа дополнительным временем тестирования, изменением в дизайне и небольшими доработками. Плохо это или хорошо, сказать сложно, но такой подход помогает снизить риск при неправильных начальных требованиях.
О нашей методике разработки прототипов
Прежде всего, мы можем дать точное определение проекту - прототипу.
Проект - прототип, это работоспособный проект, который создается подсистемой генерации кода на базе хорошо структурированного описания проекта.
Это значит буквально следующее: фактическая работа идет не над программным кодом, а над описанием (метамоделью) проекта.
Реальное программирование не начинается, пока заказчик не согласится с прототипом.
Таким образом, цикл согласования функциональности смещается в самое начало проекта.
В момент завершения разработки прототипа, мы имеем на руках следующие результаты:
- Исходный код для каждого из документов
- Шаблон документации пользователя
Следующий этап разработки состоит из настройки той части интерфейса программ, которая может быть настроена по желанию пользователей, и доработка тех функций, которые лишь намечены в описании модели, но оставлены для ручной реализации. В принципе в этот момент, часть информационной системы, которая относиться к вводу и модификации документов готова, и скорее всего уже не будет меняться. С этого момента начинается разработка отчетов и, если это предполагается логикой информационной системы, разработки бизнес процессов.
Система управления бизнес процессами тесно интегрирована с информационной системой и представляет собой гибкое дополнение к хранилищу документов, которое может работать либо с предопределенными процессами, либо включать в себя полный комплекс средств для создания новых бизнес процессов.
Мы стараемся стандартизировать подходы к разработке документов, отчетов и бизнес процессов, с тем, чтобы свести к минимуму ручную доводку исходного кода, заменив её настройкой. Для достаточно большого количества проектов это вполне возможно, допустимо и даже оправдано.
Страницы: 
wic: Python + PyQt4 (число прочтений - 57317 )
