Процес керування розробкою програмного забезпечення
Лабораторна робота № 2
«Розробка опису й аналіз інформаційної системи (ІС)»
1. Мета роботи:
Описати й проаналізувати інформаційну систему, розподілити ролі в групі розроблювачів.
2. Методичні вказівки
Лабораторна робота спрямована на ознайомлення із процесом опису інформаційної системи й одержання навичок по використанню основних методів аналізу ІС.
Вимоги до результатів виконання лабораторного практикуму:
1. наявність опису інформаційної системи;
2. проведення аналізу здійсненності виконання проекту;
3.наявність висновку про можливість реалізації проекту, що містить рекомендації щодо розробки системи, базові пропозиції за обсягом необхідного бюджету, кількості розроблювачів, часу й необхідному програмному забезпеченню.
3. Теоретичні відомості
Загальні відомості про розробку програмного забезпечення (ПЗ)
Проблеми керування програмними проектами вперше виявилися в 60-х - початку 70-х років, коли провалилися багато великих проектів по розробці програмних продуктів. Були зафіксовані затримки в створенні ПЗ, воно було ненадійним, витрати на розробку в кілька разів перевершували первісні оцінки, створені програмні системи часто мали низькі показники продуктивності. Причини провалів коренилися в тих підходах, які використовувалися в керуванні проектами. Застосовувана методика була заснована на досвіді керування технічними проектами й виявилася неефективною при розробці програмного забезпечення.
Важливо розуміти різницю між професійною розробкою ПЗ й аматорським програмуванням. Необхідність керування програмними проектами випливає з того факту, що процес створення професійного ПЗ завжди є суб'єктом бюджетної політики організації, де воно розробляється, і має часові обмеження. Робота керівника програмного проекту по великому рахункові полягає в тому, щоб гарантувати виконання цих бюджетних і часових обмежень із урахуванням бізнес- цілей організації щодо розроблювального ПЗ.
Керівники проектів повинні спланувати всі етапи розробки програмного продукту. Вони також повинні контролювати хід виконання робіт і дотримання всіх необхідних стандартів. Постійний контроль над ходом виконання робіт необхідний для того, щоб процес розробки не виходив за часові й бюджетні обмеження. Гарне керування не гарантує успішного завершення проекту, але погане керування обов'язкове приведе до його провалу. Це може виразитися в затримці строків здачі готового ПЗ, у перевищенню кошторисної вартості проекту й у невідповідності готового ПЗ специфікації вимог.
Процес розробки ПЗ суттєво відрізняється від процесів реалізації технічних проектів, що породжує певні складності в керуванні програмними проектами:
1. Програмний продукт нематеріальний. Програмне забезпечення нематеріально, його не можна побачити або поторкати. Керівник програмного проекту не бачить процес "росту" розроблювального ПЗ. Він може покладатися тільки на документацію, яка фіксує процес розробки програмного продукту.
2. Не існує стандартних процесів розробки ПЗ. На сьогоднішній день не існує чіткої залежності між процесом створення ПЗ й типом створюваного програмного продукту. Інші технічні дисципліни мають тривалу історію, процеси розробки технічних виробів багаторазово випробувані й перевірені. Процеси створення більшості технічних систем добре вивчені. Вивченням же процесів створення ПЗ фахівці займаються тільки останнім часом. Тому поки не можна точно передбачити, на якому етапі процесу розробки ПО можуть виникнути проблеми, що загрожують усьому програмному проекту.
3. Великі програмні проекти - це часто "одноразові" проекти. Великі програмні проекти, як правило, значно відрізняються від проектів, реалізованих раніше. Тому, щоб зменшити невизначеність у плануванні проекту, керівники проектів повинні мати дуже великий практичний досвід. Але постійні технологічні зміни в комп'ютерній техніці й комунікаційному устаткуванні знецінюють попередній досвід. Знання й навички, накопичені досвідом, можуть не затребуватися в новому проекті.
Перераховані відмінності можуть привести до того, що реалізація проекту вийде з часового графіка або перевищить бюджетні асигнування. Програмні системи найчастіше виявляються новинками як в "ідеологічному", так і в технічному плані. Тому, передбачаючи можливі проблеми в реалізації програмного проекту, слід завжди пам'ятати, що багатьом з них властиво виходити за рамки часових і бюджетних обмежень.
Процес керування розробкою програмного забезпечення
Неможливо описати й стандартизувати всі роботи, виконувані в проекті по створенню ПЗ. Ці роботи досить суттєво залежать від організації, де виконується розробка ПЗ, і від типу створюваного програмного продукту. Але завжди можна виділити наступні:
· Написання пропозицій по створенню ПЗ.
· Планування й складання графіка робіт зі створення ПЗ.
· Оцінювання вартості проекту.
· Добір персоналу.
· Контроль над ходом виконання робіт.
· Написання звітів і представлень.
Перша стадія програмного проекту може складатися з написання пропозицій по реалізації цього проекту. Пропозиції повинні містити опис цілей проектів і способів їх досягнення. Вони також звичайно містять у собі оцінки фінансових і часових витрат на виконання проекту. При необхідності тут можуть приводитися обґрунтування для передачі проекту на виконання сторонньої організації або команді розроблювачів.
Написання пропозицій — дуже відповідальна робота, тому що для багатьох організацій питання про те, чи буде проект виконуватися самою організацією або розроблятися за контрактом сторонньою компанією, є критичним. Не існує яких-небудь рекомендацій з написання пропозицій, багато чого тут залежить від досвіду.
На етапі планування проекту визначаються процеси, етапи й отримані на кожному з них результати, які повинні привести до виконання проекту. Реалізація цього плану приведе до досягнення цілей проекту. Визначення вартості проекту прямо пов'язане з його плануванням, оскільки тут оцінюються ресурси, що вимагаються для виконання плану.
Контроль над ходом виконання робіт (моніторинг проекту) — це безперервний процес, що триває протягом усього строку реалізації проекту. Керівник повинен постійно відслідковувати хід реалізації проекту й порівнювати фактичні й планові показники виконання робіт з їхньою вартістю. Хоча багато організацій мають механізми формального моніторингу робіт, досвідчений керівник може скласти ясну картину про стадію розвитку проекту просто шляхом неформального спілкування з розроблювачами.
Неформальний моніторинг часто допомагає виявити потенційні проблеми, які в явному виді можуть виявитися пізніше. Наприклад, щоденне обговорення ходу виконання робіт може виявити окремі недоробки в створюваному програмному продукті. Замість очікування звітів, у яких буде відбитий факт "пробуксовки" графіка робіт, можна обговорити з фахівцями намічені програмістські проблеми й не допустити зриву графіка робіт.
Протягом реалізації проекту звичайно відбувається кілька формальних контрольних перевірок ходу виконання робіт зі створення ПЗ. Такі перевірки повинні дати загальну картину ходу реалізації проекту в цілому й показати, наскільки вже розроблена частина ПЗ відповідає цілям проекту.
Тривалість виконання великих програмних проектів може сягати кілька років. Протягом цього часу цілі й наміри організації, що замовила програмний проект, можуть суттєво змінитися. Може виявитися, що розроблювальний програмний продукт став уже непотрібним або вихідні вимоги до створюваного ПЗ просто застаріли і їх необхідно кардинально міняти. У такій ситуації керівництво організації-розроблювача може ухвалити рішення щодо припинення розробки ПЗ або про зміну проекту в цілому для того, щоб урахувати змінені цілі й наміри організації-замовника.
Керівники проектів звичайно зобов'язані самі підбирати виконавців для своїх проектів. В ідеальному випадку професійний рівень виконавців повинен відповідати тій роботі, яку вони будуть виконувати в ході реалізації проекту. Однак у багатьох випадках керівники повинні покладатися на команду розроблювачів, яка далека від ідеальної.
Така ситуація може бути викликана наступними причинами:
1.Бюджет проекту не дозволяє залучити висококваліфікований персонал. У такому випадку за меншу плату залучаються менш кваліфіковані фахівці.
2. Бувають ситуації, коли неможливо знайти фахівців необхідної кваліфікації як у самій організації-розроблювача, так і поза неї. Наприклад, в організації "кращі люди" можуть бути вже зайняті в інших проектах.
3.Організація прагне підвищити професійний рівень своїх працівників. У цьому випадку вона може залучити до участі в проекті недосвідчених або недостатньо кваліфікованих працівників, щоб вони отримали необхідний досвід і повчилися у більш досвідчених фахівців.
Таким чином, майже завжди добір фахівців для виконання проекту має певні обмеження й не є вільним. Разом з тим необхідно, щоб хоча б кілька членів групи розроблювачів мали кваліфікацію й досвід, які достатні для роботи над даним проектом. В іншому випадку неможливо уникнути помилок у розробці ПЗ.
Керівник проекту звичайно зобов'язаний посилати звіти про хід його виконання як замовнику, так і підрядним організаціям. Це повинні бути короткі документи, засновані на інформації, що випливає з докладних' звітів про проект. У цих звітах повинна бути та інформація, яка дозволяє чітко оцінити ступінь готовності створюваного програмного продукту.
У рамках дисципліни «Реінжиніринг інформаційних систем» виділені наступні ролі в групі по розробці ПЗ для ІС :
· Керівник – загальне керівництво проектом, написання документації, спілкування із замовником ПЗ
· Системний аналітик – розробка вимог (складання технічного завдання, проекту програмного забезпечення)
· Тестер – складання плану тестування й атестації готового ПЗ (продукту), складання сценарію тестування, базовий приклад, проведення заходів щодо плану тестування
· Розроблювач – моделювання компонент програмного забезпечення, кодування
Планування проекту розробки програмного забезпечення
Ефективне управління програмним проектом прямо залежить від правильного планування робіт, необхідних для його виконання. План допомагає керівникові передбачити проблеми, які можуть виникнути на яких-небудь етапах створення ПЗ, і розробити превентивні заходи для їхнього попередження або рішенні. План, розроблений на початковому етапі проекту, розглядається всіма його учасниками як керівний документ, виконання якого повинне привести до успішного завершення проекту. Цей первісний план повинен максимально докладно описувати всі етапи реалізації проекту.
Процес планування починається, виходячи з опису системи, з визначення проектних обмежень (часові обмеження, можливості наявного персоналу, бюджетні обмеження і т.д.). Ці обмеження повинні визначатися паралельно з оцінюванням проектних параметрів, таких як структура й розмір проекту, а також розподілом функцій серед виконавців. Потім визначаються етапи розробки й те, які результати документація, прототипи, підсистеми або версії програмного продукту) повинні бути отримані по закінченню цих етапів. Далі починається циклічна частина планування. Спочатку розробляється графік робіт з виконання проекту або дається дозвіл на продовження використання раніше створеного графіка. Після цього проводиться контроль виконання робіт і відзначаються розбіжності між реальним і плановим ходом робіт.
Далі, у міру отримання нової інформації про хід виконання проекту, можливий перегляд первісних оцінок параметрів проекту. Це, у свою чергу, може привести до зміни графіка робіт. Якщо в результаті цих змін порушуються строки завершення проекту, повинні бути переглянуті (і погоджені із замовником ПЗ) проектні обмеження.
Звичайно, більшість керівників проектів не думають, що реалізація їх проектів пройде гладко, без усяких проблем. Бажано описати можливі проблеми ще до того, як вони виявлять себе в ході виконання проекту. Тому краще встановити "песимістичні" графіки робіт, ніж "оптимістичні". Але, звичайно, неможливо побудувати план, що враховує всі, у тому числі випадкові, проблеми й затримки виконання проекту, тому й виникає необхідність періодичного перегляду проектних обмежень і етапів створення програмного продукту.
План проекту повинен чітко показати ресурси, які необхідні для реалізації проекту, поділ робіт на етапи й часовий графік виконання цих етапів. У деяких організаціях план проекту складається як єдиний документ, що містить усі види планів, описаних вище. В інших випадках план проекту описує тільки технологічний процес створення ПЗ. У такому плані обов'язково присутні посилання на плани інших видів, але вони розробляються окремо від плану проекту.
Деталізація планів проектів дуже відрізняється в залежності від типу розроблювального програмного продукту й організації-розроблювача. Але в кожному разі більшість планів містить наступні розділи.
1. Уведення. Короткий опис цілей проекту й проектних обмежень (бюджетних, часових і т.д.), які є важливими для керування проектом.
2. Організація виконання проекту. Опис способу добору команди розроблювачів і розподіл обов'язків між членами команди.
3. Аналіз ризиків. Опис можливих проектних ризиків, імовірності їх прояву й стратегій, спрямованих на їхнє зменшення.
4. Апаратні й програмні ресурси, необхідні для реалізації проекту. Перелік апаратних засобів і програмного забезпечення, необхідного для розробки програмного продукту. Якщо апаратні засоби потрібно закуповувати, приводиться їхня вартість разом із графіком закупівлі й поставки.
5. Розбивка робіт на етапи. Процес реалізації проекту розбивається на окремі процеси, визначаються етапи виконання проекту, приводиться опис результатів ("виходів") кожного етапу й контрольні оцінки.
6. Графік робіт. У цьому графіку відображаються залежності між окремими процесами (етапами) розробки ПЗ, оцінки часу їх виконання й розподіл членів команди розроблювачів по окремих етапах.
7. Механізми моніторингу й контролю над ходом виконання проекту. Описуються надавані керівником звіти про хід виконання робіт, строки їх надання, а також механізми моніторингу всього проекту.
План повинен регулярно переглядатися в процесі реалізації проекту. Одні частини плану, наприклад графік робіт, змінюються часто, інші більш стабільні. Для внесення змін у план потрібна спеціальна організація документообігу, що дозволяє відслідковувати ці зміни.
Загальні відомості про вимоги до інформаційних систем
Проблеми, які доводиться вирішувати фахівцям у процесі створення програмного забезпечення, дуже складні. Природа цих проблем не завжди ясна, особливо якщо розроблювальна програмна система інноваційна. Зокрема, важко чітко описати ті дії, які повинна виконувати система.
Опис функціональних можливостей і обмежень, що накладаються на систему, називається вимогами до цієї системи, а сам процес формування, аналізу, документування й перевірки цих функціональних можливостей і обмежень – розробкою вимог.
Вимоги підрозділяються на користувацькі й системні. Користувацькі вимоги – це опис природньою мовою (плюс діаграми, що пояснюють) функцій, виконуваних системою, і обмежень, що накладаються на неї. Системні вимоги – це опис особливостей системи (архітектура системи, вимоги до параметрів устаткування і т.д.), необхідних для ефективної реалізації вимог користувача.
Перші кроки по розробці вимог до інформаційних систем - аналіз здійсненності
Розробка вимог — це процес, що включає заходи, необхідні для створення й затвердження документа, що містить специфікацію системних вимог. Для нових програмних систем процес розробки вимог повинен починатися з аналізу здійсненності. Початком такого аналізу є загальний опис системи і її призначення, а результатом аналізу — звіт, у якому повинна бути чітка рекомендація, продовжувати чи ні процес розробки вимог проектованої системи. Інакше кажучи, аналіз здійсненності повинен освітити наступні питання.
1. Чи відповідає система загальним і бізнес-цілям організації-замовника й організації-розроблювача?
2. Чи можна реалізувати систему, використовуючи існуючі на даний момент технології й не виходячи за межі заданої вартості?
3. Чи можна об'єднати систему з іншими системами, які вже експлуатуються?
Критичним є питання, чи буде система відповідати цілям організації. Якщо система не відповідає цим цілям, вона не представляє ніякої цінності для організації. У той же час багато організацій розробляють системи, що не відповідають їхнім цілям, або не зовсім ясно розуміючи ці цілі, або під впливом політичних або суспільних факторів.
Виконання аналізу здійсненності включає збір і аналіз інформації про майбутню систему й написання відповідного звіту. Спочатку слід визначити, яка саме інформація необхідна, щоб відповісти на поставлені вище питання. Наприклад, цю інформацію можна одержати, відповівши на наступне:
1. Що відбудеться з організацією, якщо система не буде введена в експлуатацію?
2. Які поточні проблеми існують в організації і як нова система допоможе їх розв'язати?
3. Яким чином система буде сприяти цілям бізнесу?
4. Чи вимагає розробка системи технології, яка до цього не використовувалася в організації?
Далі необхідно визначити джерела інформації. Це можуть бути менеджери відділів, де система буде використовуватися, розроблювачі програмного забезпечення, знайомі з типом майбутньої системи, технологи, кінцеві користувачі і т.д.
Після обробки зібраної інформації готується звіт по аналізі здійсненності створення системи. У ньому повинні бути дані рекомендації щодо продовження розробки системи. Можуть бути запропоновані зміни бюджету й графіка робіт зі створення системи або пред'явлені більш високі вимоги до системи.
Порядок виконання роботи
1. Вивчити пропонований теоретичний матеріал.
2. Скласти докладний опис інформаційної системи.
3. На підставі опису системи провести аналіз здійсненності. У ході аналізу відповісти на запитання:
· Що відбудеться з організацією, якщо система не буде введена в експлуатацію?
· Які поточні проблеми існують в організації і як нова система допоможе їх розв'язати?
· Яким образом система буде сприяти цілям бізнесу?
· чи Вимагає розробка системи технології, яка до цього не використовувалася в організації?
Результатом аналізу повинне з'явитися висновок про можливість реалізації проекту.
4. Розподілити ролі в групі (керівник проекту-розроблювач, системний аналітик-розроблювач, тестер-розроблювач).
5. Заповнити розділи плану:
· Введення
· Організація виконання проекту
· Аналіз ризиків
Розділи повинні містити рекомендації щодо розробки системи, базові пропозиції за обсягом необхідного бюджету, числу розроблювачів, часу й необхідному програмному забезпеченню.
6. Скласти звіт щодо проробленої роботи.
5. Зміст звіту
У звіті слід указати:
1. Мета роботи
2. Вступ. Короткий опис цілей проекту й проектних обмежень (бюджетних, часових і т.д.), які важливі для керування проектом
3. Опис інформаційної системи (ПЗ) - наявність висновку про можливість реалізації проекту, що містить рекомендації щодо розробки системи, базові пропозиції за обсягом необхідного бюджету, кількості розроблювачів, часу й необхідному програмному забезпеченню
4. Аналіз здійсненності ( згідно з вимогами до результатів виконання лабораторного практикуму п.2), указати можливі проблеми й шляхи їх подолання.
5. Ролі учасників групи розробки ПЗ.
6. Програмно-апаратні засоби, використовувані при виконанні роботи.
7. Висновок (висновки)
8. Список використовуваної літератури
Зразок оформлення титульного аркуша наведений у Додатку.
6. Література
1. Соммервиль Иан. Инженерия программного обеспечения, 6-е издание. : Пер. с англ. – М.: Издательский дом “Вильямс”, 2002. – 624 с.
2. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. – СПб.:Питер, 2002. – 496 с.
3. Константайн Л., Локвуд Л. Разработка программного обеспечения. – СПб.:Питер, 2004. – 592 с.
4. Иванова Г.С. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.
Додаток
МІНІСТЕРСТВО ОСВІТИ Й НАУКИ УКРАЇНИ
КИЇВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
Імені Вадима ГЕТЬМАНА
Факультет інформаційних систем і технологій
Кафедра інформаційних систем в економіці
Дисципліна «Реінжиніринг комп’ютерних систем»
Звіт по лабораторній роботі № 2
«РОЗРОБКА ОПИСУ Й АНАЛІЗ ІНФОРМАЦІЙНОЇ СИСТЕМИ»
Виконали студенти 3-го курсу
групи
Перевірив доцент Городній О.В.
Київ – 2016
Лабораторна робота №2
«Розробка опису й аналіз інформаційної системи»
Мета роботи:
Описати й проаналізувати інформаційну систему, розподілити ролі в групі розроблювачів.
Вступ.
Короткий опис цілей проекту й проектних обмежень (бюджетних, часових і т.д.), які важливі для керування проектом
……….(1-2стор.)
Опис інформаційної системи
наявність висновку про можливість реалізації проекту, що містить рекомендації щодо розробки системи, базові пропозиції за обсягом необхідного бюджету, кількості розроблювачів, часу й необхідному програмному забезпеченню
……….(2-4стор.)
Аналіз здійсненності
( згідно з вимогами до результатів виконання лабораторного практикуму п.2), указати можливі проблеми й шляхи їх рішення.
…………(3-5стор.)
Ролі учасників групи розробки ПО
………..(1стор.)
Програмно-апаратні засоби, використовувані при виконанні роботи.
………(1 стор.)
Висновок (висновки)
…….(1стор.)
Список використовуваної літератури
…….(1 стор.)