1) Термин «программная инженерия» появился впервые в 1968 году на конференции НАТО и предназначался, чтобы спровоцировать поиск решений для происходившего в то время «кризиса программного

1) Термин «программная инженерия» появился впервые в 1968 году на конференции НАТО и предназначался, чтобы спровоцировать поиск решений для происходившего в то время «кризиса программного обеспечения». Это нужно было для создания более качественного, доступного, лучше поддерживаемого и быстрее разрабатываемого ПО.

2) Планирование — оптимальное распределение ресурсов для достижения поставленных целей, деятельность (совокупность процессов), связанная с постановкой целей (задач) и действий в будущем. Задачи: преобразование требований в задание, опред. необход. ресурсов, координация командной работы, оценка рисков, сообщения о возникших проблемах. Процессы: планирование цели, декомпозиция цели, опред. составляющих проекта, оценка длительности работ, опред. и назначение ресурсов, оценка стоимости, составл. расписания.

3) Жизненный цикл разработки ПО – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

Модель разработки ПО — структура, согласно которой построена разработка программного обеспечения (ПО). Существует несколько моделей такого процесса, каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.

4) Диагра́мма Га́нта — это тип столбчатых диаграмм, который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами.

5) Каскадная модель — модель процесса разработки ПО, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

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

7) V-Model является моделью разработки информационных систем, направленной на упрощение понимания сложностей, связанных с разработкой систем.

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

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

9) Модуль прототипирования. Создается «быстрая» частичная реализация системы до составления окончательных требований. Обеспечивается обратная связь между пользователями и разработчиками в процессе выполнения проекта.

Преимущества: уменьшение времени, стоимости, рисков; вовлечение пользователя в процесс разработки.

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

10) Анализ рисков - процедуры выявления факторов рисков и оценки их значимости. Мероприятия по их устранению: анализ требований на работу, провести собеседования (составить команду), контроль бюджета.

11) Инкрементная модель предусматривает дробление продукта на относительно независимые составляющие, которые разрабатываются и вводятся в эксплуатацию по отдельности.

Преимущества: постепенное предоставление результата заказчику.

Недостатки: деление на функциональные блоки замедляет процесс.

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

13) Экстремальное программирование — одна из гибких методологий разработки программного обеспечения. Основные приёмы XP: короткий цикл обратной связи, непрерывный, а не пакетный процесс (частые небольшие релизы), простота понимания. Не годится для больших проектов.

14) MSF-методология ориентирована на создание ПП, которое удовлетворяет требования и обеспечивает поиск решений проблем, которые возникают перед заказчиком. Преимущества: сочетаются простота управления, учет анализа рисков и гибкость. Недостатки: большая сложность.

15) Стандарт – набор принятых правил. Типы стандартов: корпоративный, отраслевой, государственный.

ISO/IEC 12.207 (описывает процесс жизн. цикла); SEI CMM (описывает зрелость процессов разработки ПП); ISO/IEC 15.504 (характеристика качества); ACM/IEEE CC-2001 (видеофайлы).

16) Зрелость компании – коэффициент опыта и компетентности предприятия.

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

17) ISO/IEC 15.504. Процессы: потребитель, поставщик; инженерная категория; вспомогательная; управленческая (процесс администрирования, управления: проектом, качество, рисками); организационная (процесс усовершенствования, управления кадрами, создание инфраструктуры).

18) Проект – работа, направленная на создание нового продукта. Характеристики: цель, уникальность, организация (по времени, ресурсам), сложность, неопределенность, предсказуемость.

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

20) Singleton – шаблон проектирования, предназначенный для создания единственного экземпляра объекта. Варианты реализации: ранняя реализация (Singleton инициализируется одновременно с загрузкой класса); инициализация в статическом блоке (экземпляр класса создается в статическом блоке, обеспечивающем возможность обработки исключений); ленивая инициализация (Singleton с глобальной методом доступа к экземпляру класса).

21) Систем контроля версий git. Ядро представляет собой набор утилит командной строки с параметрами. Все операции с системой контроля версий, такие, как коммит и слияние, производятся только с локальным репозиторием. Команда push передает все новые данные из локального репозитория в удаленный. Команда pull — обратна команде push. Репозиторий Git представляет собой каталог файловой системы, в котором находятся файлы конфигурации репозитория, индекс, описывающий расположение файлов и хранилище, содержащее файлы.

