Оглавление

1. Классические этапы разработки ПО. .......................................................................................................... 2

2. Что такое техническое задание? Что такое список спецификаций? ....................................................... 2
3. Что такое календарный план? Как он выглядит? Как оценить сроки выполнения проекта? ............... 3
4. Что такое смета проекта? Как она выглядит?? .......................................................................................... 5
5. Какие задачи в проекте выполняют: менеджер проекта, тимлид, дизайнер, разработчик…? ............ 5
6. Что такое макет пользовательского интерфейса? .................................................................................... 6
7. Что такое система версионного контроля? Репозиторий? ...................................................................... 6
8. Что такое ветка в репозитории? Как создать ветку в репозитории? ....................................................... 6
9. Что такое gitflow? ......................................................................................................................................... 7
10. UML-диаграммы пакетов: что показывают данные диаграммы? ......................................................... 8
12. Инкапсуляции и сокрытия реализации. ................................................................................................... 9
13. Агрегации и композиция. ........................................................................................................................ 10
14. Наследование. .......................................................................................................................................... 12
15. Полиморфизма. ........................................................................................................................................ 16
16. Что такое исключение?. ........................................................................................................................... 16
17. Форма и элемент управления – отличие? Отличие Show() и ShowDialog()? DialogResult? ............... 17
18. Winforms: стандартные элементы управления – кнопки, чекбоксы, комбобоксы, листбоксы ........ 19
19. Winforms: как организовать передачу данных между двумя формами?........................................... 22
20. RSDN –?...................................................................................................................................................... 22
21. Для чего нужны xml-комментарии? ....................................................................................................... 26
22. Что такое цикломатическая сложность метода?? ................................................................................ 26
23. Что такое юнит-тест? Что такое Setup и Teardown? Что такое степень покрытия кода тестами ...... 27
24. Что такое юнит-тест? Приведите пример позитивного юнит-теста?................................................... 28
25. Что такое юнит-тест? Приведите пример негативного юнит-теста?. .................................................. 29
26. Что такое сервер непрерывной интеграции? Какие задачи он выполняет? ...................................... 30
27. Как автоматизировать сборку установщика приложения? .................................................................. 31
28. Методология Scrum: что такое резерв проекта (project backlog)? ...................................................... 31
29. Методология Scrum: что такое спринт? Что такое story points? .......................................................... 31
30. Методология Scrum: что такое планировочный покер? ...................................................................... 32
31. Методология Scrum: что такое Scrum-доска? ....................................................................................... 32
32. Методология Scrum: что такое Burndown Chart? .................................................................................. 33
33. Методология Scrum: чем отличаются демонстрация и ретроспектива? ............................................ 33
34. В чем разница между каскадной и итерационной (гибкой) методологиями управления
проектами? ..................................................................................................................................................... 34
35. Что такое система управления проектами? Для чего она нужна? Кто в ней работает?.................... 36
1. Классические этапы разработки ПО. Кратко опишите каждый этап – что на нём
делается, кто его выполняет, что является результатом этапа?
• появление задачи;
• составление ТЗ и анализ задачи;
Все изначальные требования должны быть отражены на бумаге и заверены обеими
сторонами: заказчиком или его представителем и представителем команды
разработчиков.
• составление проекта программной системы;
Проект программной системы — это документ, описывающий будущую программную
систему, взаимодействие её частей, ответственность каждой части системы таким
образом, чтобы можно было приступить к реализации программы без значительных
модификаций документа.
• реализация проекта системы;
• тестирование ПО;
Этап тестирования ПО — это финальный этап, на котором можно исправить имеющиеся
в программе дефекты.
• поддержка ПО.
После передачи готового продукта заказчику наступает этап поддержки программного
продукта, имеется в виду исправление появляющихся в ПО ошибок, которые не были
выявлены на этапе тестирования. Фиксация необходимых для решения задач может
осуществляться одним из перечисленных способов:
• отправка отчёта об ошибке с помощью заранее встроенной системы обратной связи в
разработанной программе.
• предоставление пользователю электронного адреса или телефона отдела поддержки
ПО, куда он может обратиться напрямую;
• открытие пользователям системы управления проектов, в которую они могут вносить
появившиеся ошибки или пожелания в виде задач.
ИЛИ МОЖНО ТАК:
1. Макетирование
2. Проектирование
3. Реализация
4. Тестирование
5. Внедрение

2. Что такое техническое задание? Что такое список спецификаций? Как должны
формулироваться спецификации?
ТЗ составляет менеджер проекта.
Техническое задание – документ, описывающий требования к разрабатываемой системе:
функциональные, системные, требования к производительности и т.д. Важными
разделами технического задания являются назначение проекта, целевая аудитория /
контекст использования. Может содержать перечень функциональных требований, а
может содержать точные макеты интерфейсов или описание требуемой архитектуры
проекта, если приложение будет встраиваться как часть другой инфраструктуры.
Список спецификаций - точное описание функций, структура входных и выходных
данных, методы и средства их размещения. Определяются алгоритмы обработки данных.
В общем случае, спецификации определяют те функции, которые должна выполнять
система, не указывая, каким образом это достигается.

3. Что такое календарный план? Как он выглядит? Как оценить сроки

выполнения проекта?
Календарный план – документ, описывающий основные сроки выполнения проекта.
Правильно и максимально точно можно оценить только те задачи, которые вы уже
многократно делали.
Разработку лучше разделить на этапы, например, по месяцу (итерационная разработка),
или по логическим этапам: макетирование, проектирование, реализация, тестирование и
т.д. (каскадная разработка). Для каждого этапа указывается дата начала, дата завершения,
а также что в ходе этапа будет реализовано и что будет предоставлено заказчику.
Отдельной графой указывается стоимость этапа.
Таблица 2.1 Пример календарного плана каскадной разработки
Календарный план проекта для каскадной методологии в каждой отдельной строке будет
описывать классические этапы разработки: макетирование, проектирование, реализация,
тестирование, внедрение. Сроки выполнения каждого этапа будут отличаться, так как,
например, макетирование занимает меньше времени, чем реализация. Стоимости также
будут отличаться. Например, макетирование и проектирование занимают равное
количество дней, однако стоимость работы проектировщика больше, чем стоимость
работы дизайнера. Поэтому этап проектирования будет оцениваться дороже.
Теперь рассмотрим календарный план для итерационной разработки:
Тут же все итерации имеют одинаковый период, а каждая итерация завершается
выпуском новой версии приложения. При этом новые функции описываются в
календарном плане. Задачи макетирования, проектирования и тестирования равномерно
распределяются по всем итерациям, за счет чего в каждой итерации участвуют все
специалисты, и стоимость разработки этапов примерно одинаковая.
Таким образом, заказчику предоставляется две таблицы – календарный план и смета
проекта.

4. Что такое смета проекта? Как она выглядит? Как на основе календарного плана
составить смету проекта?
Смета – документ, описывающий стоимость отдельных этапов.

5. Какие задачи в проекте выполняют: менеджер проекта, тимлид, дизайнер,

