5.4 Порядок виконання роботи та методичні вказівки з її виконання

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

Отримані результати необхідно оформити у вигляді звіту з лабораторної роботи та надати викладачеві у вигляді роздруківки.

Під час виконання лабораторної роботи необхідно вибрати або створити деякий програмний проект. Проект має містити більше ніж один файл з текстом програми та мати у своїй структурі підкаталоги. Необхідно додати проект до SourceJammer-архіву, провести його вдосконалення. В процесі праці над програмним продуктом необхідно використовувати систему контролю версій.

Для виконання роботи необхідно здійснити такі дії:

1. Отримати ім’я користувача та пароль для доступу до серверу SourceJammer у викладача.

2. Створити архів на сервері та призначити йому ім’я sourceXX, де XX – номер вашої бригади.

3. Створити трьох користувачів (UserXX_1, UserXX_2, UserXX_3, де XX – номер вашої бригади) та надати їм привілеї: контролера архіву, користувача архіву, а останньому користувачеві залишити звичайні привілеї.

4. Створити програму, використовуючи будь-яку мову програмування. Програма повинна виводити повідомлення.

5. Визначити, які файли в вашому програмному проекті є первинними (тексти програм), а які вторинними (відкомпільовані програми).

6. Додати первинні файли створеного програмного продукту до SourceJammer-архіву.

7. Створити підкаталог в архіві та зробіть так, щоб один з файлів програми відображався в цей каталог, проте зберігав зв’язок з оригіналом.

8. Виконати зміни у файлі, що знаходиться у підкаталозі, у встановленому порядку (позначення файла як недосяжного для модифікації, внесення змін, позначення файла як вільного для модифікації).

9. Переконатися, що зміни відбулися і у тому файлі, що знаходиться в вищому каталозі.

10. Створити гілку-копію файла в підкаталозі. Виконайте пункти 8-9. Визначте, що змінилося після виконання цих кроків. Зробіть відповідні висновки.

11. Спробувати підключитися до архіву як користувач, який має повноваження користувача архіву (для підключення іншого користувача необхідно спочатку відключитися від архіву, а тільки потім виконати підключення).

12. Позначити файли, які ви будете змінювати, та доопрацюйте версію програми (додайте функцію створення ще одного повідомлення).

13. Проаналізувати атрибути файлів, які позначені в системі SourceJammer як недосяжні для модифікації іншими користувачами, та файлів, які вільні для модифікації.

14. Позначити файли як вільні для модифікації.

15. Переконатися в тому, що зміни відбулися на сервері, та визначте версію кожного файла, що є на сервері.

16. Зробити так, щоб активною версією файлів в архіві на сервері (одного з тих, що мають більше ніж одну версію) стала перша версія. Зробити висновок про те що відбулося.

17. Спробувати підключитися до архіву як користувач, який має привілеї контролера архіву.

18. Повторити виконання пункту 15. Зробити висновки про те, що відбулося.

19. Зробити висновки про принципи роботи з різними версіями при виконанні розробки програмних продуктів.

20. Спробувати підключитися до архіву як користувач, який має привілеї звичайного користувача.

21. Призначити локальний каталог для архіву.

22. Отримати останні версії всього архіву.

23. Позначити один з файлів як недосяжний для модифікації.

24. Зробити висновки про принципи розподілу привілеїв в системі контролю версій SourceJammer.

25. Проаналізувати конфігураційні файли системи SourceJammer. Визначити, яка інформація там знаходиться. Зробити відповідні висновки.

5.5 Зміст звіту

Звіт звиконання лабораторної роботи має містити:

1. Назву лабораторної роботи.

2. Мету лабораторної роботи.

3. Текстовий короткий опис виконання роботи та отриманих результатів відповідно до наведених у розділі 5.4 пунктів.

4. Висновки з роботи.

5.6 Контрольні запитання і завдання

1. Що таке система контролю версій ?

2. Назвіть основне призначення систем контролю версій. Які переваги ці системи надають команді розробників ?

3. Які системи контролю версій ви знаєте ?

4. Опишіть принципи, за якими працюють системи контролю версій.

5. Назвіть переваги системи SourceJammer серед інших аналогічних продуктів.

6. Назвіть основні признаки класифікації систем контролю версій.

7. Скільки рівнів доступу до системи SourceJammer існує ? Яка між ними різниця ?

8. Які основні операції може виконувати система контролю версій SourceJammer над об’єктами, що в ній знаходяться ?

ПЕРЕЛІК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ

1. Шафер Д.Ф., Фатрелл Р.Т., Шафер Л.И. Управление программными проектами: достижение оптимального качества при минимуме затрат. – М.: Издательский дом „Вильямс”, 2003. – 1136 с.

2. Стовер Т. Эффективная работа: Microsoft Project 2002. – СПб.: Питер, 2004. – 843 с.

3. Ройс У. Управление проектами по созданию программного обеспечения. – М .: издательство «ЛОРИ», 2002. – 426 с.

4. Кантор М. Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения. – М.: Издательский дом «Вильямс», 2002. – 176 с.

5. Мазур И.И., Шапиро В.Д., Каролинский И.М., Ольдерогге Н.Г. и др. Управление проектами: справочник для профессионалов. – М.: Высшая школа, 2001. – 875 с.

6. Адаир Дж. Эффективная мотивация. – М.: издательство «Эксмо», 2003 – 256 с.

7. Бек К. Экстремальное программирование. Разработка через тестирование. – СПб.: Питер, 2003. – 224 с.

