26.Примерная структура процесса и организации, занимающейся разработкой пп

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

Исходя из этого, структура выглядит следующим образом:

- тимлидер – осуществляет распределение частей проекта между старшими разработчиками, просмотр кода, отслеживает сроки выполнения заданий а так же создание новых при необходимости;

- старшие разработчики во главе с тимлидером – создают спецификации, основываясь на предложениях самих разработчиков или пожеланиях заказчика. Старшие разработчики распределяют задания среди младших или выполняют сами, после чего проверяют результаты или передают другим (или тимлидеру) для проверки. Так же задание может быть передано другой команде (скажем, системным администраторам) для выполнения промежуточных действий. Задачи старших разработчиков так же могут различаться в зависимости от роли в команде – релиз-менеджер, поддержка пользователей и т.д.);

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

27.Роль метрик в процессе разработки пп

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

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

28.Основные источники метрических показателей

(БЛЯТЬ ХОТЬ УБЕЙТЕ , НЕ НАШЕЛ)….

29.Планирование работ по созданию пп: структура разделения работ по созданию пп, оценка объемов, ресурсов, рисков

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

Цель управления требованиями состоит в том, чтобы гарантировать что организация документирует, проверяет и удовлетворяет потребности и ожидания её клиентов и внутренних или внешних заинтересованных лиц. Управление требованиями начинается с выявления и анализа целей и ограничений клиента. Управление требованиями далее включает поддержку требований, интеграцию требований и организацию работы с требованиями и сопутствующей информацией, поставляющейся вместе с требованиями. Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта, и чтобы ни один класс разработок не доминировал над другим 31- Проектирование является важнейшим этапом в современной технологии создания ПО. На этом этапе закладываются не только основные технические характеристики программных изделий, но и определяется содержание и характер работы на остальных этапах разработки: кодирования, тестирования и отладке. Решения, принимаемые на этапе проектирования, определяют простоту или сложность сопровождения. 32- Системное программное обеспечение предназначено для:

      создания операционной среды функционирования других программ (другими словами, для организации выполнения программ);

      автоматизации разработки (создания) новых программ;

      обеспечения надежной и эффективной работы самого компьютера и вычислительной сети;

      проведения диагностики и профилактики аппаратуры компьютера и вычислительных сетей;

      выполнения вспомогательных технологических процессов (копирование, архивирование, восстановление файлов программ и баз данных и т.д.).

 

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

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

33-хуй знает честно 34- В разработке программного обеспечения, стадии разработки программного обеспечения используются для описания степени готовности программного продукта.  Кодирование обеспечивает реализацию проектных решений в выбранной среде программирования. Тестирование — обязательный этап для выявления дефектов программного продукта 35- Часто бывает так, что над созданием ПП работают несколько человек, но никто из них не несет полной ответственности за его качество. Справочная система ПП формируется на основе материала, разработанного для руководства пользователя. У хорошо документированного ПП имеются следующие пре¬имущества: • Легкость использования., Меньшая стоимость технической поддержки , Высокая надежность. Легкость сопровождения. Упрощенная установка. Коммерческий успех. Достоверность информации.  36- Тестирование представляет собой деятельность по проверке программного кода и документации. Она должна заранее плани¬роваться и систематически проводиться специально назначенным независимым тестировщиком. 1-синтаксическая проверка 2- проверка соответствия стандартам кодирования 3- технический обзор программного кода.  37. Виды тестирования. Требования к хорошему тесту (Модульное тестирование-представляет собой проверки программных процедур и подпрограмм, Интеграционное тестирование-проводится для проверки совместной работы отдельных модулей, Системное тестирование-предназначен для проверки программной системы в целом, Выходное тестирование-проверяется готовность ПП к поставке заказчику, Приемочное тестирование.)(Хороший тест-должна быть достаточной вероятность выявления тестом ошибки, набор тестов не должен быть избыточным, должен быть наилучшим в своей категории, не должен быть слишком простым или сложным)

38. Программные ошибки. Синтаксические и семантические ошибки. (Функциональные недостатки, недостатки пользовательского интерфейса, обработка ошибки, ошибки вычислений, перегрузки, ошибки управления потоком)(

39. Понятие тестирования. Понятие отладки. Различие между отладкой и тестированием.

40. Тестирование документации(Читая и анализируя документацию, тестировщик прежде всего должен уделять внимание ее точности, полноте, ясности, простоте использования и тому насколько она соответствует ПП)

41. Роль этапа сопровождения в ЖЦ ПП(Подготовительная работа, анализ проблем и запросов на модификацию ПП, модификация ПП, проверка и приемка, перенос ПП в новую среду работы, снятие ПП с эксплуатации)

42. Управление поставками программных продуктов(Процедура поставки ПП, схемы классификации ПП, методы проверки и отслеживанию соответствий ПП)

43. Обеспечение надежности программных продуктов(Надежность ПП необходимо планировать на начальных стадиях выполнения проекта. Методы: Прогнозирование ошибок, Предотвращение ошибок, Устранение ошибок, Обеспечение отказоустойчиватси)

44. Характеристики качества программного продукта

1 Угринович Н.Д. Информатика и информационные технологии. – М.: Бином, 2007. – с. 262.