Перечислить основные принципы подхода RAD.

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

Можно ли применять методологию RAD крупной компанией? Почему?

 

Методология RAD - способ быстрой разработки приложений. Подход RAD предусматривает наличие трех составляющих:

• небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

• короткого, но тщательно проработанного производственного графика (до 3 месяцев);

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

 

Подход RAD хорош для относительно небольших проектов, разрабатываемых для конкретного заказчика.

 

26. Дать понятие экстремального программирования.

Описать основные методики экстремального программирования.

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

Можно ли применять метод экстремального программирования одновременно с другими методами? Почему?

 

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

• Игра в планирование  – быстро определяет перечень задач, которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.

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

• Простой дизайн – в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают.

• Программирование парами – весь разрабатываемый код пишется двумя программистами на одном компьютере.

 • Коллективное владение – в любой момент времени любой член команды может изменить любой код в любом месте системы.

• 40-часовая неделя – программисты работают не более 40 ча-сов в неделю. Это правило. Никогда нельзя работать сверхурочно две недели подряд.

 • Заказчик на месте разработки – в состав команды входит реальный живой пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе.

 

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

27. Дать понятие тестирования ПО.

Описать типы ошибок.

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

Можно ли провести тестирование ПО и выявить 100% ошибки. Если возможно, то в каких случаях?

Тестирование — процесс выполнения программы с целью обнаружения ошибок.

Ошибка – состояние программы, при котором выдается неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, а следовательно и к неверному решению.

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

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