Модульное программирование основано на понятии модуля — программы или функционально завершенного фрагмента программы.
Программный модуль является самостоятельным программным продуктом. Каждый программный модуль разрабатывается, компилируется и отлаживается отдельно от других модулей программы. Модульная структура программы представляет собой древовидную структуру, в узлах которой размещаются программные модули, а направленные дуги показывают статическую подчиненность модулей. Каждый модуль может обращаться к подчиненным ему модулям.
Модуль характеризуют:
• один вход и один выход.
• функциональная завершенность.
• логическая независимость.
• слабые информационные связи с другими программными модулями.
• размер и сложность программного элемента в разумных рамках.
Анализ таблицы показывает, что при проектировании программных модулей лучше всего использовать функциональную, последовательную и информационную связности.
Так как подпрограмма - это отдельная функционально независимая часть программы, то можно утверждать, что модуль это подпрограмма. Подпрограммы группируются в отдельных файлах, имеющих специальную структуру – модулях.
25. Дать понятие методологии RAD.
Перечислить основные принципы подхода RAD.
Заказчик обратился к разработчику с задачей разработать программный продукт, который в дальнейшем требовал построения сложной расчетной программы, содержащей большой объем (сотни тысяч строк). Можно ли в данном случае применить методологию RAD. Ответ обосновать.
Можно ли применять методологию RAD крупной компанией? Почему?
Методология RAD - способ быстрой разработки приложений. Подход RAD предусматривает наличие трех составляющих:
• небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;
• короткого, но тщательно проработанного производственного графика (до 3 месяцев);
• повторяющегося цикла, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.
Подход RAD хорош для относительно небольших проектов, разрабатываемых для конкретного заказчика.
26. Дать понятие экстремального программирования.
Описать основные методики экстремального программирования.
Разработчики программных продуктов работают в разных ситуациях. Они могут целый день не отрываться от задачи, а могут полдня потратить на консультации других разработчиков, исследования и т.п. Это непредсказуемо. Возможно лишь статистическое накопление информации. Так вот, как правило, на разработку из-за таких отвлекающих факторов тратится больше времени, нежели изначальная оценка. Какой подход будет принят в данной ситуации при применении экстремального программирования.
Можно ли применять метод экстремального программирования одновременно с другими методами? Почему?
Экстремальное программирование – это упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований.
• Игра в планирование – быстро определяет перечень задач, которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.
• Небольшие версии – самая первая упрощенная версия си-стемы быстро вводится в эксплуатацию, после этого через относительно короткие промежутки времени происходит выпуск версии за версией.
• Простой дизайн – в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают.
• Программирование парами – весь разрабатываемый код пишется двумя программистами на одном компьютере.
• Коллективное владение – в любой момент времени любой член команды может изменить любой код в любом месте системы.
• 40-часовая неделя – программисты работают не более 40 ча-сов в неделю. Это правило. Никогда нельзя работать сверхурочно две недели подряд.
• Заказчик на месте разработки – в состав команды входит реальный живой пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе.
После того, как команда уже втянулась в проект, скорость разработки начинает повышаться.
27. Дать понятие тестирования ПО.
Описать типы ошибок.
При проектировании программного продукта для выполнения некой задачи специалист по тестированию формирует тесты, используя как структурный, так и функциональный подходы, обеспечивая всестороннее тестирование. Какую задачу ставит специалист?
Можно ли провести тестирование ПО и выявить 100% ошибки. Если возможно, то в каких случаях?
Тестирование — процесс выполнения программы с целью обнаружения ошибок.
Ошибка – состояние программы, при котором выдается неправильные результаты, причиной которых являются изъяны в операторах программы или в технологическом процессе ее разработки, что приводит к неправильной интерпретации исходной информации, а следовательно и к неверному решению.
Дефект в программе является следствием ошибок разработчика на любом из этапов разработки и может содержаться в исходных или проектных спецификациях, текстах кодов программ, эксплуатационной документация и т.п. Дефект обнаруживается в процессе выполнения программы.
Отказ – это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями и рассматривается как событие, способствующее переходу программы в неработоспособное состояние из–за ошибок, скрытых в ней дефектов или сбоев в среде функционирования.