9. Инструменты быстрой разработки приложений. Преимущество применения rad-технологий.

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

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

Технология быстрой разработки приложений (RAD) позволяет обеспечить (+):

• быстроту продвижения программного продукта на рынок;

• интерфейс, устраивающий пользователя;

• легкую адаптируемость проекта к изменяющимся требованиям;

• простоту развития функциональности системы.

Среды разработки, использующие принципы RAD: Borland Delphi, Borland C++ Builder, Microsoft Visual Studio, Macromedia Flash, Macromedia Authorware, Macromedia Director, Omnis Studio, Visual DataFlex, IntraWeb.

10. Определение архитектур «клиент-сервер» и «файл-сервер». Отличия в количестве пользователей и скорости работы системы в зависимости от типа архитектуры.

Клиент-сервер — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением.

Файл-сервер — архитектура построения локальных вычислительных сетей, основанная на использовании файлового сервера (file server) — относительно мощной ЭВМ, управляющей созданием, поддержкой и использованием общих информационных ресурсов локальной сети, включая доступ к ее базам данных (БД) и отдельным файлам, а также их защиту.

Отличие архитектуры "клиент-сервер" от архитектуры "файл-сервер"

Сетевое многопользовательское приложение строится по принципу файл-серверной архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файловый сервер принимает запросы, поступающие по сети от компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо управляет файлами MDB, содержащими данные. Единственная связь между этими независимыми действиями – файл блокировок (файл, который имеет имя, совпадающее с именем файла приложения, но с расширением. Idb), который обязательно создается для каждого файла базы данных с расширением. mdb. При этом каждая копия Jet выполняет изменения индексов, работу с системными таблицами и другие функции, входящие в компетенцию СУБД.

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

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

Архитектура "клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.

11. Методы организации проведения обследования предметной области ИС и сбора материалов.

12. Группы функций системы, выделяемые в методе MoSCoW.

На этапе выбора стратегии, и на этапе анализа, и при проектировании независимо от метода, применяемого при разработке проекта, всегда следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации — MoSCoW — предложен в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.

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

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

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

Этот метод приоритизации чаще всего используется при фиксированных дедлайнах, когда все внимание должно быть обращено на самые важные требования. И при его использовании можно ожидать более высоких ROI на проекте, так как всё сосредоточено на главном, жертвуя второстепенным.

MoSCoW — легко запоминающаяся аббревиатура:

M — MUST have this.

S — SHOULD have this if at all possible.

C — COULD have this if it does not affect anything else.

W — WON’T have this time but WOULD like in the future.

Must have — Жизненно необходимые

Требования отмеченные как MUST have должны быть включены в текущую поставку. Если хоть одно из требований не сделано, поставка считается провальной.

Should have — Обязательные

Требования SHOULD have также критичны для успеха проекта, но не необходимы в ближайших поставках. Такие требования имеют workarounds, то есть имеются обходные пути для выполнения требований, и могут быть отложены на будущие поставки продукта.

Could have — Пожалуй можно реализовать

Требования COULD have менее критичные требования, обычно относящиеся к «nice to have». Чаще всего менее трудоёмки чем первые 2 категории.

Won’t have (but Would like) — Можно и не делать, но хотелось бы

Наименее критичные или не самые подходящие в данные момент времени. И как результат данные требования не планируются в ближайшие поставки. Также эти требования часто первыми исключаются из последующих поставок, при реприоритизации. Однако это не делает их менее важными, и эти требования относят к отряду улучшений на будущее. Вот этот тонкий момент иногда сбивает пользователей с толку, так как данные требования стоят в одном ряду с остальными.