разработчик, QAспециалист? Что означает разделение junior/middle/senior?
Проджект-менеджер (англ. project manager) помогает в непосредственной
реализации технических задач: общение с командой разработчиков, бюджет,
содержание и сбор требований по проекту, постановка целей, распределение задач и
контроль за соблюдением сроков.
Тимлид (англ. Team lead) необходим на масштабных проектах повышенной
сложности (например, при разработке банковских продуктов). Он является
руководителем группы разработчиков и отвечает за техническое управление.
-менеджер проекта: составление ТЗ;
- дизайнер: макетирование;
- тестировщик: составление плана тестирования, тестирование;
- старший разработчик: проектирование, код ревью.
- все разработчики: разработка функций #1-8, отладка, сборка установщика.
Junior-разработчики - разработчики с малым опытом или без опыта вовсе, но имеют
базовые знания в программировании.
Middle-разработчики уже обычно имеют некоторый опыт, достаточный для решения
типичных задач, могут аргументировать и объяснить свои решения, это командные
«игроки».
Senior-разработчики в свою очередь обладают опытом и навыками, которые позволяют
им участвовать в проектировании систем, обосновывать и принимать решения,
влияющие на общую инфраструктуру. Также мы ожидаем от сотрудников этого уровня
активного участия в обучении других членов команды.
6. Что такое макет пользовательского интерфейса? Опишите последовательность
действий для составления и утверждения макетов пользовательского интерфейса?
Кто участвует в этом процессе?
Макеты интерфейса – документ с утвержденными макетами всех окон/страниц
пользовательского интерфейса, а также с указанием связей между окнами. Также макеты
могут показывать реакцию, например, на ввод некорректных данных.

7. Что такое система версионного контроля? Что такое репозиторий? Чем

отличаются локальный и удаленный репозитории? Что такое коммит? Что такое
синхронизация? Что такое gitignore? Какие файлы нежелательно хранить под
версионным контролем и почему?
Система контроля версий — это система, записывающая изменения в файл или набор
файлов в течение времени и позволяющая вернуться позже к определённой версии.
Репозиторий— это виртуальное хранилище проекта. В нем можно хранить версии кода
для доступа по мере необходимости.
Gitignore это файл, который лежит в корневой папке репозитория и содержит список
расширений файлов, которые не следует автоматически добавлять в репозиторий при
коммитах. Например, в репозиторий не имеет смысла добавлять результаты компиляции,
находящиеся в папках bin проектов Visual Studio – так как эти файлы можно всегда
получить с помощью компиляции, а хранение их в репозитории – лишняя нагрузка. Также
в gitignore можно указать расширения для файлов настроек среды разработки – среда
разработки создает файлы ваших настроек и помещает их в папку с проектом.

8. Что такое система версионного контроля? Что такое ветка в репозитории? Как
создать ветку в репозитории? Что такое слияние веток? Что такое конфликт
версионного контроля? Как устраняются конфликты версионного контроля?
Ветка в Git'е — это просто «скользящий» указатель на один из коммитов. Для создания
ветки нажмите кнопку Branch-> new (через консоль нинаю)
Слияние веток (кнопка Merge)– это перенос изменений с одной ветки на другую. При
этом слияние не затрагивает сливаемую ветку, то есть она остается в том же состоянии,
что позволяет нам потом продолжить работу с ней.
Ситуация, когда при слиянии нескольких версий сделанные в них изменения
пересекаются между собой, называют конфликтом. При конфликте изменений система
управления версиями не может автоматически создать объединённый проект, и
вынуждена обращаться к разработчику. Для разрешения конфликта система, в общем
случае, предлагает разработчику три варианта конфликтующих файлов: базовый,
локальный и серверный.
Если несколько человек изменили один и тот же участок кода, то, автоматически,
объединить такие изменения невозможно. Обычно, системы контроля версий
предоставляют собой инструменты, позволяющие вручную внести необходимые правки
в тест программ, чтобы объединить конфликтующие части кода.

9. Что такое система версионного контроля? Что такое gitflow? Какие ветки
должны создаваться согласно gitflow? Какие ограничения на доступ и к каким
веткам репозитория описаны в gitflow? Что такое pull request и чем он отличается
от коммита?
Git-flow — это методология ветвления и слияния. У нас есть две основные ветки: master
и develop.
В ветке master содержится код продукта. А вся работа делается в ветке develop.
Во время работы на основе develop создаются так называемые feature-ветки. Их может
быть неограниченное количество. Далее, у нас есть ветка release, которая используется
для подготовки к новому релизу проекта. Наконец, есть ветка hotfix, которая служит для
срочного исправления багов.
Вот как в теории, происходит рабочий процесс в Gitflow:
1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и
делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка
release, куда перемещается текущая версия. Правка багов будет происходить на этой же
ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с
develop
8. Кроме того, этот момент можно отметить на master-ветке
pull request — предложение изменения кода в чужом репозитории.
1. Крутой программер создал репозиторий.
2. Вы сделали форк его репозитория (т.е. скопировали к себе).
3. Вы сделали какие-то крутые изменения в своём репозитории.
Теперь если вы хотите, чтобы крутой дядя внёс ваши крутые изменения в свой крутой
код. И вы просите, чтобы он взял ваши изменения, т.е. сделал git pull. Это и
называется pull request
10. UML-диаграммы пакетов: что показывают данные диаграммы? Как они
составляются? Как рисуются пакеты на диаграммах пакетов? Какие связи между
пакетами могут быть? Чем связи отличаются друг от друга? Нарисуйте диаграмму
пакетов для примера.
В качестве связей между пакетами используется импортирование, т. е. когда элементы
одного пакета обращаются к доступным элементам другого пакета. Зависимость со
стереотипом «import» позволяет при обращении сущности из одного пакета к сущности
другого пакета указывать только ее имя, а не полную спецификацию.
Семантика зависимости со стереотипом «merge» (Слияние пакетов) - это "направленная
связь между двумя пакетами, которая указывает, что содержимое двух пакетов должно
быть объединено. Это очень похоже на обобщение в том смысле, что исходный элемент
концептуально добавляет характеристики целевой элемент к его собственным
характеристикам, что приводит к элементу, который сочетает в себе характеристики
обоих ". В этом отношении, если элемент существует как в исходном пакете, так и в
целевом пакете, тогда определение исходного элемента будет расширено, чтобы
включить определение целевого элемента.

11. Дайте определения понятиям класса и объекта. Напишите пример класса с

несколькими полями и методами, а также покажите, как создавать экземпляры
класса. Пример на языке Си++ или C#.
Класс – это описание объектов, объект – это инсталляция (отображение) класса в памяти.
public class Contact
{
private string _surname;
private string _name;
private string _email;
/// Свойства фамилии
public string Surname
{
 get => _surname;
set
{
ValidateTitleLength(value);
value = ToCorrectRegister(value);
_surname = value;
}
}
/// Метод для проверки значений. Строка не должна быть пустой или превышать 50
символов.
void ValidateTitleLength(string str)
{
if (string.IsNullOrEmpty(str))
{
throw new ArgumentException("Ошибка. Пустая строка");
}
if (str.Length > 50)
{
throw new ArgumentException("Ошибка. Значение не должно превышать 50
символов");
}
}
/// конструктор класса по умолчанию
public Contact() { }

/// конструктор со всеми полями класса

/// <param name="surname">Фамилия</param>
/// <param name="name">Имя</param>
/// <param name="email">Электроонная почта</param>
public Contact(string name, string surname, string email)
{
this.Email = email;
this.Name = name;
this.Surname = surname;
}
var contact = new Contact("Ani","Mnatsakanyan", "Anime@mail.ru");

12. Дайте определение понятиям инкапсуляции и сокрытия реализации. Напишите

пример класса с методами-аксессорами (свойствами), где методы-аксессоры
обеспечивают защиту от присвоения неправильных данных. А также создайте
экземпляр класса и покажите, как работать с методами-аксессорами. Пример на
языке Си++ или C#. Нарисуйте UML-диаграмму вашего примера.
Свойство системы, позволяющее объединять в едином описании состояние и
поведение объектов, а также скрывать детали своей реализации, называется
инкапсуляция.
private string _surname;
public string Surname
{
 get => _surname;
set
{
if (str.Length > 50)
{
throw new ArgumentException("Ошибка. Значение не должно превышать 50
символов");
}
_surname = value;
}}

Классы позволяют определить доступность своих полей и методов с помощью

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

13. Дайте определения понятиям агрегации и композиции. Напишите примеры

классов, связанных агрегацией и композицией. Создайте экземпляры классов,
покажите, как обращаться к агрегируемым объектам. Пример на языке Си++ или
C#. Нарисуйте UML диаграмму вашего примера.
Когда объект является полем другого класса, такая связь называется агрегированием.
Агрегирование делится на агрегацию и композицию. Для композиции время жизни
объекта-контейнера и объекта-поля должны совпадать. Для агрегации время жизни
объекта-контейнера и объекта-поля различны. Агрегация может связывать экземпляры
класса как один ко одному, так и один ко многим, так и в других численных
соотношениях.
Композиция – это когда двигатель не существует отдельно от автомобиля. Он
создается при создании автомобиля и полностью управляется автомобилем. В
типичном примере, экземпляр двигателя будет создаваться в конструкторе
автомобиля.
class Engine
{
int power;
public Engine(int p)
{
power = p;
}
}

class Car
{
string model = "Porshe";
Engine engine;
public Car()
{
this.engine = new Engine(360);
}
}

Агрегация – это когда экземпляр создается где-то в другом месте кода, и передается
в конструктор автомобиля в качестве параметра.
class Engine
{
int power;
public Engine(int p)
{
power = p;
}
}

class Car
{
string model = "Porshe";
Engine engine;
public Car(Engine someEngine)
{
this.engine = someEngine;
}
}
Engine goodEngine = new Engine(360);
Car porshe = new Car(goodEngine);
14. Дайте определение понятию наследования. Напишите пример наследуемых
классов. Создайте экземпляры классов, обратитесь к их полям и методам. Пример
на языке Си++ или C#. Нарисуйте UML-диаграмму вашего примера.
Наследование – это свойство системы, позволяющее описать новый класс на основе
уже существующего с частично или полностью заимствующейся
функциональностью. Класс, от которого производится наследование, называется
базовым или родительским. Новый класс – потомком, наследником или производным
классом. С помощью наследования можно создавать новые классы, а также выделять
общую реализацию нескольких классов в один базовый класс для уменьшения
дублирования кода.
namespace ConsoleApp1
{
// Класс Book - базовый класс
class Book
{
// 1. Внутренние поля класса
string title; // название (заголовок) книги
string author; // фамилия и имя автора
double price; // стоимость книги

// 2. Конструктор с 3 параметрами
public Book(string _title, string _author, double _price)
{
title = _title;
author = _author;
// 3. Свойства типа get/set для доступа к полям класса
public string Title
{
get { return title; }
set { title = value; }
}

public string Author

{
get { return author; }
set { author = value; }
}

public double Price

{
get { return price; }
set
{
price = value;
}
}
// Класс, который наследует класс Book - добавляет жанр к книге.
class BookGenre : Book
{
// 1. Внутреннее поле - жанр, к которому относится книга
string genre;

// 2. Конструктор с 4 параметрами.
// Вызывает конструктор базового класса с помощью base(...).
public BookGenre(string _title, string _author, double _price, string _genre) :
base(_title, _author, _price)
{
genre = _genre;
}

// 3. Свойство доступа к полю genre

public string Genre
{
get { return genre; }
set { genre = value; }
}

// 4. Метод Print() - вызывает метод базового класса

// В заголовке метода используется ключевое слово new. Это
// есть рекомендация компилятора - подчеркнуть, что данный метод
// прячет одноименный метод базового класса.
public new void Print()
{
base.Print(); // вызвать метод Print() базового класса Book
WriteLine("genre = {0}", genre);
}
}

// Класс, который наследует класс BookGenre - добавляет к иерархии классов

// поле издателя.
// Перед классом используется ключевое слово sealed - это означает,
// что данный класс не может быть унаследован другими классами.
sealed class BookGenrePubl : BookGenre
{
// 1. Внутреннее поле - информация об издателе
private string publisher;

// 2. Конструктор с 5 параметрами - Вызывает конструктор базового

// класса BookGenre() с помощью ключевого слова base.
public BookGenrePubl(string _title, string _author, double _price,
string _genre, string _publisher) : base(_title, _author, _price, _genre)
{
publisher = _publisher;
}
 // 3. Свойство доступа к полю publisher
public string Publisher
{
get { return publisher; }
set { publisher = value; }
}

// 4. Метод Print() - вызывает метод базового класса.

// В объявлении метода рекомендуется использовать
// ключевое слово new, так как данный метод "прячет" метод базового класса.
public new void Print()
{
base.Print();
WriteLine("publisher = {0}", publisher);
}
}

class Program
{
static void Main(string[] args)
{
// 1. Объявить экземпляр класса Book
Book b1 = new Book("Title - 01", "Author - 01", 122.25);

// 2. Вывести значения полей класса экземпляра b1

b1.Print();

// 3. Объявить экземпляр класса BookGenre

BookGenre bg1 = new BookGenre("Title - BookGenre", "Author - BookGenre", 200.33,
"Story");

// 4. Вывести значения полей экземпляра bg1

WriteLine("-------------------");
bg1.Print();

// 5. Объявить экземпляр класса BookGenrePubl

BookGenrePubl bp1 = new BookGenrePubl("Title - BookGenrePubl", "Aurhor -
BookGenrePubl",
300.55, "Story", "Pupkin Inc."
}
}
}
15. Дайте определение понятию полиморфизма. Напишите пример полиморфных
классов. Создайте экземпляры полиморфных классов, поместите их в переменную
интерфейса/базового класса – вызовите полиморфные методы через переменную
интерфейса/базового класса. Пример на языке Си++ или C#. Нарисуйте UML-
диаграмму вашего примера.
Полиморфизм – это свойство системы использовать объекты с одинаковым
интерфейсом без информации о типе и внутренней структуре объекта.
Для полиморфизма необходимо создать базовый класс с чисто виртуальными функциями
– интерфейс. В дочерних классах определяется собственная реализация интерфейса.
Таким образом, можно сказать, что дочерние классы обладают единым интерфейсом. В
дальнейшем, вне иерархии наследования создается указатель на базовый класс, который
может хранить экземпляры дочерних полиморфных классов. Обращаясь через указатель
к методам базового класса (через общий интерфейс) мы можем вызвать разную
реализацию, в зависимости от объекта, который хранится в указателе в данный момент
времени

16. Что такое исключение? Как выбросить исключение? Как обработать

исключение? Какие ключевые слова для этого используются? Какие стандартные
типы исключений есть в C#(Си++)? Пример на языке Си++ или C#.
Механизм, который необходим для раннего обнаружения ошибок в исходном коде и
обеспечения целостности данных в классе.

Инструкция try-catch состоит из блока try. Блок try содержит защищаемый код, в
котором могут происходить исключения. Этот блок выполняется до момента
возникновения исключения или до своего успешного завершения. После следует одно
или несколько предложений catch, в которых определяются обработчики для различных
исключений.

При возникновении исключения среда CLR ищет оператор catch, который обрабатывает
это исключение. Если выполняющийся в данный момент метод не содержит такого блока
catch, то среда CLR рассматривает метод, который вызвал текущий метод, и т. д. по стеку
вызовов. Если блок catch не найден, то среда CLR отображает пользователю сообщение о
необработанном исключении и останавливает выполнение программы.
тип объекта ошибки может передаваться оператору throw в языке C#?
if (value.Year < 1900 || value.Date > nowDate || value == null)
{
throw new ArgumentException("Ошибка. Некорректная дата ");
}
Типы исключений:

 DivideByZeroException: представляет исключение, которое генерируется

при делении на ноль
 ArgumentOutOfRangeException: генерируется, если значение аргумента
находится вне диапазона допустимых значений
 ArgumentException: генерируется, если в метод для параметра передается
некорректное значение
 IndexOutOfRangeException: генерируется, если индекс элемента массива
или коллекции находится вне диапазона допустимых значений
 InvalidCastException: генерируется при попытке произвести недопустимые
преобразования типов
 NullReferenceException: генерируется при попытке обращения к объекту,
который равен null (то есть по сути неопределен)

17. Winforms: понятие формы и элемента управления – в чем отличие? В чем

отличие методов Show() и ShowDialog() у форм? Что такое DialogResult и для чего
он используется? Напишите пример использования DialogResult.
Windows Forms – это набор библиотек для создания десктоп-приложений для oc
Форма – часть пространства экрана, обычно прямоугольной формы, которую можно
использовать для представления сведений пользователю и для получения сведений от
него.
На форме размещаются элементы управления.
Элемент управления (или управляющий элемент, программный элемент,
компонент Windows-форм, или контрол) – это объект на форме, который придает
форме новые функциональные возможности и формирует пользовательский
интерфейс.
show отображает обычное окно, а ShowDialog - модальное.
[Модальные окна, использование ShowDialog]
Модальное окно должно блокировать другие окна, пока не будет закрыто модальное
окно.
Пример запуска диалогового (модального) окна настройки, вызываемого из меню:
private void SetupStripMenuItem_Click(object sender, EventArgs e)
{
//Program.form2.Show();
Program.form2.ShowDialog();
}
[Важные отличия Show от ShowDialog]
1. Show() запускает отображение обычного окна, а ShowDialog() отображает модальное
окно. Отличия обычного окна от модального известны - обычное окно равноправно со
всеми окнами приложения, а модальное окно блокирует все остальные окна
приложения, пока не будет закрыто это модальное окно.
2. Если после вызова Show() пользователь закроет вызванное окно, то повторно вызвать
Show() не получится, так как объект окна будет уничтожен, и его надо будет создавать
заново. Т. е. Использование Show() всегда должно быть по такой схеме: создание
экземпляра класса окна (), Show(), закрытие окна. При каждом вызове Show() экземпляр
класса окна нужно создавать заново в коде приложения.
3. ShowDialog() работает по другому: после закрытия пользователем окна (в отличие от
Show()) экземпляр класса окна не будет уничтожен, поэтому не нужно перед каждым
новым вызовом ShowDialog создавать экземпляр класса. Этот экземпляр класса может
быть создан только один раз при старте приложения (например, в функции Main модуля
Program.cs).
4. Свойства модального окна нужно менять в самом классе этого окна, а не из классов
других окон, так как действие кода из другого класса не будет производить никакого
эффекта на модальное окно. Например, поменять свойства Top и Left модального окна,
влияющие на его положение, из модулей других окон не получится
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Form2 frm = new Form2();
frm.Show();
Application.Run(new Form1());
}
После запуска программы отобразятся сразу две формы, Form1 и Form2.
Чтобы можно было вызывать из Form1 подпрограммы и функции (методы) из Form2 (и
наоборот), то необходимо инициализировать и запускать формы немного по-другому
(код из Program.cs):
namespace MyApp
{
static class Program
{
static public Form1 frm1;
static public Form2 frm2;
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
frm1 = new Form1();
frm2 = new Form2();
frm2.Show();
Application.Run(frm1);
}
}
}
Пример вызова из класса Form2 (процедура Form2_FormClosed) метода класса Form1
(процедуру Close):
private void Form2_FormClosed(object sender, FormClosedEventArgs e)
{
Program.frm1.Close();
}
Объект DialogResult, представляющий результат формы при использовании в
качестве диалогового окна. Возвращает или задает результат диалога для формы.
form.ShowDialog();
if(form.DialogResult == OK)
{
…
}
18. Winforms: стандартные элементы управления – кнопки, чекбоксы, комбобоксы,
листбоксы – как с ними работать? Напишите небольшие примеры кода, как
работать с данными элементами управления.
Через элементы управления пользователь взаимодействует с программой. Элементы
управления размещаются на формах – окнах. Формы размещают на себе элементы
управления, а также хранят логику их взаимодействия между собой
Наиболее часто используемым элементом управления является кнопка. Обрабатывая
событие нажатия кнопки, мы может производить те или иные действия.
При нажатии на кнопку на форме в редакторе Visual Studio мы по умолчанию попадаем
в код обработчика события Click, который будет выполняться при нажатии:
Элемент CheckBox или флажок предназначен для установки одного из двух значений:
отмечен или не отмечен. Чтобы отметить флажок, надо установить у его
свойства Checked значение true.
private void checkBox_CheckedChanged(object sender, EventArgs e)
{
CheckBox checkBox = (CheckBox)sender; // приводим отправителя к элементу типа
CheckBox
if (checkBox.Checked == true)
{
MessageBox.Show("Флажок " + checkBox.Text + " теперь отмечен");
}
else
{
MessageBox.Show("Флажок " + checkBox.Text + " теперь не отмечен");
}
}
Элемент ComboBox образует выпадающий список и совмещает функциональность
компонентов ListBox и TextBox. Для хранения элементов списка в ComboBox также
предназначено свойство Items.
Подобным образом, как и с ListBox, мы можем в окне свойств на свойство Items и нам
отобразится окно для добавления элементов ComboBox И как и с компонентом ListBox,
здесь мы также можем программно управлять элементами.
Добавление элементов:
// добавляем один элемент
comboBox1.Items.Add("Парагвай");
// добавляем набор элементов
comboBox1.Items.AddRange(new string[] { "Уругвай", "Эквадор" });
// добавляем один элемент на определенную позицию
comboBox1.Items.Insert(1, "Боливия");
Элементы в список могут добавляться как во время разработки, так и программным
способом. В Visual Studio в окне Properties (Свойства) для элемента ListBox мы можем
найти свойство Items. После двойного щелчка на свойство нам отобразится окно для
добавления элементов в список:
В пустое поле мы вводим по одному элементу списка - по одному на каждой строке.
После этого все добавленные нами элементы окажутся в списке, и мы сможем ими
управлять:
Программное управление элементами в ListBox
Добавление элементов
Итак, все элементы списка входят в свойство Items, которое представляет собой
коллекцию. Для добавления нового элемента в эту коллекцию, а значит и в список, надо
использовать метод Add, например: listBox1.Items.Add("Новый элемент");. При
использовании этого метода каждый добавляемый элемент добавляется в конец списка.
Можно добавить сразу несколько элементов, например, массив. Для этого используется
метод AddRange:
string[] countries = { "Бразилия", "Аргентина", "Чили", "Уругвай", "Колумбия" };
listBox1.Items.AddRange(countries);
Вставка элементов
В отличие от простого добавления вставка производится по определенному индексу
списка с помощью метода Insert:
listBox1.Items.Insert(1, "Парагвай");
В данном случае вставляем элемент на вторую позицию в списке, так как отсчет
позиций начинается с нуля.
Удаление элементов
Для удаления элемента по его тексту используется метод Remove:
listBox1.Items.Remove("Чили");
Чтобы удалить элемент по его индексу в списке, используется метод RemoveAt:
listBox1.Items.RemoveAt(1);
Кроме того, можно очистить сразу весь список, применив метод Clear:
listBox1.Items.Clear();
Доступ к элементам списка
Используя индекс элемента, можно сам элемент в списке. Например, получим первый
элемент списка:
string firstElement = listBox1.Items[0];
Метод Count позволяет определить количество элементов в списке:
int number = listBox1.Items.Count();
Выделение элементов списка
При выделении элементов списка мы можем ими управлять как через индекс, так и
через сам выделенный элемент. Получить выделенные элементы можно с помощью
следующих свойств элемента ListBox:
 SelectedIndex: возвращает или устанавливает номер выделенного элемента
списка. Если выделенные элементы отсутствуют, тогда свойство имеет значение -1
 SelectedIndices: возвращает или устанавливает коллекцию выделенных
элементов в виде набора их индексов
 SelectedItem: возвращает или устанавливает текст выделенного элемента
 SelectedItems: возвращает или устанавливает выделенные элементы в виде
коллекции
По умолчанию список поддерживает выделение одного элемента. Чтобы добавить
возможность выделения нескольких элементов, надо установить у его
свойства SelectionMode значение MultiSimple.
Чтобы выделить элемент програмно, надо применить метод SetSelected(int index, bool
value), где index - номер выделенного элемента. Если второй параметр - value имеет
значение true, то элемент по указанному индексу выделяется, если false, то выделение
наоборот скрывается:
listBox1.SetSelected(2, true); // будет выделен третий элемент
Чтобы снять выделение со всех выделенных элементов, используется
метод ClearSelected.
Событие SelectedIndexChanged возникает при изменении выделенного элемента
19. Winforms: как организовать передачу данных между двумя формами?
Напишите пример кода.

2.1 Изменение модификатора доступа

В Form2 Установить модификатор доступа для контрола/поля public
В любом месте Form1
Form2 f = new Form2();
f.ShowDialog();
this.textBox1.Text = f.textBox1.Text;

2.2 Использование открытого свойства/метода. Способ очень похож на первый

В классе Form2 определяем свойство (или метод)
public string Data
{
get
{
return textBox1.Text;
}
}

В любом месте Form1

Form2 f = new Form2();
f.ShowDialog();
this.textBox1.Text = f.Data;

20. RSDN – нотация оформления кода. Опишите базовые требования к

именованию: классов, полей, методов, свойств. Как модификаторы доступа
влияют на именование?
camelCase должен начинаться со строчной буквы, а первая буква каждого
последующего слова должна быть заглавной.
В PascalCase каждое слово начинается с заглавной буквы.
2) Не используйте малопонятные префиксы или суффиксы
3) Не используйте подчеркивание для отделения слов внутри идентификаторов, это
удлиняет идентификаторы и затрудняет чтение. Вместо этого используйте стиль
именования Кемел или Паскаль.
4) Старайтесь не использовать сокращения лишний раз.
5) Старайтесь делать имена идентификаторов как можно короче (но не в ущерб
читабельности). Главное, чтобы смысл идентификатора был понятен в используемом
контексте. Например, количество элементов коллекции лучше назвать Count, а не
CountOfElementsInMyCollection.
6) Когда придумываете название для нового, общедоступного (public) класса,
пространства имен или интерфейса, старайтесь не использовать имена, потенциально или
явно конфликтующие со стандартными идентификаторами. 7) Предпочтительно
использовать имена, которые ясно и четко описывают предназначение и/или смысл
сущности.
8) Старайтесь не использовать для разных сущностей имена, отличающиеся только
регистром букв.
9) Старайтесь использовать имена с простым написанием.
Сокращения. Не используйте аббревиатуры или неполные слова в идентификаторах,
если только они не являются общепринятыми. Например, пишите GetWindow, а не
GetWin. Если имеется идентификатор длиной менее трех букв, являющийся
сокращением, то его записывают заглавными буквами, например, System.IO,
System.Web.UI. Имена длиннее двух букв записывайте в стиле Паскаль или Кэмел,
например, Guid, Xml, xmlDocument.
Не используйте одно и то же имя для класса и пространства имен. Например, не
используйте класс Debug и пространство имен Debug.
Не используйте литеральные константы (магические числа, зашитые в код размеры
буферов, времена ожидания и тому подобное). Лучше определите константу (если вы
никогда не будете ее менять) или переменную только для чтения (если она может
измениться в будущих версиях вашего класса).
Классы и структуры.
Используйте существительное (одно или несколько прилагательных и существительное)
для имени класса. Используйте стиль Паскаль для регистра букв. Не используйте
специальных префиксов, поясняющих, что это класс. Например, FileStream, а не
CFileStream. В подходящих случаях используйте составные слова для производных
классов, где вторая часть слова поясняет базовый класс. К примеру, ApplicationException
– вполне подходящее название для класса, унаследованного от Exception, поскольку
ApplicationException является наследником класса Exception. Не стоит, однако
злоупотреблять этим «Если производный класс незначительно меняет свойства,
поведение или внешний вид базового, используйте составные слова. Если класс
значительно расширяет или меняет поведение базового, используйте новое
существительное, отражающее суть производного класса».
Используйте составное имя, когда класс принадлежит некоторой специфичной категории,
например FileStream, StringCollection, IntegrityException. Это относится к классам,
которые являются потоками (Stream), коллекциями (Collection, Queue, Stack),
ассоциативными контейнерами (Dictionary), исключениями (Exception).
Для базового класса, предназначенного не для прямого использования, а для
наследования, следует использовать суффикс Base. Например, CollectionBase. Такие
классы также необходимо делать абстрактными.
Коллекциям (реализующим интерфейс ICollection/IList) нужно давать имя в виде
Collection. Переменным же этих типов лучше давать имена, являющиеся множественным
числом от элемента. Например, коллекция кнопок должна иметь имя ButtonCollection, а
переменная buttons.
Интерфейсы.
Используйте описывающее существительное, прилагательное или одно, или несколько
прилагательных и существительное для идентификатора интерфейса. Например,
IComponent – это описывающее существительное, ICustomAttributeProvider – это
конкретизированное прилагательными существительное, а IPersistable – это
характеризующее прилагательное. Если интерфейс описывает поведение, а не объект, то
следует использовать суффикс –able. (Класс может клонироваться – ICloneable)
Используйте префикс I (заглавная i) для интерфейсов, чтобы уточнить, что тип является
интерфейсом. Старайтесь избегать интерфейсов с двумя I в начале, например,
IIdentifiable. Попробуйте подобрать синоним, например, IRecognizable. Для пары класс-
интерфейс, в которой класс является некоторой стандартной или эталонной реализацией
интерфейса, используйте одинаковые имена, отличающиеся только префиксом I для
интерфейса. Например, IConfigurationManager и ConfigurationManager, при этом
ConfigurationManager не должен быть абстрактным, в этом случае используйте суффикс
Base.
Перечисления.
Используйте стиль Паскаль для регистра букв в названии и значениях перечисления. Не
используйте суффикс Enum в названии типа, вместо этого используйте более конкретный
суффикс, например, Style, Type, Mode, State. Чтобы код легче читался, используйте
следующее правило: «Название перечисления + is + значение должно образовывать
простое предложение». Например: BorderStyle.Single (Border style is single,
ThreadState.Aborted --> Thread state is “aborted”.
Поля и методы.
Непубличные поля (private, protected и protected internal) именуются в стиле Кэмел и
начинаются с префикса _. Публичных полей быть не должно. Константные поля следует
именовать с использованием стиля Паскаль, без префиксов, вне зависимости от
модификаторов доступа. Статические поля именуются в зависимости от модификатора
доступа. Поля только для чтения, должны быть приватными и именоваться согласно
модификатору доступа. Используйте глаголы или комбинацию глагола и
существительных и прилагательных для имен методов. Используйте стиль Паскаль для
регистра букв (вне зависимости от области видимости метода). Если метод является
обработчиком события формы, то название метода отделяется от названия события
символом подчерка («_»). Например, ShowFilePathsMenuItem_CheckedChanged.
Свойства.
Параметры методов. Из имени и типа параметра должны быть понятны его назначение и
смысл. Используйте стиль Кэмел для регистра букв в имени параметра. Старайтесь
избегать указания типа в имени параметра. Имена параметров не должны совпадать с
именами членов класса. Это должно решаться префиксом «_» во всех полях.
Оформление. Используйте табуляцию в 4 пробела, а не пробелы для отступов.
Количество пробелов необходимо выставить в настройках IDE. Избегайте строк длинной
больше ширины экрана. Оставляйте запятую на предыдущей строке так же, как вы это
делаете в обычных языках (русском, например). Избегайте лишних скобок, обрамляющих
выражения целиком. Лишние скобки усложняют восприятие кода и увеличивают
возможность ошибки. Каждая инструкция должна начинаться с новой строки. Пустые
строки.
Одна пустая строка перед и после объявления поля, свойства, делегата, события, метода.
Если переменные в методе объявляются отдельным блоком, используйте одну пустую
строку между их объявлением и инструкцией, идущей за этим блоком. Используйте одну
пустую строку между логическими частями в методе. Например, условными блоками и
циклами. Перед комментариями внутри методов необходимо оставлять одну пустую
строку. Локальные переменные. Объявляйте переменные непосредственно перед их
использованием. Если необходимы счетчики в циклах, не отражающие реальных
объектов, традиционно называют i, j, k, l, m, n. Инициализируйте переменные при
объявлении, если это возможно. При объявлении с инициализацией используйте
ключевое слово var. Это же касается определений в инструкциях for, foreach, using.
Комментарии. Используйте xml-documentation-комментарии. Многострочные
комментарии не могут быть вложенными, поэтому их использование может создать
проблемы. Должны быть заполнены все поля xml-комментариев (summary, parameters,
return и т.д.) Для описания сути некоторого участка кода, пояснений к алгоритму и другой
важной информации используйте несколько подряд идущих однострочных комментариев
(//...). Отделяйте текст комментария одним пробелом «// Текст комментария.». В конце
обязательна точка.

21. Для чего нужны xml-комментарии? Как указать xml-комментарий: у класса, у

поля, у метода? Как xml-комментарии помогают при написании кода?
xml-комментарии – комментарии специального формата в исходном коде для
автодокументирования кода. Можете посмотреть комментарии и руководство к
библиотеке непосредственно в среде разработки. Вся необходимая информация будет
храниться в самой сборке.
ТЕГИ:
/*обяз*/
1. <exception cref="member">description</exception> //Ссылка на исключение,
которое доступно из текущей среды компиляции.
2. <returns>description</returns> //Описание возвращаемого значения.
3. <summary>description</summary> //Обычный комментарий
4. <param name="name">description</param> //Имя параметра метода.
/*можно понтануться и еще накинуть*/
5. <example>description</example> // Описание примера кода.
6. <see cref="member"/> //Ссылка на член или поле, которые доступны для вызова из
текущей среды компиляции.
И др…

22. Что такое цикломатическая сложность метода? Как её рассчитать? Что такое
цикломатическая сложность класса? Для чего нужно рассчитывать
цикломатическую сложность?
Цикломатическая сложность алгоритма (функции, метода) служит для определения
количества тестов — это количество линейно независимых маршрутов через
программный код.
Например, если исходный код не содержит никаких точек ветвления или циклов, то
сложность равна единице, поскольку есть только единственный маршрут через код. Если
код имеет единственный оператор if, содержащий простое условие, то существует два
пути через код: один если условие оператора if имеет значение true и один — если false
Цикломатическая сложность цикла = 1;
Цикломатическая сложность класса в свою очередь определяется суммой
цикломатических сложностей всех открытых методов класса.
23. Что такое юнит-тест? Что он проверяет? Какую структуру имеет юнит-тест?
Что такое Setup и Teardown? Что такое степень покрытия кода тестами? Как она
определяется?
Юнит-тестирование – тестирование минимальных модулей архитектуры, максимально
изолированных друг от друга. Минимальными модулями архитектуры как правило
являются классы. Условие изоляции тестируемого модуля от других необходимо для
того, чтобы в случае обнаружения ошибки быть уверенным, что ошибка возникла именно
в тестируемом модуле. В противном случае найти место возникновении ошибки будет
гораздо сложнее. Юнит-тестированию подлежит поведение класса, находящееся под
модификаторами доступа public или protected. Закрытая реализация класса (private)
напрямую тестированию не подвергается, только опосредованно через вызов открытых
методов класса.
Юнит-тестирование — тестирование одного выбранного блока/компонента в изоляции от
других компонентов системы. Как правило, подобными компонентами являются классы
или методы.
1. Создаются входные параметры — тестовые данные.
2. Подают тестовые данные на вход общедоступного метода тестируемого класса.
3. Сравнивают возвращаемое тестируемым методом значение с некоторым эталоном —
заранее известным результатом, который должен получиться при правильной работе
данного метода. Данный эталон определяется в ТЗ, спецификациях или другой проектной
документации. Если результат работы метода совпадает с эталоном — тест пройден. В
любом другом случае тест считается провальным.
Чтобы метод выполнялся перед запуском каждого теста в текущем тест, то данный
метод следует пометить атрибутом
[SetUp] – подготовка тестируемых объектов (создание объекта,присвоение ему
значения..)
Также есть атрибут, который позволяет запускать метод после каждого теста — это
[TearDown] - действия после теста (отключение от БД, удаление созданных в тесте
файлов и т.д.)
24. Что такое юнит-тест? Приведите пример позитивного юнит-теста? Пример на
языке Си++ или C#.
Юнит-тестирование – тестирование минимальных модулей архитектуры, максимально
изолированных друг от друга.
Позитивный тест – тест, в котором проверяется работа метода при корректных исходных
данных.
25. Что такое юнит-тест? Приведите пример негативного юнит-теста? Пример на
языке Си++ или C#.
Негативный тест – тест, в котором проверяется обработка методом заведомо
некорректных исходных данных.
26. Что такое сервер непрерывной интеграции? Какие задачи он выполняет?
Системы непрерывной интеграции позволяют выполнять автоматическую сборку
программы, её тестирование, а также сборку установочных пакетов или размещение веб-
сервиса на удаленном рабочем сервере.
Непрерывная интеграция — это методология разработки и набор практик, при которых
в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство
современных приложений разрабатываются с использованием различных платформ и
инструментов, то появляется необходимость в механизме интеграции и тестировании
вносимых изменений.
С технической точки зрения, цель CI — обеспечить последовательный и
автоматизированный способ сборки, упаковки и тестирования приложений.
Типичные задачи CI:

 Проверить, было ли обновление в коде

 Собрать билд
 Прогнать автотесты
 Развернуть приложение на тестовом стенде
 Прогнать на этом стенде GUI тесты (или тесты Postman-a)
 Оповестить всех заинтересованных по email о результатах сборки и
тестирования
27. Как автоматизировать сборку установщика приложения? Какие нюансы
необходимо учитывать при автоматизации сборки установщика?
Написать скрипт после отладки, в котором мы скопируем файлы, которые должны быть
в нашем архиве установщика, в случае лр – это файлы формата dll, exe, Json, послпе
запустить инно сетап, который сгенерирует сценарий. НЮАНСЫ С ПУТЯМИ. Все пути,
которые вы указываете в сценарии, должны быть относительными
Абсолютные пути означают, что путь к файлу привязан к вашей текущей структуре папок.
при запуске вашего сценария на другом компьютере, может возникнуть ошибка – так как
на другом компьютере может не существовать папкок и пр..

28. Методология Scrum: что такое резерв проекта (project backlog)? Как он
выглядит? Кто его составляет?
Scrum – гибкая методология разработки с акцентом на качество процессов. Суть
методологии сводится к тому, что создание продукта делится на определенные части.
Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания
заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени
важности и ценности для заказчика.
Резерв проекта (Product Backlog) – это список требований к функциональности
продукта (ПО), упорядоченный по степени важности и редактируемый всеми
участниками скрам-процесса.
Бэклог продукта (Product backlog) представляет собой упорядоченный по степени
важности список требований, предъявляемых к разрабатываемому продукту. Элементы
этого списка называются Пользовательскими историями (User story). Каждой истории
соответствует уникальный ID

29. Методология Scrum: что такое спринт? Что такое резерв спринта? Что такое
story points?
Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает
часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная
продолжительность спринта – 1-2 недели.
Спринт (Sprint) – это итерация в скрам, в ходе которой создается функциональный рост
программного обеспечения.
В конце каждого такого спринта необходимо проводить демонстрацию завершенного
куска.
Резерв Проекта (Project Backlog) — это список требований к функциональности
разрабатываемой системы, упорядоченный по степени их важности.
Резерв Спринта (Spring Backlog) — содержит функциональность, выбранную
владельцем проекта из резерва проекта.
Story Points (стори поинтc) – единица оценки сложности выполнения задачи.
(применяется, если проект состоит из 3+ спринтов).
30. Методология Scrum: что такое планировочный покер? Для чего проводится
планировочный покер? Когда он проводится?
Scrum Poker (скрам покэ) – быстрый и точная техника оценки при помощи колоды карт
с числами Фибоначчи (1,2,3,5,8,13). Задачи с оценкой 13 необходимо дробить на более
мелкие.

В колоде могут быть также специальные карты:

 знак вопроса (?), означающий неуверенность;

 бесконечность (∞), означающая, что обсуждаемая функция или
принципиально не может быть реализована, или слишком велика, чтобы присваивать ей
число;
Процедура проведения
Каждому участнику обсуждения выдаётся по колоде карт. Все колоды идентичны друг
другу.
 Ведущий (англ. Moderator), не участвующий в обсуждении, ведёт собрание.
 Менеджер продукта (англ. Product Manager) дает краткие обзоры каждому
из пунктов. Итог обсуждения записывается менеджером продукта.
 Участники выбирают по одной карте и кладут их рубашкой вверх, показывая
таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-
разному: они могут означать количество дней, наиболее подходящие дни или
относительные единицы сложности (англ. story points).
 Каждый участник называет свою карту и переворачивает её.
 Участникам с высокими и низкими оценками предоставляется возможность
высказаться и обосновать свою оценку.
 Процесс обсуждения продолжается до достижения консенсуса(согласия).
Голос участника, который, скорее всего, будет владеть разработкой, имеет больший вес
в «голосовании на основе консенсуса».

31. Методология Scrum: что такое Scrum-доска? Как с ней работать? Для чего
проводятся ежедневные митинги?
Scrum-доска — это инструмент открытой демонстрации состояния текущей работы
Scrum-доска состоит из трех колонок: «сделать» (to-do), «в процессе» (in progress),
«сделано» (done).
На Scrum-доске размещается весь объём Sprint Backlog, который команда выбрала на
Sprint Planning для реализации в текущем спринте. Обычно карточки бизнес-задач
располагаются на доске сверху вниз в порядке убывания приоритета (сверху — самые
важные, внизу — наименее важные).
Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание,
где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно
выполнить за спринт.
1. Проводится в одно и то же время;
2. Длится строго не более 15 минут. Решение проблем выносится за рамки
митинга и в составе лиц, непосредственно затронутых данным препятствием;
3. Все отвечают только на три вопроса, отвечают друг другу:

 Что я сделал вчера?

 Что я буду делать сегодня?
 Какие проблемы есть у меня и команды на пути к цели?

32. Методология Scrum: что такое Burndown Chart? Как он выглядит? Как и кем
он заполняется? Как анализировать Burndown Chart и какие выводы по нему
можно сделать для улучшения процесса разработки?

Диаграмма сгорания задач / Burndown Chart

Данный график - средство для отслеживания выполненных задач в спринте или во всём
проекте.

Синим на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую

и следует опираться.
Красным отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных баллов (в данном случае),
идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.

33. Методология Scrum: чем отличаются демонстрация и ретроспектива? Кто

участвует в каждом из этих собраний, и для чего они проводятся?
Финал каждого спринта — демонстрация готового продукта. Скрам-команда составляет
ревью, в котором описывает цели спринта, поставленные задачи и то, как они были
решены. Владелец продукта, заказчики и пользователи на основе ревью и демонстрации
принимают решение о том, что должно быть изменено в дальнейшем процессе
разработки.
На основе отзыва о продукте, полученного после демонстрации, проводится
ретроспектива. Ее основная цель — определить, как можно улучшить процесс разработки
на следующем спринте, чтобы избежать возникших проблем и работать более
эффективно. После того, как пути улучшения качества работы были определены, команда
может приступать к планированию следующего спринта.
Sprint Review Meeting
Участвуют все. Знаменуется значительным приростом функционала продукта.
Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review
= 2-х недельному спринту).
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как?
как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
34. В чем разница между каскадной и итерационной (гибкой) методологиями
управления проектами? Какие преимущества и недостатки у каждой методологии?
В каких проектах лучше использовать каскадную методологию, а в каких –
итерационную?
Разработку лучше разделить на этапы, например, по месяцу (итерационная разработка),
или по логическим этапам: макетирование, проектирование, реализация, тестирование и
т.д. (каскадная разработка).
Каскадная.
Достоинства:
1) полная и согласованная документация на каждом этапе, которая позволяет
безболезненно вводить в разработку новых участников. Помимо этого, большое
положительное влияние на проект оказывают изначально сформулированные и
неизменяемые требования;
2) легко определяются сроки и затраты на проект. Фактически на этапе планирования мы
определяем объём работы на каждом из этапов проекта, делим этот объём на
производительность команды, руководствуясь знаниями и получаем общие сроки и
затраты на проект.
Недостатки такой методологии:
1)в водопадной методологии переход от одного этапа к другому может быть осуществлён
только при полной корректности результатов предыдущего этапа. Как следствие,
затягивание любого из этапов проекта увеличивает сроки и бюджет разработки всей
системы;
2) Очень часто разработчикам приходится решать задачи, которые изначально не были
заложены в проект. Это может произойти просто из-за человеческого фактора, когда
уйдёт один из разработчиков, а на введение в проект другого придётся потратить
несколько незапланированных недель, а то и месяцев;
3) ошибки на каждом этапе разработки изначально являются критичными — это связано
с длительностью разработки проекта. Следует понимать, что заказчик увидит
работоспособную систему только на последних этапах разработки, поэтому любое
неверно понятое требование или ошибка в архитектуре или функциональности будет
найдена только после завершения работы над системой. Длительность разработки по
водопадной методологии может варьироваться от полугода до бесконечности,
соответственно по завершению разработки мы рискуем получить не тот проект, который
задумывал получить заказчик, а это может вылиться в незапланированную модернизацию
системы или выбрасывание всего проекта, как ненужного;
4) при работе на конкурентном поле по водопадной методологии мы не можем
гарантировать гибкое изменение требований и функционала программы, что изначально
снижает конкурентоспособность разрабатываемого продукта.
 Каскадная модель будет давать отличный результат только в проектах
с четко и заранее определенными требованиями и способами их
реализации.
 Требования известны, понятны и зафиксированы.
 Нет проблем с доступностью программистов нужной квалификации.
 В относительно небольших проектах.
Гибкая.
Достоинства:
• чёткое разделение ролей в команде
• короткие спринты работы позволяют быстрее получать обратную связь от владельцев
проекта и намного быстрее, чем в водопадной методологии, изменять продукт и
исправлять возникающие ошибки;
• кросс-функциональная команда разработки позволяет более устойчиво реагировать на
возникновение человеческого фактора (болезни, увольнения и т. д.);
Недостатки:
• как ни странно, очень часто говорят о чрезмерной трате времени на встречи, т. к.
разработчикам комфортнее работать без отрыва от процесса программирования;
• кросс-функциональная команда не всегда справляется со сложными задачами, т. к.
появляется необходимость в человеке с более высоким навыком работы с определённым
типом задач, заменить которого на другого члена команды не представляется возможным.
 Требования к конечной системе заранее четко определены и понятны.
 Проект большой или очень большой.
 Основная задача должна быть определена, но детали реализации могут
эволюционировать с течением времени.
35. Что такое система управления проектами? Для чего она нужна? Кто в ней
работает?
Система управления проектами – это совокупность инструментов,
обеспечивающих управление проектами и их эффективную реализацию.
— комплексное программное обеспечение, включающее в себя приложения для
планирования задач, составления расписания, контроля цены и управления бюджетом,
распределения ресурсов, совместной работы, общения, быстрого управления,
документирования и администрирования системы, которые используются совместно для
управления крупными проектами.
К основным функциям СУП, используемых при разработке ПО, можно отнести:
• Bug-tracking system — система отслеживания ошибок — прикладная программа,
разработанная с целью помочь разработчикам программного обеспечения учитывать и
контролировать ошибки и неполадки, найденные в программах.
• Интеграция с системами контроля версий.
• Система работы с документацией. В СУП обычно хранится вся созданная документация
по проектам, причем она постоянно обновляется, чтобы каждому пользователю в любой
момент времени была доступна актуальная информация по проекту.
• Система планирования заданий.
Данная система позволяет:
• отслеживать текущее состояние разработки, какие задачи уже сделаны, какие в
разработке и так далее;
• отслеживать временные затраты.
• следить за загруженностью разработчиков.