Труднощами керування процесом розробки;

Мета роботи:

Ø на основі апробованої методології вдосконалитиопис предметної області об’єкта дослідження для привести моделі «ЯК Є» до моделі «ЯК ПОВИННО БУТИ»;

Ø сформувати вимоги до інформаційної системи для заданого об’єкта.

Завдання:

1. На основі апробованої методології вдосконалити опис предметної області «Лікарські препарати» для привести моделі «ЯК Є» до моделі «ЯК ПОВИННО БУТИ», встановивши:

Ø призначення системи «Лікарські препарати»;

Ø склад підсистем;

Ø цілі системи і підсистем;

Ø модульну структуру всієї системи;

Ø основні інформаційні об'єкти «Лікарські препарати»;

Ø порядок занесення даних в БД;

Ø функціональні характеристики системи;

Ø дані, які надходять на вхід кожної з підсистем;

Ø зовнішні сутності кожної з підсистем;

Ø категорії користувачів системи і надані їм можливості;

Ø призначення підсистеми обробки запитів та визначення категорій користувачів;

Ø критерії функціонування системи.

2.Сформувати вимоги до інформаційної системи для заданого об’єкта щодо:

Ø функціональних характеристик;

Ø надійності;

Ø налаштованості ПЗ;

Ø умов експлуатації;

Ø складу і параметрів технічних засобів;

Ø інформаційної і програмної сумісності;

Ø програмної документації.

3.Розробити ескізи пропозицій у вигляді схем, нотацій, діаграм чи моделей щодо отриманих результатів в пп.1-2 Завдання.

Хід роботи

1. Вивчити та вдосконалити опис предметної області «Лікарські препарати» відповідно до індивідуального завдання на основі методології;

2. Сформувати вимоги до інформаційної системи для заданого об’єкта.

3. Оформити звіт з виконаної роботи.

Зміст

1. ВСТУП …………………………………………………………….……….4

2. Особливості розробки складних програмних продуктів……………..5

2.1 Складність розробки ПЗ ……………………………….……………………………5

3. Національні стандарти розробки складних програмних продуктів....7

4. Міжнародні стандарти розробки складних програмних продуктів…9

4.1 Еволюція …………………………………………………………………..…………10

5. СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ…………………………………...…11

6. ТЕСТОВІ ЗАВДАННЯ………………………………………………………………..12

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

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

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

2.Особливості розробки складних програмних продуктів.

Програ́мний проду́кт (англ. programming product) — це:

1. програмний засіб, програмне забезпечення, які призначені для постачання користувачеві (покупцеві, замовникові)

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

Розробка програмного забезпечення (англ. software engineering, Software development) - це рід діяльності (професія) і процес, спрямований на створення і підтримку працездатності, якості та надійності програмного забезпечення, використовуючи технології, методологію та практики з інформатики, управління проектами, математики, інженерії та інших областей знання.

2.1 Складність розробки ПЗ

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

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

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

Найбільш поширеними проблемами, що виникають в процесі розробки ПЗ, вважають:

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

Розробка програмних засобів для операційних систем Windows має ряд особливостей. Так, взаємодія програмного засобу з користувачем та з операційною системою здійснюється через відправлення та обробку повідомлень. Таку побудову обробки повідомлень в програмі назвали подією.

3.Національні стандарти розробки складних програмних продуктів.

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

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

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

На сьогодні існує комплекс стандартів, які регламентують різні аспекти життєвого циклу ПЗ. До їх розробки було залучено такі міжнародні організації, як IEEE (Інститут інженерів по електротехніці та електроніці), ISO (Міжнародна організація по стандартизації), EIA (Асоціація електронної промисловості), IEC (Міжнародна комісія по електротехніці), а також деякі національні дослідні інститути (ANSI, Американський національний інститут стандартів; SEI, Інститут програмної інженерії).

Американський національний інститут стандартів (англ. American National Standards Institute, ANSI) - об'єднання американських промислових і ділових груп, яке розробляє торговельні та комунікаційні стандарти. Входить до ISO і Міжнародну електротехнічну комісію, представляючи там свою країну.

Сформовано 19 жовтня 1918 як Американський комітет інженерних стандартів (AESC). Згодом - Американська асоціація стандартів (ASA, 1928), а після реорганізації в 1966 році - Інститут Стандартів США (USASI). Нинішнє ім'я прийнято в 1969 році. У ANSI представлені американські корпорації, урядові служби, міжнародні організації та приватні особи.

З прийнятих інститутом стандартів відомі:

ANSI X3.4 - 7-бітна кодування ASCII

ASA X3.9-1966 - мова Фортран-66

ANSI C - стандарт мови C

ANSI X3.64 (використовується так званої ANSI-графікою)

Всупереч поширеній помилці, ANSI не приймав стандарти 8-бітних кодових сторінок, хоча і брав участь у розробці кодування ISO-8859-1 і, можливо, деяких інших.

Для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості CMM, яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) США. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п'ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій – п'ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача.

4.Міжнародні стандарти розробки складних програмних продуктів.

4.1 Еволюція

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

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

Міжнародна організація по стандартизации (>ИСО) прийняла таке визначення:

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

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

Серед усіх стандартів у галузі розробки програмного забезпечення, що використовуються в даний час в світі, найбільш популярними моделями є: ISO 9001, TickIT(Велика Британія), SEI SW-CMM(США).

Стандарти ISO серії 9000

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

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

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

Стандарт TickIT

