Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Процес керування розробкою програмного забезпечення






 

Неможливо описати й стандартизувати всі роботи, виконувані в проекті по створенню ПЗ. Ці роботи досить суттєво залежать від організації, де виконується розробка ПЗ, і від типу створюваного програмного продукту. Але завжди можна виділити наступні:

 

· Написання пропозицій по створенню ПЗ.

· Планування й складання графіка робіт зі створення ПЗ.

· Оцінювання вартості проекту.

· Добір персоналу.

· Контроль над ходом виконання робіт.

· Написання звітів і представлень.

 

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

 

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

 

На етапі планування проекту визначаються процеси, етапи й отримані на кожному з них результати, які повинні привести до виконання проекту. Реалізація цього плану приведе до досягнення цілей проекту. Визначення вартості проекту прямо пов'язане з його плануванням, оскільки тут оцінюються ресурси, що вимагаються для виконання плану.

 

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

 

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

 

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

 

Тривалість виконання великих програмних проектів може сягати кілька років. Протягом цього часу цілі й наміри організації, що замовила програмний проект, можуть суттєво змінитися. Може виявитися, що розроблювальний програмний продукт став уже непотрібним або вихідні вимоги до створюваного ПЗ просто застаріли і їх необхідно кардинально міняти. У такій ситуації керівництво організації-розроблювача може ухвалити рішення щодо припинення розробки ПЗ або про зміну проекту в цілому для того, щоб урахувати змінені цілі й наміри організації-замовника.

 

Керівники проектів звичайно зобов'язані самі підбирати виконавців для своїх проектів. В ідеальному випадку професійний рівень виконавців повинен відповідати тій роботі, яку вони будуть виконувати в ході реалізації проекту. Однак у багатьох випадках керівники повинні покладатися на команду розроблювачів, яка далека від ідеальної.

Така ситуація може бути викликана наступними причинами:

 

1.Бюджет проекту не дозволяє залучити висококваліфікований персонал. У такому випадку за меншу плату залучаються менш кваліфіковані фахівці.

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

3.Організація прагне підвищити професійний рівень своїх працівників. У цьому випадку вона може залучити до участі в проекті недосвідчених або недостатньо кваліфікованих працівників, щоб вони отримали необхідний досвід і повчилися у більш досвідчених фахівців.

 

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

 

Керівник проекту звичайно зобов'язаний посилати звіти про хід його виконання як замовнику, так і підрядним організаціям. Це повинні бути короткі документи, засновані на інформації, що випливає з докладних' звітів про проект. У цих звітах повинна бути та інформація, яка дозволяє чітко оцінити ступінь готовності створюваного програмного продукту.

 

У рамках дисципліни «Реінжиніринг інформаційних систем» виділені наступні ролі в групі по розробці ПЗ для ІС:

 

· Керівник – загальне керівництво проектом, написання документації, спілкування із замовником ПЗ

· Системний аналітик – розробка вимог (складання технічного завдання, проекту програмного забезпечення)

· Тестер – складання плану тестування й атестації готового ПЗ (продукту), складання сценарію тестування, базовий приклад, проведення заходів щодо плану тестування

· Розроблювач – моделювання компонент програмного забезпечення, кодування

 

 

Планування проекту розробки програмного забезпечення

 

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

 

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

Далі, у міру отримання нової інформації про хід виконання проекту, можливий перегляд первісних оцінок параметрів проекту. Це, у свою чергу, може привести до зміни графіка робіт. Якщо в результаті цих змін порушуються строки завершення проекту, повинні бути переглянуті (і погоджені із замовником ПЗ) проектні обмеження.

Звичайно, більшість керівників проектів не думають, що реалізація їх проектів пройде гладко, без усяких проблем. Бажано описати можливі проблеми ще до того, як вони виявлять себе в ході виконання проекту. Тому краще встановити " песимістичні" графіки робіт, ніж " оптимістичні". Але, звичайно, неможливо побудувати план, що враховує всі, у тому числі випадкові, проблеми й затримки виконання проекту, тому й виникає необхідність періодичного перегляду проектних обмежень і етапів створення програмного продукту.

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

Деталізація планів проектів дуже відрізняється в залежності від типу розроблювального програмного продукту й організації-розроблювача. Але в кожному разі більшість планів містить наступні розділи.

 

1. Уведення. Короткий опис цілей проекту й проектних обмежень (бюджетних, часових і т.д.), які є важливими для керування проектом.

2. Організація виконання проекту. Опис способу добору команди розроблювачів і розподіл обов'язків між членами команди.

3. Аналіз ризиків. Опис можливих проектних ризиків, імовірності їх прояву й стратегій, спрямованих на їхнє зменшення.

4. Апаратні й програмні ресурси, необхідні для реалізації проекту. Перелік апаратних засобів і програмного забезпечення, необхідного для розробки програмного продукту. Якщо апаратні засоби потрібно закуповувати, приводиться їхня вартість разом із графіком закупівлі й поставки.

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

6. Графік робіт. У цьому графіку відображаються залежності між окремими процесами (етапами) розробки ПЗ, оцінки часу їх виконання й розподіл членів команди розроблювачів по окремих етапах.

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

 

План повинен регулярно переглядатися в процесі реалізації проекту. Одні частини плану, наприклад графік робіт, змінюються часто, інші більш стабільні. Для внесення змін у план потрібна спеціальна організація документообігу, що дозволяє відслідковувати ці зміни.

 

Загальні відомості про вимоги до інформаційних систем

 

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

 

Опис функціональних можливостей і обмежень, що накладаються на систему, називається вимогами до цієї системи, а сам процес формування, аналізу, документування й перевірки цих функціональних можливостей і обмежень – розробкою вимог.

 

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

 

Перші кроки по розробці вимог до інформаційних систем - аналіз здійсненності

 

Розробка вимог — це процес, що включає заходи, необхідні для створення й затвердження документа, що містить специфікацію системних вимог. Для нових програмних систем процес розробки вимог повинен починатися з аналізу здійсненності. Початком такого аналізу є загальний опис системи і її призначення, а результатом аналізу — звіт, у якому повинна бути чітка рекомендація, продовжувати чи ні процес розробки вимог проектованої системи. Інакше кажучи, аналіз здійсненності повинен освітити наступні питання.

 

1. Чи відповідає система загальним і бізнес-цілям організації-замовника й організації-розроблювача?

2. Чи можна реалізувати систему, використовуючи існуючі на даний момент технології й не виходячи за межі заданої вартості?

3. Чи можна об'єднати систему з іншими системами, які вже експлуатуються?

 

Критичним є питання, чи буде система відповідати цілям організації. Якщо система не відповідає цим цілям, вона не представляє ніякої цінності для організації. У той же час багато організацій розробляють системи, що не відповідають їхнім цілям, або не зовсім ясно розуміючи ці цілі, або під впливом політичних або суспільних факторів.

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

 

1. Що відбудеться з організацією, якщо система не буде введена в експлуатацію?

2. Які поточні проблеми існують в організації і як нова система допоможе їх розв'язати?

3. Яким чином система буде сприяти цілям бізнесу?

4. Чи вимагає розробка системи технології, яка до цього не використовувалася в організації?

 

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

 

Після обробки зібраної інформації готується звіт по аналізі здійсненності створення системи. У ньому повинні бути дані рекомендації щодо продовження розробки системи. Можуть бути запропоновані зміни бюджету й графіка робіт зі створення системи або пред'явлені більш високі вимоги до системи.

 

 


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.013 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал