- •Харків 2012
- •1 Визначення життєвого циклу та створення структури декомпозиції робіт іт-проекту
- •1.3 Опис програмного продукту, необхідного для виконання лабораторної роботи
- •1.4 Порядок виконання роботи та методичні вказівки з її виконання
- •1.5 Зміст звіту
- •2 Створення структури декомпозиції ресурсів іт-проекту
- •2.3 Опис програмного продукту, необхідного для виконання лабораторної роботи
- •2.4 Порядок виконання роботи та методичні вказівки з її виконання
- •2.5 Зміст звіту
- •3 Визначення операцій та виконавців проекту
- •3.3 Опис програмного продукту, необхідного для виконання лабораторної роботи
- •3.4 Порядок виконання роботи та методичні вказівки з її виконання
- •3.5 Зміст звіту
- •4 Розробка та оптимізація плану іт-проекту
- •4.3 Опис програмного продукту, що використовується для виконання лабораторної роботи
- •4.4 Порядок виконання роботи та методичні вказівки з її виконання
- •5 Групова розробка програмного забезпечення за допомогою системи контролю версій sourcejammer
- •5.4 Порядок виконання роботи та методичні вказівки з її виконання
- •5.5 Зміст звіту
- •Навчальне видання
- •61166 Харків, просп. Леніна, 14
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. Розробка чи адаптація програм. |