Досить широку популярність здобув британський стандарт TickIT. Цей галузевий стандарт регламентує вимоги до системи якості для організацій розробників програмного забезпечення і базується на моделі ISO 9001:94. На відміну від моделі ISO 9001, яка регламентує "що необхідно зробити", розробники даного стандарту спробували відповісти на питання "як" можна виконати вимоги, визначені в ISO 9001. TickIT об'єднує в собі модель ISO 9001 з набором рекомендаційних стандартів ISO 12207 та ISO 9000-3.

Стандарти SEI SW-CMM

Дуже цікавий підхід до поліпшення внутрішніх процесів розробки програмного забезпечення визначено у моделі SEI SW-CMM. В основу даної моделі (також як і в основу стандартів ISO серії 9000) покладена теорія TQM. Теорія TQM грунтується на поступовому поліпшенні внутрішніх виробничих процесів за рахунок безлічі невеликих впроваджуваних в компанії поліпшень. Однак, моделі ISO і CMM трохи різняться у своїх підходах до побудови самовдосконалюється систем управління якістю та поліпшення виробничих процесів.

На відміну від моделі ISO, де для того, щоб відповідати вимогам, необхідно продемонструвати 100%-ве відповідність моделі (і тільки воно дозволяє компанії самовдосконалюватися), в моделі SEI SW-CMM передбачено поетапний підхід до побудови системи вдосконалення процесів. Для досягнення цієї мети розробники стандарту СММ визначили п'ять рівнів, які повинна пройти організація для того, щоб досягти основної мети - підвищення ефективності функціонування процесів компанії і, як наслідок, поліпшення якості результатів виробничих процесів і розроблюваного програмного забезпечення.

Приклад

Розробники комп'ютерного програмного забезпечення, обслуговуючі певну нішу на ринку збуту, встановили. що при розширенні бази користувачів вони зіткнуться з питаннями, що стосуються менеджменту продукції та управління конфігурацією. Зміни в основної продукції, апаратних засобах користувачів і в регуляторних вимогах ускладнювали проблеми обслуговування споживачів. Стандарт ISO 9004:2000 дав необхідні рекомендації з розробки документованих процедур для управління змінами та поліпшенням процесу. Стандарти ISO 10006:1997 та ISO 10007:1995 забезпечили додаткову підтримку при менеджменті проектування і підготовки процедур з менеджменту конфігурації. Згодом вони набули іншого розробника програмного забезпечення і зуміли використати свою систему менеджменту якості для дуже швидкої інтеграції придбаної фірми у свою структуру з мінімальними перебоями для споживачів.

5. СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1. Методологія розробки та використання стандартів при створенні інформаційних систем (у рамках процесу розробки програмних продуктів) // Вісті. – 2005. – №34

2. Брой М. Информатика. Основополагающеее введение: в 4-х ч. Ч. 1./Пер. с нем. – М.: Диалог-МИФИ, 1996 – 299 с.

3. Іан Соммервіллем Інженерія програмного забезпечення = Software Engineering. — 6-е вид. — М.: «Вильямс», 2002. — С. 642.

4. Джек Грінфілд, Кіт Шорт, Стів Кук, Стюарт Кент, Джон Крупи Фабрики розробки програм (Software Factories): потокова збірка типових додатків, моделювання, структури та інструменти = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. — М.: «Діалектика», 2006. — С. 592

6.ТЕСТОВІ ЗАВДАННЯ

1.Програмний продукт це -?

1) Програмний засіб, програмне забезпечення, які призначені для постачання користувачеві (покупцеві, замовникові)

2) Програма, яку може запускати, тестувати, виправляти та змінювати будь-яка людина. Вона може використовуватись в різних операційних системах та з різними наборами даних.

3) Це програмне забезпечення, на яке зберігаються як немайнові, так і майнові авторські права

4) Процес, спрямований на створення та підтримку працездатності, якості та надійності програмного забезпечення

5) Множина взаємопов'язаних елементів,

2.Розробка програмного забезпечення це -?

1) Рід діяльності та процес, спрямований на створення та підтримку працездатності, якості та надійності програмного забезпечення

2) Це програмне забезпечення, на яке зберігаються як немайнові, так і майнові авторські права

3) Програмне забезпечення з відкритим сирцевим кодом

4) Сукупність ресурсів інформаційних технологій, що надають послуги на одному чи більшому числі інтерфейсів

5) Використання всіх можливих і неможливих способів для підтримки життя в старезній і, що розпадається на частині системі

3. Найчастіші проблеми при розробці ПЗ, вважають:

1) Брак прозорості

2) Недолік контролю

3) Недолік трасування.

4) Труднощами керування процесом розробки;

5) Необхідністю забезпечити достатню гнучкість програми;

4.Інформаційна система це -?

1) Сукупність ресурсів інформаційних технологій, що надають послуги на одному чи більшому числі інтерфейсів

2) Це програмне забезпечення, на яке зберігаються як немайнові, так і майнові авторські права

3) Множина взаємопов'язаних елементів, що взаємодіє з середовищем, як єдине ціле і відокремлена від нього.

4) Науковий метод пізнання, що являє собою послідовність дій з установлення структурних зв'язків між змінними або елементами досліджуваної системи

5) Напрям методології досліджень, який полягає в дослідженні об'єкта як цілісної множини елементів в сукупності відношень і зв'язків між ними

5. Основні причини складності програмного забезпечення:

1) Складністю реальної предметної області, з якої виходить замовлення на розробку;

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