Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 15:54

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 9 ] 
Автор Сообщение
 Заголовок сообщения: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Пн дек 06, 2010 03:40 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Модель быстрой разработки приложений жизненного цикла программного обеспечения

Метод быстрой разработки приложений (Rapid Application Development, RAD) был предложен компанией IBM в качестве альтернативы более формальным методам, таким как каскадная модель. В среде программистов аббревиатура RAD часто ассоциируется с RAD tools, т.е. инструментальными средствами быстрой разработки приложений, среди которых можно упомянуть Delphi, C++ Builder, Visual Studio и другие среды разработки, характерной чертой которых является наличие визуального конструктора форм, что и относит их к классу RAD tools. Однако без должного уровня организационной подготовки эти среды сводятся к инструменту создания пользовательского интерфейса. Поскольку рисование интерфейса оказывается существенно проще реализации обработчиков событий (которые могут содержать довольно сложные алгоритмы), проекты, выполняемые с использованием RAD tools имеют тенденцию превращаться в заготовки навигаторов по системным меню, кнопкам быстрого вызова, спискам и т.п. Также для подобных программ характерно наличие таких недостатков, как нереализованная или непродуманная обработка ошибок при вводе данных или доступе к файлам, отсутствие инициализации и настройки интерфейсов, отсутствие контроля возможности запуска тех или иных функций. Крайне редко в программах, разработанных в Delphi и подобных средах, реализуются новые компоненты, разработка ведется в подавляющем большинстве случаев с применением тех компонентов, которые доступны по умолчанию, либо могут быть загружены в виде готовых модулей.
В то же время отмечается, что метод RAD подразумевает активное участие конечного пользователя на всех этапах разработки. При этом «решающее ролевое участие конечного пользователя заключается в перемещении процесса работы от программирования и тестирования к планированию и проектированию. Пользователям приходится справляться с большим объемом работы в начале жизненного цикла, но в награду они получают систему, построенную за более короткий промежуток времени». [1]
Модель RAD включает в себя следующие этапы разработки:
- этап планирования требований – сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;
- пользовательское описание – совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации;
- фаза конструирования («до полного завершения») – эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависят от использования генераторов кода, экранных генераторов и других типов производственных инструментов;
- перевод на новую систему эксплуатации – эта фаза включает проведение пользователями приемочных испытаний, установку системы и обучение пользователей.

Преимущества модели RAD

- время цикла разработки для всего проекта можно сократить благодаря использованию мощных инструментов;
- требуется меньшее количество специалистов, поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области;
- существует возможность произвести быстрый начальный осмотр продукта;
- благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков уменьшаются затраты;
- благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;
- модель обеспечивает эффективное использование имеющихся в наличии средств и структур;
- привлечение заказчика на постоянной основе сводит до минимума риск того, что он не будет удовлетворен разработанным продуктом, кроме того, это гарантирует, что система будет соответствовать коммерческим потребностям, а сам программный продукт будет надежен в эксплуатации;
- в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);
- интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем;
- основное внимание переносится с документации на код, причем при этом справедлив принцип «получаете то, что видите» (WYSIWYG);
- в модели используются следующие принципы и инструментальные средства моделирования: деловое моделирование (методы передачи информации, место генерирования информационных потоков, кем и куда направляется, каким образом обрабатывается); моделирование данных (происходит идентификация объектов данных и атрибутов, а также взаимосвязей); моделирование процесса (выполняется преобразование объектов данных); генерирование приложения (методы четвертого поколения);
- в модели используются компоненты уже существующих программ.

Недостатки модели RAD.

