Варіант 2
Завдання І. Життєвий цикл інформаційної системи. Порівняннямоделей життєвого циклу
Завдання ІІ. Бізнес-процеси складського підрозділу
Список використаної літератури
Завдання І. Життєвий цикл інформаційної системи. Порівняннямоделей життєвого циклу
Одним з базових понять методології проектування ІС є поняттяжиттєвого циклу її програмного забезпечення (ЖЦ ПЗ).
ЖЦ ПЗ — це безперервний процес, що починається змоменту ухвалення рішення про необхідність його створення й закінчується вмомент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, єміжнародний стандарт ISO/IEC 12207 [5] (ISO — International Organization ofStandardization — Міжнародна організація по стандартизації, IEC — InternationalElectrotechnical 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, для добре налагодженогосередовища розробки ІС із максимальним повторним використанням програмнихкомпонентів, визначається в такий спосіб:
функціональних елементів одна людина
1000-4000 функціональних елементів одна команда розроблювачів
> 4000 функціональних елементів 4000 функціональних елементів на одну команду розроблювачів
Підсумовуючи викладене, перелічимо основні принципиметодології RAD:
— розробка додатків ітераціями;
— необов'язковість повного завершення робіт на кожному з етапівжиттєвого циклу;
— обов'язкове залучення користувачів у процес розробки ІС;
— необхідне застосування CASE-засобів, що забезпечують цілісністьпроекту;
— застосування засобів керування конфігурацією, що полегшуютьвнесення змін у проект і супровід готової системи;
— необхідне використання генераторів коду;
— використання прототипування, що дозволяє повніше з'ясувати йзадовольнити потреби кінцевого користувача;
— тестування й розвиток проекту, здійснювані одночасно з розробкою;
— ведення розробки нечисленною добре керованою командоюпрофесіоналів;
— грамотне керівництво розробкою системи, чітке планування йконтроль виконання робіт.
Завдання ІІ. Бізнес-процеси складського підрозділу
Основнізадачі, які вирішує підрозділ. Облік надходження й руху матеріалів унатуральному (не грошовому) вираженні.
Описпредметної області. Є класифікатор матеріалів. Матеріли надходять насклад. Потім, за певними документами, видаються матеріально-відповідальним особам,які закріплені за структурними підрозділами. Комірник повинен забезпечитисхоронність матеріалів і вірогідно знати залишки, кому й коли були виданіматеріали. Крім того, важливі різноманітні звіти.
Рекомендованідані: класифікатор матеріалів, матеріал, матеріально-відповідальні особи,підрозділи, прихід-витрата матеріалів.