Варіант 2

Завдання І. Життєвий цикл інформаційної системи. Порівняння моделей життєвого циклу

Завдання ІІ. Бізнес-процеси складського підрозділу

Список використаної літератури

Завдання І. Життєвий цикл інформаційної системи. Порівняння моделей життєвого циклу

Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ).

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії й задачі, які повинні бути виконані під час створення ПЗ.

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

1. основні процеси ЖЦ ПЗ (придбання, поставка, розробка, експлуатація, супровід);

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

3. організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка й поліпшення самого ЖЦ, навчання).

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

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

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

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

У процесі реалізації проекту важливе місце займають питання ідентифікації, опису й контролю конфігурації окремих компонентів і всієї системи в цілому. Керування конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, насамперед процеси розробки й супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожний з яких може мати різновиди або версії, виникає проблема врахування їхніх зв'язків і функцій, створення уніфікованої структури й забезпечення розвитку всієї системи. Керування конфігурацією дозволяє організувати, систематично враховувати й контролювати внесення змін у ПЗ на всіх стадіях ЖЦ. Загальні принципи й рекомендації конфігураційного обліку, планування й керування конфігураціями ПЗ відбиті в стандарті ISO 12207-2.

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

ЖЦ ПЗ носить ітераційний характер : результати чергового етапу часто викликають зміни в проектних рішеннях, прийнятих на більш ранніх етапах.

Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання й взаємозв'язки процесів, дій і задач, виконуваних протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, у яких остання створюється й функціонує.

Регламенти ISO/IEC 12207 є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії й задачі, включені в ці процеси.

На сьогодні найбільше поширення одержали наступні дві основні моделі ЖЦ:

· каскадна модель (70-85 р.г.);

· спіральна модель (86-90 р.г.).

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

Рис. 1.1. Каскадна схема життєвого циклу ПЗ

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

Позитивні сторони застосування каскадного підходу полягають у наступному:

— на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;

— виконувані в логічній послідовності етапи робіт дозволяють планувати строки завершення всіх робіт і відповідні витрати.

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

Однак, у процесі використання цього підходу виявився ряд його недоліків, викликаних насамперед тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку тверду схему. У процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. У результаті реальний процес створення ПЗ приймав наступний вид (Рис.2).

Рис2. Реальний процес розробки ПЗ за каскадною схемою

Основним недоліком каскадного підходу є істотне запізнювання з одержанням результатів. Узгодження результатів з користувачами здійснюється тільки в точках, планованих після завершення кожного етапу робіт, вимоги до ІС "заморожені" у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена.

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

Для подолання перерахованих проблем була запропонована спіральна модель ЖЦ (Рис.3), що робить упор на початкові етапи ЖЦ: аналіз і проектування. На цих етапах реалізованість технічних рішень перевіряється шляхом створення прототипів. Кожний виток спирали відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі й характеристики проекту, визначається його якість і плануються роботи наступного витка спирали. У такий спосіб заглиблюються й послідовно конкретизуються деталі проекту й у результаті вибирається обґрунтований варіант, що доводиться до реалізації.

Рис.3. Спіральна модель ЖЦ

життєвий цикл інформаційна система

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

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

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є, що одержала в останній час широке поширення, є методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

— невелику команду програмістів (від 2 до 10 чоловік);

— короткий, але ретельно пророблений виробничий графік (від 2 до 6 мес.);

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

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

Життєвий цикл ПЗ за методологією RAD складається із чотирьох фаз:

· фаза аналізу й планування вимог;

· фаза проектування;

· фаза побудови;

· фаза впровадження.

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

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

Після детального визначення состава процесів оцінюється кількість функціональних елементів розроблювальної системи й приймається рішення про поділ ІС на підсистеми, що піддаються реалізації однією командою розроблювачів за прийнятний для RAD-проектів час - порядку 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

· загальна інформаційна модель системи;

· функціональні моделі системи в цілому й підсистем, реалізованих окремими командами розроблювачів;

· точно визначені за допомогою CASE-засобу інтерфейси між автономно розроблювальними підсистемами;

· побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

· визначається необхідність розподілу даних;

· здійснюється аналіз використання даних;

· здійснюється фізичне проектування бази даних;

· визначаються вимоги до апаратних ресурсів;

· визначаються способи збільшення продуктивності;

· завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім погодженим вимогам.

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

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

Наведена схема розробки ІС не є абсолютною. Можливі різні варіанти, що залежать, наприклад, від початкових умов, у яких ведеться розробка: розробляється зовсім нова система; уже було проведене обстеження підприємства й існує модель його діяльності; на підприємстві вже існує деяка ІС, що може бути використана як початковий прототип або повинна бути інтегрована з розроблювальною.

Треба, однак, відзначити, що методологія RAD, як і будь-яка інша, не може претендувати на універсальність, вона гарна в першу чергу для відносно невеликих проектів, розроблювальних для конкретного замовника. Якщо ж розробляється типова система, що не є закінченим продуктом, а являє собою комплекс типових компонентів, централізовано супроводжуваних, адаптованих до програмно-технічних платформ, СУБД, засобів телекомунікації, організаційно-економічних особливостей об'єктів впровадження та інтегрованих з існуючими розробками, на перший план виступають такі показники проекту, як керованість і якість, які можуть ввійти в суперечність із простотою й швидкістю розробки. Для таких проектів необхідний високий рівень планування й тверда дисципліна проектування, строга відповідність заздалегідь розробленим протоколам і інтерфейсам, що знижує швидкість розробки.

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

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

Оцінка розміру додатків здійснюється на основі так званих функціональних елементів (екрани, повідомлення, звіти, файли й т.п.) Подібна метрика не залежить від мови програмування, на якому ведеться розробка. Розмір додатка, що може бути виконаний за методологією RAD, для добре налагодженого середовища розробки ІС із максимальним повторним використанням програмних компонентів, визначається в такий спосіб:

Підсумовуючи викладене, перелічимо основні принципи методології RAD:

— розробка додатків ітераціями;

— необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

— обов'язкове залучення користувачів у процес розробки ІС;

— необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

— необхідне використання генераторів коду;

— використання прототипування, що дозволяє повніше з'ясувати й задовольнити потреби кінцевого користувача;

— тестування й розвиток проекту, здійснювані одночасно з розробкою;

— ведення розробки нечисленною добре керованою командою професіоналів;

— грамотне керівництво розробкою системи, чітке планування й контроль виконання робіт.

Завдання ІІ. Бізнес-процеси складського підрозділу

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

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

Рекомендовані дані: класифікатор матеріалів, матеріал, матеріально-відповідальні особи, підрозділи, прихід-витрата матеріалів.

Список використаної літератури

1. Вендров А.М. CASE-технологии. Современные средства и средства проектироания информационных систем. – М.: ФиС, 1998 . – 216 с.

2. Дубейковский В. И. Эффективное моделирование с AllFusion Process Modeler 4.1.4 и AllFusion PM. – М.: Диалог-МИФИ, 2007. – 384 с.

3. Маклаков С.В. BPwin и ERwin. CASE - средства разработки информационных систем. – М.: Диалог-МИФИ, 2007. – 256 с.

4. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: Диалог-МИФИ, 2005. – 432 с.

5. Свитинбенк Петер, Чессел Менди и др. Шаблоны: управляемая моделями разработка в среде IBM Rational Software Architect. – М.: Академия. 2006. – 215 с.

6. Чаадаев В.К. Бизнес-процессы в компаниях связи. – М.Диалог, 2006. – 176 с.