8. Крамаренко В.І., Холод Б.І., Нагорська М.М., Логвіна Б.І. Управління персоналом фірми. – К.: ЦУЛ, 2003 – 272 с.

ДОДАТОК А

ПРИКЛАД АНКЕТ ДЛЯ ВИБОРУ МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ ПРОЕКТУ СТВОРЕННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ

Таблица А.1 - Выбор модели жизненного цикла на основе характеристик требований

Требования	Каскад-ная	V-образная	Прото-типирование	Спираль-ная	Инкре-ментная
Являются ли тре-бования легко определимыми и/или хорошо известными?	Да	Да	Нет	Нет	Нет
Могут ли требования заранее определятся в цикле?	Да	Да	Нет	Нет	Да
Часто ли будут изменятся требования в цикле?	Нет	Нет	Да	Да	Нет
Нужно ли демонстрировать требования с целью определения?	Нет	Нет	Да	Да	Нет
Требуется ли демонстрация возможностей проверка концепции?	Нет	Нет	Да	Да	Нет
Будут ли требования отражать сложность системы?	Нет	Нет	Да	Да	Да
Обладает ли требование функциональными свойствами на раннем этапе?	Нет	Нет	Да	Да	Да

Таблица А.2 - Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта	Каскад-ная	V-образная	Прото-тип.	Спираль-ная	Инкре-мент.
Являются ли проблемы предметной области проекта новыми для большинства разработчиков?	Нет	Нет	Да	Да	Нет
Является ли технология предметной области проекта новой для большинства разработчиков?	Да	Да	Нет	Да	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков?	Да	Да	Нет	Да	Нет
Изменяются ли роли участников проекта во время жизненного цикла?	Нет	Нет	Да	Да	Да
Могут ли разработчики проекта пройти обучение?	Нет	Да	Нет	Нет	Да
Является ли структура более значимой для разработчиков, чем гибкость?	Да	Да	Нет	Нет	Да
Будет ли менеджер проекта строго отслеживать прогресс команды?	Да	Да	Нет	Да	Да
Важна ли легкость распределения ресурсов?	Да	Да	Нет	Нет	Да
Приемлет ли команда равноправные обзоры и инспекции заказчиков, а также стадии?	Да	Да	Да	Да	Да

Табл. А.3 - Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив пользователей	Каскад-ная	V-образная	Прото-тип.	Спираль-ная	Инкре-мент.
Будет ли присутствие пользователей ограничено в жизненном цикле?	Да	Да	Нет	Да	Да
Будут ли пользователи знакомы с определением системы?	Нет	Нет	Да	Да	Да
Будут ли пользователи ознакомлены с проблемами предметной области?	Нет	Нет	Да	Нет	Да
Будут ли пользователи вовлечены во все фазы жизненного цикла?	Нет	Нет	Да	Нет	Нет
Будет ли заказчик отслеживать ход выполнения проекта?	Нет	Нет	Да	Да	Нет

Табл. А.4 - Выбор модели жизненного цикла на основе характеристик типа проектов и рисков.

Требования	Каскад-ная	V-образная	Прото-тип.	Спираль-ная	Инкре-мент.
Будет ли проект идентифицировать новое направление продукта для организации?	Нет	Нет	Да	Да	Да
Будет ли проект иметь тип системной интеграции?	Нет	Да	Да	Да	Да
Будет ли проект являться расширением существующей системы?	Нет	Да	Нет	Нет	Да
Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла?	Да	Да	Да	Нет	Нет
Ожидается ли длительная эксплуатация продукта в организации?	Да	Да	Нет	Да	Да
Должна ли быть высокая степень надежности?	Нет	Да	Нет	Да	Да
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения?	Нет	Нет	Да	Да	Да
Является ли график ограниченным?	Нет	Нет	Да	Да	Да
Являются ли «прозрачными» интерфейсные модули?	Да	Да	Нет	Нет	Да
Доступно ли повторное использование компоненты?	Нет	Нет	Да	Да	Нет
Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)	Нет	Нет	Да	Да	Нет

ДОДАТОК Б

Таблиця Б.1 – Опис стадій та етапів створення автоматизованої системи

Стадії	Етапи робіт
1	2
1. Формування вимог до автоматизованої системи (АС).	1.1. Обслідування об’єкту та обґрунтування необхідності створення АС. 1.2. Формування вимог користувача до АС. 1.3. Оформлення звіту про виконану роботу та заявки на розробку АС (тактико-технічного завдання)
2. Розробка концепції АС.	2.1. Вивчення об’єкту. 2.2. Проведення необхідних науково-дослідницьких робіт. 2.3. Розробка варіантів концепції АС, що вдовольняють вимогам користувача. 2.4. Оформлення звіту про виконану роботу.
3. Технічне завдання.	Розробка та затвердження технічного завдання на створення АС.
4. Ескізний проект.	4.1. Розробка попередніх проектних рішень по системі та її частинам. 4.2. Розробка документації на АС та її частини.
5. Технічний проект.	5.1. Розробка проектних рішень по системі та її частинам. 5.2. Розробка документації на АС та її частини. 5.3. Розробка й оформлення документації на постачання виробів для комплектування АС та (або) технічних вимог (технічних завдань) на їх розробку. 5.4. Розробка завдань на проектування в суміжних частинах проекту об’єкту автоматизації.
6. Робоча документація.	6.1. Розробка робочої документації на систему та її частини. 6.2. Розробка чи адаптація програм.