Если эта модель применяется для проекта, для которого она не подходит в полной мере, могут сказываться недостатки, рассмотренные ниже. При этом оценка актуальности недостатков дается для ситуации, сложившейся в российском сегменте форт-программистов. Рассматривается порядок работы, когда Форт используется в качестве RAD tool, и разработчик программы использует модули на Форте (в их текущем состоянии комплектности) для быстрой разработки, аналогично Delphi/** Builder/ Visual Studio.

Если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте.
Недостаток проявляется двумя способами, отличающимися целевым назначением разрабатываемой программы. Если с помощью модели RAD на Форте разрабатывается продукт для внутреннего применения (например, инструментальное ПО), то пользователем является разработчик или коллектив разработчиков. В этом случае участие в процессе разработки является очевидным, и недостаток не проявляется. В то же время, при использовании Форта для выпуска программ, предназначенных для продажи, пользователи в конечном итоге не вовлекаются в процесс планирования, а вместо обсуждения требований к программе и интерфейсу с пользователем обсуждается вопрос «можно ли использовать Форт».

При использовании этой модели необходимо достаточное количество высококвалифицированных и хорошо обученных разработчиков, умеющих воспользоваться выбранными инструментальными средствами разработки для ее ускорения.
Сам факт использования форт-систем, существенно уступающих Delphi-подобным средам в функциональности визуальных конструкторов и генераторов кода, свидетельствует о недостаточной квалификации разработчиков, выбирающих некорректное инструментальное средство. Ускорение разработки путем ускорения конструирования интерфейсов не выделяется форт-программистами как ключевая особенность модели разработки.

Возникает потребность в системе, которая может быть смоделирована корректным образом.

При использовании в качестве RAD tool Форт, видимо, не используется в качестве средства моделирования/прототипирования, хотя сравнительный анализ Форта и Delphi-подобных средств позволяет предположить, что Форт мог бы выступать в качестве средства моделирования процессов и алгоритмов для их последующей реализации с помощью RAD tools.

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

В настоящий момент наблюдается явный недостаток повторно используемых компонентов в Форте.

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

Фактор не представляется существенным ввиду простоты адаптации интерфейсов в Форте.

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

Требование потенциально несущественное, однако фокусировка на особенностях Форта переводит его в разряд критических. В действительности, в формулировке требования не упоминается, что разработчики обязаны использовать RAD tool. Четко указано, что и разработчики и заказчики должны быть готовы к быстрому выполнению действий, что вполне реализуемо и на Форте, причем возможность проблемного ориентирования языка является здесь существенным плюсом. При наличии жестких временных ограничений заказчик, как правило, не стремится наложить на разработчика дополнительные ограничения по выбираемым инструментам, стилю кодирования и т.п., поскольку одновременное выполнение нескольких условий существенно удорожает разработку. Поэтому настоятельное информирование заказчика о том, что разработка будет выполняться на Форте воспринимается им как попытка разработчика снять с себя ответственность за выбор инструмента разработки, зафиксировав в техническом задании язык программирования, нестандартный для большинства предметных областей. В конечном итоге прямые переговоры о выполнении проекта в сжатые сроки и на Форте вряд ли приведут к успешным результатам.

При использовании модели «вслепую» на затраты и дату завершения работы над проектом ограничения не накладываются.

Использование RAD tools «вслепую» и является основной организационной проблемой. Как правило, подавляющее большинство учебной и технической литературы ограничивается разъяснением особенностей программирования с помощью таких средств и описанием использования отдельных компонентов программ. При этом не разъясняется тот факт, что данные инструменты предназначены для ускорения разработки, а не для ее сквозного выполнения. Однако привлечение сторонних инструментов для моделирования, планирования и проектирования, как правило, не описывается.

Команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут «затянуть» разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом.

Существует риск, что работа над проектом никогда не будет завершена – в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла.

Существует проблема организации цикла взаимодействия как такового. Для применения модели RAD необходимо, чтобы менеджер проекта установил взаимодействие с заказчиком и определил его требования к разрабатываемой программе. После определения и согласования требований разработчик реализует их с использованием средств ускоренной разработки проекта. Однако установлению взаимодействия с заказчиком при разработке «вслепую» уделяется чрезмерно мало внимания.

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

Процесс разработки на Форте может быть ускорен за счет реализации проблемно-ориентированного расширения. Однако для этого требуется налаженная обратная связь с пользователем, свободная от обсуждения вопроса «можно ли пользоваться Фортом».

Область применения модели RAD
- в системах, которые поддаются моделированию (основанных на использовании компонентных объектов), а также в масштабируемых системах;
- в системах, требования для которых в достаточной мере хорошо известны;
- в случаях, когда конечный пользователь может принимать участие в процессе разработки на протяжении всего жизненного цикла;
- когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств;
- при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки, как правило, не более, чем за 60 дней;
- в системах, которые можно поместить во временной блок с целью обеспечения функциональных возможностей на последовательной основе;
- когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;
- в системах, которые предназначены для концептуальной проверки, являются некритическими, или имеют небольшой размер;
- когда затраты и соблюдение графика не являются самым важным вопросом (например, при разработке внутренних инструментальных средств);
- в системах, в которых не требуются достижение высокой производительности, особенно достигаемой посредством использования настройки интерфейсов;
- при невысокой степени технических рисков;
- в информационных системах;
- когда команде, работающей над проектом, знакома предметная область, и она обладает достаточными навыками в использовании средств разработки и имеет высокую степень мотивации при выполнении данного проекта.

Рассмотрим теперь ситуацию, когда проект на Форте выполняется в соответствии с моделью RAD индивидуальным программистом или небольшим коллективом, но работа ведется в основном путем кодирования и тестирования. Весьма вероятно, при этом могут появиться следующие условия, препятствующие применению модели RAD:
- не устанавливается взаимодействие с заказчиком; при этом либо организации или круга пользователей нет вообще, либо с ними обсуждаются не требования к программе, а возможность использования в этой программе Форта. В итоге не образуется списка требований, демонстрация выполнения которых могла бы обеспечить продвижение до очередной контрольной точки, и основы для применения RAD не возникает.
- не присутствуют повторно используемые компоненты; существенным недостатком является ассоциирование повторно используемых компонентов с «повторно используемыми компонентами для организации графического интерфейса».
- подразумевается, что разработчики хорошо освоили используемые инструменты и хорошо осведомлены в предметной области; независимо от используемого языка программирования, попытка использовать RAD для исследовательского проекта или освоения языка не соответствует рекомендациям для этой модели.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Пн дек 06, 2010 16:04 
Не в сети
Аватара пользователя

Зарегистрирован: Вт ноя 06, 2007 21:23
Сообщения: 227
Откуда: Екатеринбург
Благодарил (а): 4 раз.
Поблагодарили: 7 раз.
А есть ли что-то подобное этому http://automation-system.ru/spravochnik-inzhenera/category/glava6.html ?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Пн дек 06, 2010 17:56 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Хищник писал(а):
Если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте.


А без RAD отсутствие пользователей в процессе разработки сказывается положительно?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Вт дек 07, 2010 00:55 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Alexander писал(а):
А есть ли что-то подобное этому http://automation-system.ru/spravochnik ... lava6.html ?

Есть ГОСТ на программную документацию. Например, составляются описание программы, описание применения, руководство оператора, руководство программиста, руководство системного программиста, формуляр (список документов является уточняемым). Однако документирование является только частью жизненного цикла программного обеспечения. Можно ведь сориентироваться на рынок, где не потребуют документацию по ГОСТ - например, игрушку написать можно и без этого.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Вт дек 07, 2010 00:58 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Mihail писал(а):
А без RAD отсутствие пользователей в процессе разработки сказывается положительно?

Разумеется, положительно. Или ты хотел съязвить? :) Так у тебя оно не получилось, потому что тебя, видимо, очень сильно обременили знания :))
Таки да, существуют модели жизненного цикла, которые не предполагают включение пользователей в процесс разработки. Например, каскадная или V-образная.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Ср дек 08, 2010 12:59 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
Хищник писал(а):
потому что тебя, видимо, очень сильно обременили знания


Скорее наоборот. Честно говоря, ничего не понял. Думал ты разъяснишь.
Хотя сомневаюсь, надо ли мне оно. Писал я на Delphi, взаимодействовал только с начальством.
И чем-бы мне помогли пользователи?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Ср дек 08, 2010 14:45 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Mihail писал(а):
Скорее наоборот. Честно говоря, ничего не понял. Думал ты разъяснишь.

:? Вот объясни, пожалуйста, какое именно место в опубликованном тексте тебе непонятно?
Mihail писал(а):
Хотя сомневаюсь, надо ли мне оно.

Вот именно такая позиция и мешает тебе смотреть на проблемы со стороны.
Mihail писал(а):
Писал я на Delphi, взаимодействовал только с начальством.
И чем-бы мне помогли пользователи?

Гм-гм-гм. Вот чем бы помогли - как раз выше и написано. Тем бы и помогли, что постоянный контакт с пользователями сделал бы возможным рисование форм прямо при них. А с учетом замечания "когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств" - так и вообще подразумевается, что пользователи могут сами и нарисовать форму, с которой они бы согласились работать впоследствии. А это сильно упрощает процесс адаптации программы под их требования, и позволяет сделать не сверхкомпактную, производительную или дешевую программу, а сделать ее очень быстро и под конкретные требования, что и является сущностью метода RAD. Так понятнее?


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Ср дек 08, 2010 16:37 
Не в сети
Аватара пользователя

Зарегистрирован: Пт дек 26, 2008 21:16
Сообщения: 412
Откуда: Великий Новгород
Благодарил (а): 9 раз.
Поблагодарили: 4 раз.
Хищник писал(а):
очень быстро и под конкретные требования, что и является сущностью метода RAD. Так понятнее?

И так появился VBA теперь пользователь сам себе пишет что хочет :mrgreen:
Кстати как то перекликается с идеями Муровского телескопа.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Статья: Модель быстрой разработки приложений
СообщениеДобавлено: Ср дек 08, 2010 17:15 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
_Harry писал(а):
И так появился VBA теперь пользователь сам себе пишет что хочет

Именно так. VBA тоже отнесен к средствам быстрой разработки приложений, просто я весь список приводить не стал.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 9 ] 

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB