Пример gantt-диаграммы

7) Каково назначение этапа управления требованиями к пп в жизненном цикле?

Одно из первых действий при проектировании ПП — сбор и упорядочение требований к нему. Изначально собираемые требо­вания представляют собой первичные требования заказчика (ПТЗ), протоколы совещаний и интервью с заказчиками и пользователя­ми, копии и оригиналы различных документов, отчеты о суще­ствующих аналогичных ПП и массу других материалов. После сбо­ра их начинают упорядочивать и очищать от противоречий. Затем на их основе вырабатывают требования к компонентам ПП — ба­зам данных, программным и техническим средствам. При этом приходится иметь дело с большим количеством неструктуриро­ванных, часто противоречивых требований и пожеланий, разбро­санных по всевозможным соглашениям о намерениях, приложе­ниям к договорам, протоколам рабочих совещаний, черновым материалам обследований.

Таким образом, без организованных усилий по регистрации и контролю выполнения этих требований велик риск их не учесть. Решение проблемы достаточно очевидно: следует вести учет со­бираемых требований и контролировать их обработку, оценку и реализацию (или отказ от реализации). Такая работа называется работой по управлению требованиями.

8) Какие действия включает в себя работа с требованиями?

Управление требованиями (requirements management) представ­ляет собой:

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

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

9) Какие цели включает в себя работа с требованиями?

Управление требованиями преследует следующие цели:

достижение соглашения с заказчиком и пользователями о том, что ПП должен делать;

улучшение понимания требований к ПП со стороны разработ­чиков;

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

10) Каково назначение этапа составления спецификации по требованиям заказчика?

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

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

11) Оценку каких ресурсов необходимо выполнить на этапе составления спецификации требований заказчика?

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

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

12) Почему требования в спецификации требований должны быть однозначными?

Используемый инструмент: система подготовки документов (например, MS Word).

Используемые методы и стандарты: процесс организации; мет­рическая программа организации.

Используемые шаблоны: спецификации требований; отчета по обзору; отчета о статусе проекта.

13) Какие основные действия выполняются на этапе разработки ПП?

На этапе разработки ПП выполняются следующие основные действия: кодирование; тестирование; разработка справочной си­стемы ПП; создание документации пользователя; создание вер­сии и инсталляции ПП

14) Каково назначение этапа кодирования?

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

15) Дать общую характеристику этапа Тестирования.

Тестирование представляет собой деятельность по проверке программного кода и документации, она должна заранее планироваться и систематически проводиться с независимым тестировщиком. Его работа начинается с проверки к требованиям ПП. После утверждения спецификации требований им разрабатывается и детализируется план тестирования, создает наборы текстов для проведения интеграционного и системного тестирования. Тестирование завершается созданием отчёта о тестировании, в котором представляются все результаты его проведения. 5 уровней тестирования: модульное, интеграционное, системное, выходное, приемочное.

16) что такое цикл тестирования?

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

17) Дать характеристику модульного тестирования.

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

18) что входит в состав модульного тестирования?

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

19) Характеристика интеграционного тестирования.

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

20) состав интеграционного тестирования.

Элементами являются: 1) проверка функциональности-проверка соответствия отдельных функций, выполняемых модулем. 2) проверка промежуточных результатов. 3) проверка интеграции-проверка того, что модули передают друг другу информацию корректно.

21) характеристика системного тестирования

Системное тестирование предназначено для проверки программной системы в целом, её организации и функционирования на соответствие спецификациям требований заказчика.

22) состав системного тестирования

Состав: 1) ограниченное тестирование-тестирование в ограниченных условиях 2) прогоночное тестирование-тестирование всех функциональных характеристик реальной работы системы, проверка документации на корректность, тесты, определяемые тестировиком.

23) характеристика выходного тестирования

Выходное тестирование-проверяется готовность ПП к поставке заказчику

24) состав Выходного тестирования

Элементы: 1) проверка инсталляции-проверка на корректность инструкции по инсталляции 2) проверка документации-проверка полной готовности документации к передаче заказчику.

25) Характеристика приемочного тестирования

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

26) Определение программной ошибки

Одними из распространенных определений программной ошиб­ки являются следующие два:

программная ошибка — это расхождение между программой и ее спецификацией, причем тогда и только тогда, когда специфи­кация существует и она правильна;

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

27) объяснить категории функциональные недостатки и недостатки пользовательского интерфейса программных ошибок

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

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