22) Mantis — система отслеживания ошибок в программных продуктах (bugtracker). Позволяет пользователям заводить сообщения об ошибках и отслеживать дальнейший процесс работы над ними со стороны разработчиков. Система является веб-приложением, поэтому не требует для работы специального ПО на стороне клиента и работает через веб-браузер.

23) IT-менеджер — это глава IT-отдела, который управляет им. Заданиями ИТ-менеджера является разработать стратегию развития и управления ИТ-отделом компании или компании в целом. Компетенции: подбор и управ. кадрами; подготовка и исп. планов проекта; руководство командой; обеспечение связи между подразделениями; обеспеч. готового продукта.

24) Паттерн Builder. Используется для поэтапного создания объекта в сложной системе. Используется в системе, где данные должны иметь несколько представлений.

25) IT-менеджер — это глава IT-отдела, который управляет им. Заданиями ИТ-менеджера является разработать стратегию развития и управления ИТ-отделом компании или компании в целом. Компетенции: подбор и управ. кадрами; подготовка и исп. планов проекта; руководство командой; обеспечение связи между подразделениями; обеспеч. готового продукта.

26) Управление задачами проекта – эффективное руководство командой и задачами проекта. Использование специализированного ПО необходимо для средних и больших команд.

JIRA - продукт для трекинга задач у разработчиков, выполняет функции баг-трекера и площадки для управления проектами.

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

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

27) Модели организации команд: X (административная), Y (хауса), Z (открытая). Ролевая модель - управление доступом на основе ролей. Позиции: менеджер, проектировщик, разработчик, тестировщик, инженер качества, технический писатель).

28) Модели организации команд: X (административная), Y (хауса), Z (открытая). Проектировщик выполняет проектировку архитектуры, контролирует выполнение, анализ требований. Разработчик отвечает за создание конечного продукта. Тестировщик — специалист, занимающийся тестированием. В его обязанность входит поиск вероятных ошибок и сбоев.

29) Коллективная разработка подразумевает разделение труда между группой людей. Технологии: Git, Mercurial.

30) Модели организации команд: X (административная), Y (хауса), Z (открытая). Позиции: инженер качества (контрол. качество разработки и конечного продукта); технический писатель (разрабатывает документацию), технолог (поддержки модели жизнен. цикла и создание служб по ее поддержке).

31) Административная модель – «каждый не любит работу», является управленческой моделью, где каждому члену предписан набор правил и описывает реальный процесс принятия решений в трудных ситуациях. Преимущества: предсказуемость результата, четкое распределение ролей и обязанностей. Недостатки: плохая адаптируемость к инновациям.

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

33) Система управления версиями — ПО для облегчения работы с изменяющейся информацией. Позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение. Git. Ядро представляет собой набор утилит командной строки с параметрами. Все операции с системой контроля версий, такие, как коммит и слияние, производятся только с локальным репозиторием. Mercurial — распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода. В первую очередь является консольной программой. Subversion — централизованная система (в отличие от распределённых систем, таких как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.

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

35) Открытая архитектура подразумевает «работаем над одной идеей спокойно и вместе». Особенность: адаптирование к условиям работы, распределение ответственности, отсутствие узкой специализации и взаимозаменяемость.

36) Коммуникация – передача сообщений между участниками проекта. Цель: получение информации. Позволяет быстро опред. мнение человека. Виды: бумажная запись, звуко-видео-запись, эл. почта, телефонный разговор, видео-конференция, контактное общение.

37) Зрелость процесса - это степень, в которой конкретный процесс удовлетворяет требованиям определенности, управляемости, измеримости, контролируемости и результативности. Уровни зрелости процессов компании или конкретных областей деятельности описаны в различных стандартах. Уровни зрелости: начальный, повторяемый, определяемый, управляемый, оптимизируемый. Под компетенцией аттестаторов подразумеваются области возможной оценки.

38) Команда – это коллектив, который успешно достигает поставленных целей.

Группа - совокупность людей, объединенных общностью интересов, профессии, деятельности.

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

40) CMM ("модель зрелости возможностей"). Подразумевает зрелость процессов в компании. Была разработана для измерения эффективности работы подрядчиков, выполняющих заказы правительства США на разработку и поставку ПО. Позже модель была обобщена для любых компаний-разработчиков ПО.

Дата добавления: 2015-08-29