Курсова робота
Методологія і технологія розробки інформаційних систем
Зміст
Введення
Глава 1. Основні поняття
1.1 Інформаційні системи
1.2 Методології розробки інформаційних систем
Глава 2. Методологія розробки інформаційних систем
2.1 Методології розробки інформаційних систем у вітчизняній літературі
2.2 Методології розробки інформаційних систем в зарубіжній літературі
Глава 3. Технологія розробки інформаційних систем
Глава 4. Державні та міжнародні стандарти в області розробки програмного забезпечення
4.1 Міжнародний стандарт ISO / IEC 12207: 1995-08-01
4.2 Стандарти комплексу ГОСТ 1934
4.3 Стандарти комплексу ГОСТ 19
Практична частина
Висновок
Список використаних джерел
Введення
Науково-технічна революція, широко розгорнулася в другій половині XX століття, породила надії на те, що за допомогою нових наукових дисциплін і нової техніки будуть дозволені важкі проблеми і протиріччя людського життя. Автоматизація та створення інформаційних систем є на даний момент однією з найбільш ресурсномістких галузей діяльності техногенного суспільства. Однією з причин активного розвитку даної галузі є те, що автоматизація служить основою докорінної зміни процесів, що грають важливу роль в діяльності людини і суспільства. Існує багато видів інформаційних систем: системи обробки даних, інформаційні системи управління, маркетингові системи, системи бухгалтерського обліку та інші, які використовуються в різних організаціях.
Величезна кількість видів інформаційних систем спричинило велику кількість методологій і технологій їх створення. У цій роботі ми спробуємо виділити та класифікувати основні методології та технології розробки інформаційних систем.
Мета даної курсової роботи - вивчити теоретичний матеріал з тематики курсової роботи та розробити фрагмент інформаційної системи "Навчально-методичний ресурс".
Для досягнення цієї мети були поставлені наступні завдання:
проаналізувати джерела літератури з теми курсової роботи;
розкрити такі поняття: "Інформаційна система", "Методологія розробки інформаційних систем", "Технологія розробки інформаційних систем";
класифікувати методології розробки програмного забезпечення по вітчизняних і зарубіжних джерел;
розглянути і вивчити державні та міжнародні стандарти в області розробки програмного забезпечення;
розробити фрагмент інформаційної системи "Навчально-методичний ресурс".
Структура курсової роботи: робота складається зі вступу, чотирьох розділів, висновків, списку літератури, що включає в себе 31 джерело та чотирьох додатків.
Перша глава присвячена вивченню основних понять, таких як "Інформаційна система", "Методологія розробки інформаційних систем".
У другому розділі класифікуються методології розробки програмного забезпечення по вітчизняних і зарубіжних джерел.
У третьому розділі вивчається поняття "Технологія розробки інформаційних систем" і класифікуються технології розробки програмного забезпечення за вітчизняними джерелами.
У четвертому розділі розглядаються і вивчаються державні та міжнародні стандарти в області розробки програмного забезпечення.
У практичній частині розглянутий процес створення фрагмента інформаційної системи "Навчально-методичний ресурс".
Глава 1. Основні поняття
1.1 Інформаційні системи
В даний час немає єдиного трактування поняття "інформаційна система" (ІС), усталеної класифікації інформаційних систем, загальноприйнятого уявлення про структуру ІС, оскільки роботи по створенню інформаційних систем проводилися паралельно за кількома напрямками - системи обробки даних і бази даних; автоматизовані системи управління і в першу чергу - автоматизовані інформаційні системи; автоматизовані системи науково-технічної інформації; автоматизовані системи нормативно-правової документації, автоматизовані системи нормативно-методичного забезпечення управління підприємствами; а останнім часом розробляються різноманітні системи спеціального призначення, такі як економічні інформаційні системи, в тому числі бухгалтерські , банківські інформаційні системи, інформаційні системи ринку цінних паперів, маркетингові інформаційні системи і т.п.
Сам термін "інформаційні системи" включає два важливих поняття - "інформація" і "система".
Інформація (лат. information - повідомлення, роз'яснення; лат. Informo - надаю вигляд, формую, організую) - відомості про осіб, предмети, факти, події, явища і процеси незалежно від форми їх подання.
Система (грец. system - ціле, складене з частин з'єднання) - це сукупність елементів, що утворюють певну цілісність, єдність і взаємодіють один з одним для досягнення певної мети. [, C .16]
З точки зору інформатики інформаційні системи забезпечують збір, зберігання, обробку, пошук, надання інформації, необхідної в процесі прийняття рішень завдань з будь-якої області. Вони допомагають аналізувати проблеми і створювати нові продукти. Інформаційна система включає в себе ряд блоків, які особливим чином взаємодіють один з одним і об'єднані в структуру. У загальному вигляді структуру ІС можна представити наступним чином (рис.1):
Рис.1. Структура ІС
Інформаційна система - являє собою сукупність організаційних, технічних, програмних і інформаційних засобів, об'єднаних в єдину систему з метою збирання, зберігання, обробки та видачі необхідної інформації для виконання заданих функцій.
Сучасне розуміння інформаційної системи передбачає використання в якості основного технічного засобу переробки інформації персонального комп'ютера. Крім того, технічне втілення інформаційної системи саме по собі нічого не буде означати, якщо не врахована роль людини, для якого призначена вироблена інформація і без якого неможливо її отримання та подання.
У Федеральному законі "Про інформацію, інформатизації і захисту інформації" дається таке визначення:
"Інформаційна система - організаційно впорядкована сукупність документів (масивів документів) та інформаційних технологій, у тому числі і з використанням засобів обчислювальної техніки і зв'язку, що реалізують інформаційні процеси". [ ]
Інформаційна система в програмуванні - це прикладна програмна підсистема, орієнтована на збір, зберігання, пошук і обробку текстової та / або фактографічної інформації, що працює в режимі діалогу з користувачем. [ , C .15]
У залежності від предметної області інформаційні системи можуть дуже сильно відрізнятися за своїми функціями, архітектурі, реалізації. Проте можна виділити ряд властивостей, які є загальними:
інформаційні системи призначені для збору, зберігання і обробки інформації. Тому в основі будь-якої з них лежить середовище зберігання і доступу до даних;
інформаційні системи орієнтуються на кінцевого користувача, не володіє високою кваліфікацією і області застосування обчислювальної техніки. Тому клієнтські додатки інформаційних систем повинні володіти простим, зручним, легко освоюваним інтерфейсом, який надає кінцевому користувачеві всі необхідні для роботи функції, але в той же час не дають йому можливість виконувати будь-які зайві дії.
1.2 Методології розробки інформаційних систем
Будь-яка теоретична або практична сфера діяльності використовує властиві тільки їй способи вирішення поставлених завдань. Ці способи називаються методами. Метод - це спосіб досягнення якої-небудь мети, рішення конкретної задачі; сукупність прийомів або операцій практичного або теоретичного освоєння дійсності. [, C .450]
Методологія - сукупність методів, що застосовуються в якій-небудь області людської діяльності. [, C .217]
Надалі будемо розуміти методологію як сукупність методів, що застосовуються в життєвому циклі і об'єднаних загальним філософським підходом.
Методологія науки дає характеристику компонентів наукового дослідження - його об'єкта, предмета аналізу, завдання дослідження, сукупності дослідницьких засобів, необхідних для вирішення завдання даного типу, а також формує уявлення про послідовність руху дослідника в процесі вирішення завдання. [, C.56]
Методологія створення інформаційних систем полягає в організації процесу побудови інформаційної системи і забезпечення управління цим процесом для того, щоб гарантувати виконання вимог як до самої системи, так і до характеристик процесу розробки.
Основними завданнями, рішення яких повинна забезпечувати методологія створення інформаційних систем, є наступні:
забезпечення створення інформаційних систем, що відповідають цілям і завданням підприємства і відповідних пропонованим до них вимогам;
гарантія створення системи з заданими параметрами протягом заданого часу в рамках обумовленого заздалегідь бюджету;
простота супроводу, модифікації та розширення системи з метою забезпечення її відповідності умов, що змінюються роботи підприємства;
забезпечення створення інформаційних систем, що відповідають вимогам відкритості, переносимості та масштабованості;
можливість використання в створюваній системі розроблених раніше коштів інформаційних технологій (програмного забезпечення, баз даних, засобів обчислювальної техніки, телекомунікацій).
На сьогоднішній день існує не так багато методологій, особливо повних, тобто враховують всі стадії життєвого циклу програмного забезпечення. Саме методологія визначає, які мови та системи будуть застосовуватися для розробки програмного забезпечення і, багато в чому, рекомендує, який технологічний підхід буде при цьому використано.
Глава 2. Методологія розробки інформаційних систем
2.1 Методології розробки інформаційних систем у вітчизняній літературі
Аналізуючи вітчизняну літературу на цю тему, ми наведемо класифікацію методологій, взяту з книги Одинцова І.О. "Професійне програмування. Системний підхід"
Методології створення інформаційних систем можна класифікувати по декількох відмітним ознаками. (Рис.2)
Класифікація за ядрам методологій
Існує деякий ядро методології зі своїми методами, яке уточнюється деякими додатковими особливостями. Цей підхід нагадує принцип словотворення в російській мові - є корінь, до якого додаються приставки, суфікси і закінчення, уточнюючі зміст слова.
Ядра методологій визначаються способом опису алгоритмів. До основних ядрам методологій відносять:
методологія імперативного програмування;
методологія об'єктно-орієнтованого програмування;
методологія функціонального програмування;
методологія логічного програмування;
методологія програмування в обмеженнях.
Розглянемо ядра методологій докладніше.
Методологія імперативного програмування - підхід, що характеризується принципом послідовної зміни стану обчислювача покроковим чином. Імперативне програмування - це історично перша підтримувана апаратно методологія програмування. Вона орієнтована на класичну фон неймановскую модель, що залишалася довгий час єдиною апаратної архітектурою, що отримала широкої практичне застосування.
Методи і концепції.
Метод зміни станів полягає в послідовному зміну станів. Метод підтримується концепцією алгоритму
Метод управління потоком виконання полягає в покроковому контролі управління. Метод підтримується концепцією потоку виконання.
Методологія об'єктно-орієнтованого програмування - це підхід, який використовує об'єктну декомпозицію, при якій статична структура системи описується в термінах об'єктів і зв'язків між ними, а поведінка системи описується в термінах обміну повідомленнями між об'єктами. На виникнення об'єктного мислення вплинули моделювання та представлення даних, графічні інтерфейси та системне програмування (з поняттям "процес"). Дослідження в області хешування реальних систем призвели до необхідності створення засобів опису сутностей, що зустрічаються у них: об'єктів і подій. Пізніше виявилося, що такі концепції, як інкапсуляція (абстрактні типи даних), успадкування і поліморфізм є досить корисним доповненням до традиційного структурному програмуванню. Можливість їх достатньо ефективної реалізації привела до створення широко поширених в наші дні об'єктно-орієнтованих мов.
Методи і концепції.
Метод об'єктно-орієнтованої декомпозиції полягає у виділенні об'єктів і зв'язків між ними. Метод підтримується концепціями інкапсуляції, успадкування та поліморфізму.
Метод абстрактних типів даних лежить в основі інкапсуляції. Метод підтримується концепцією абстрагування.
Метод пересилки повідомлень полягає в описі поведінки системи в термінах обміну повідомленнями між об'єктами. Метод підтримується концепцією повідомлення.
Методологія функціонального програмування - спосіб складання програм, в яких єдиним дією є виклик функції, єдиним способом розчленування програми на частини - введення імені для функції і завдання для цього імені виразу, що обчислює значення функції, а єдиним правилом композиції - оператор суперпозиції функції. Функціональна методологія є однією з найстаріших. За походженням вона тісно пов'язана з лямбда-обчисленням, винайденим ще на початку 30-х років XX століття логіком Алонзо Черчен. Ця методологія використовується теоретиками програмування і є засобом лабораторних досліджень штучного інтелекту. [, C .80]
Методи і концепції.
Метод аплікативного полягає в тому, що програма є вираз, поставлене із застосування функцій до аргументів. Програма складається із сукупності визначень функцій, представляють собою виклики інших функцій і вкладених один в одного. Метод підтримується концепцією функції.
Метод рекурсивного поведінки полягає в самоповторяющийся поведінці, що повертається до самого себе. Метод підтримується концепцією рекурсії.
Метод настроюваності полягає в тому, що можна легко породжувати нові програмні об'єкти за зразком, як значення відповідних виразів (застосування породжує функції до параметрів зразка). Цьому сприяє те, що не тільки програма, але і будь-який програмний об'єкт (в ідеалі) є виразом.
Методологія логічного програмування - підхід, згідно з яким програма містить опис проблеми в термінах фактів і логічних формул, а вирішення проблеми система виконує за допомогою механізмів логічного висновку. Логічне програмування починає свій відлік часу з кінця 60-х років XX століття, коли Корделл Грін запропонував використовувати резолюцію як основу логічного програмування. Алан Колмеро створив мову логічного програмування Prolog в 1971 році. Логічне програмування пережило пік популярності в середині 80-х років XX століття, коли воно було покладено в основу проекту розробки програмного і апаратного забезпечення обчислювальних систем п'ятого покоління.
Методи і концепції.
Метод однаковості полягає в однаковому застосуванні механізму логічного доведення до всієї програми.
Метод уніфікації - це механізм зіставлення зі зразком для створення і декомпозиції структур даних.
Методологія програмування в обмеженнях - це підхід, при якому в програмі визначається тип даних рішення, предметна область рішення та обмеження на значення шуканого розв'язку. Рішення знаходиться системою. Методологія пропонує дворівневу архітектуру, інтегруючу компонент обмеження і програмний компонент. Компонент обмежень забезпечує основні операції і складається з системи висновків на фундаментальних властивостях системи обмежень. Операції, що оточують компонент обмежень, реалізуються програмно-мовним компонентом. Методологія виникла на початку 80-х років XX століття як перспективна область досліджень на стику символьних обчислень, штучного інтелекту, дослідження операцій і інтервальної арифметики.
Методи і концепції.
Метод описової моделі обчислень полягає в тому, що програма на мові програмування містить опис понять і завдань. Метод підтримується концепцією моделі.
Класифікація за топологічної специфіці методологій
Топологічна специфіка (топологія) методологій визначається як спосіб вибору методів для отримання уточненого ядра методології. Критерієм якості топологій є кількість загальних витрат на розробку програмного забезпечення. Витрати визначаються сукупністю численних факторів, у тому числі пов'язаних з абстракціями даних, управління та модульності. Наприклад, до гарної топології призводить відмова від використання глобальних даних та оператора безумовного переходу (за винятком особливого ряду випадків), сильна зв'язність модулів і їх слабке зчеплення.
Методологія структурного імперативного програмування - підхід, що полягає в завданні хорошою топології імперативних програм, орієнтованої на скорочення кількості загальних витрат на розробку програмного забезпечення. Скорочення буде мати місце і в результаті того, що і проектні моделі, і програмний код будуть мати хорошу структурованість, що дозволяє уникнути багатьох помилок. У випадку даної методології хорошу топологію задають відмова від використання глобальних даних і, в більшості випадків, оператора безумовного переходу, розробка модулів з сильною зв'язністю і забезпечення їх незалежності від інших модулів. Підхід базується на двох основні принципи побудови: послідовна декомпозиція алгоритму розв'язання задачі зверху вниз; використання структурного кодування. Ця методологія є найважливішим розвитком імперативної методології. Творцем структурного підходу вважається Едсгер Дейкстра. Йому також належить спроба з'єднати структурне програмування з методами доведення програм.
Методи і концепції.
Метод алгоритмічної декомпозиції зверху вниз полягає в покрокової деталізації постановки задачі, починаючи з найбільш загальної задачі. Даний метод забезпечує хорошу структурованість і підтримується концепцією алгоритму.
Метод модульної організації частин програми полягає в розбитті програми на спеціальні компоненти, звані модулями. Метод підтримується концепцією модуля
Метод структурного кодування полягає у використанні при кодуванні трьох основних керуючих конструкцій. Метод підтримується концепцією управління.
Класифікація за реалізаційною специфіці методологій
Кожне з ядер методологій має певну специфіку, визначальну деяку організацію апаратної підтримки даної методології. На даний момент найбільш відомими організаціями є дві: централізована і паралельна.
Ядра методологій спочатку продумувалися для централізованих архітектур. Пізніше з'явилися паралельні апаратні реалізації, до яких стали адаптувати вже існуючі методології. Прикладом паралельної методології є методологія імперативного паралельного програмування - підхід, в якому пропонується використання явних конструкцій для паралельного виконання вибраних фрагментів програм. Вважається, що паралельне програмування виникло з винаходом каналів - незалежних апаратних контролерів, які давали можливість центральному процесору виконувати нову прикладну програму одночасно з операціями вводу-виводу інших програм. Спочатку з паралельним програмуванням мали справу лише розробники операційних систем.
До методів даної методології можна віднести метод синхронізації виконуваного коду, який полягає у використанні спеціальних атоміческіх операцій для здійснення взаємодії між одночасно виконуваними фрагментами коду. Цей метод підтримується концепцією примітивів синхронізації.
Змішані методології.
Змішані методології включають об'єднання методів кількох методологій. Найбільш часто об'єднуються методології функціонального та логічного програмування. Існують дослідні роботи в галузі об'єднання об'єктно-орієнтованого та логічного програмування. Ряд досліджень присвячено питанням уніфікації методологій програмування.
Петров В.М. у своїй книзі "Технології розробки програмного забезпечення" наводить ще одну методологію - RAD (Rapid Application Development).
Методологія швидкої розробки додатків RAD.
На початковому етапі існування комп'ютерних інформаційних систем їх розробка велася на традиційних мовах програмування. Однак у міру зростання складності розроблюваних систем та збільшення запитів користувачів потрібні нові кошти, щоб забезпечити значне скорочення термінів розробки. Це стало передумовою до створення цілого напряму в галузі програмного забезпечення - інструментальних засобів для швидкої розробки додатків. Розвиток цього напрямку привело до появи на ринку програмного забезпечення засобів автоматизації практично всіх етапів життєвого циклу інформаційних систем. Ці кошти придбали назву методології швидкої розробки додатків RAD (Rapid Application Development).
RAD - це комплекс спеціальних інструментальних засобів швидкої проектування прикладних інформаційних систем, що дозволяють оперувати з певним набором графічних об'єктів, функціонально відображають інформаційні компоненти додатків.
Під методологією швидкої розробки додатків зазвичай розуміється розробки інформаційних систем, який базується на трьох основних елементах:
невеликий команді програмістів (зазвичай від 2 до 10 осіб);
ретельно пророблений виробничий графік робіт, розрахованих порівняно короткий термін розробки (від 2 до 6 міс);
итерационная модель розробки, заснована на тісній взаємодії із замовником - по мірі виконання проекту розробники уточнюють і реалізацію в продукті вимог, висунутих замовником.
Основні принципи:
використовується итерационная (спіральна) модель розробки;
повне завершення робіт на кожному з етапів життєвого циклу не обов'язково;
в процесі розробки інформаційної системи необхідна тісна дію з замовником та майбутніми користувачами;
необхідне застосування CASE-засобів і засобів швидкої розробки, засобів управління конфігурацією, внесення змін до проекту і супровід готової системи, використання прототипів, що дозволяє повніше з'ясувати і реалізувати потреби кінцевого користувача;
тестування і розвиток проекту здійснюються одночасно з розробкою;
розробка ведеться нечисленною і добре керованою командою професіоналів;
необхідні грамотне керівництво розробкою системи, чітке планування та контроль виконання робіт.
Засоби RAD дали можливість реалізовувати зовсім іншу в порівнянні з традиційною технологію створення додатків: інформаційні об'єкти формуються як якісь діючі моделі (прототипи), чиє функціонування узгоджується з користувачем, а потім розробник може переходити безпосередньо до формування закінчених додатків, не втрачаючи з уваги загальної картини проектування системи.
Методології, технології та інструментальні засоби проектування становлять основу проекту будь-якої інформаційної системи. Методологія реалізується через конкретні технології та підтримують їх стандарти, методики та інструментальні засоби, які забезпечують виконання процесів життєвого циклу інформаційних систем.
2.2 Методології розробки інформаційних систем в зарубіжній літературі
Формально методології можна розділити на два типи - класичні (монументальні, передбачувані, де всі етапи детально проектується заздалегідь і не допускається відхилення від початкового плану) та їх протилежність - адаптивні (гнучкі, де в процесі роботи допустимо і навіть типово перепроектування). У залежності від початкових умов і характеру поставленого завдання, може застосовуватися як класична, так і адаптивна методологія (Рис.4).
Класична (монументальна) методологія застосовується, якщо:
У замовника є чітке думку з приводу функціональності та дизайну майбутньої програми, тобто йому абсолютно і в деталях ясно, що він хоче отримати на виході.
Завдання, яке вирішується програмою, чітко формалізується і може бути документована, тобто, можливо, створити детальне технічне завдання. Таке технічне завдання повинне повністю документувати кожне елементарне стан роботи програми, містити повний опис спеціальних алгоритмів (якщо такі використовуються), бути однозначно розуміється у всіх пунктах, описувати всі деталі дизайну користувальницького інтерфейсу. Технічне завдання може бути розроблено фахівцями або замовником самостійно.
Вимоги до програми стабільні, і замовник не буде ставити додаткових умов щодо зміни функціональності програми під час її розробки в рамках поточного контракту. Як наслідок цього обсяг робіт суворо фіксований, також як фіксована і вартість контакту.
Ітераційний процес на даному етапі зміщений в область аналізу, проектування і розробки технічного завдання, процес розробки суворо документований і лине. Термін створення технічного завдання складає близько 60% часу від всього процесу розробки.
Адаптивна (agile - гнучка або lightweight - легка) методологія застосовується, якщо:
Не зрозумілі або змінюються вимоги до системи.
Замовник уявляє собі розробляється ПЗ тільки в загальних рисах і передбачає вносити зміни у функціональність або дизайн розробляється програми під час розробки ("не сподобалося - поміняйте").
Необхідно якомога швидше отримати перші версії працюючої програми.
Розв'язувана програмою завдання важко піддається документуванню.
На реалізацію всіх вимог є достатній запас часу.
При застосуванні такої методології розробка програми є послідовність великої кількості ітерацій, кожна з яких займає за часом від тижня до місяця. За результатами кожної ітерації вимоги до програми уточнюються, і, при необхідності, ітерація повторюється. Процес розробки при такій методології ведення проекту менш бюрократичний, основні акценти зміщені в область практичної реалізації, а не на створення повної і описує "все і вся" документації. Для замовника є можливість практичним шляхом намацати потрібне рішення, яке задовольняє не тільки початковим вимогам, але і в тому числі тим, які з'являться у міру розробки продукту (а рідкісний проект обходиться без появи таких вимог). Замовник у цьому випадку більш щільно взаємодіє з розробниками, знаходиться постійно в курсі поточного стану справ, бере участь у проектуванні чергового етапу та аналізує результати виконаного.
У незалежності від використовуваної методології, робочий процес, підпорядковується таким простим, але важливим правилами:
Використовується система контролю версій.
Оформлення коду стандартизовано.
Першочергове виправлення помилок перед внесенням будь-яких інших змін.
Виконується регулярне резервне копіювання всіх проектних даних.
Використовуються інструментальні засоби автоматизації документування вихідного коду і ведення списків помилок.
Виконуються різні види тестування, починаючи від спеціально створюваних тестових проектів, закінчуючи використанням спеціалізованого інструментарію.
Однією з важливих складових успішного проекту є якісне і безперервні спілкування з замовником. Ефективність співробітництва, відповідність виконуваної роботи вимогам замовника гарантуються регулярними візитами до клієнта відповідальних осіб на всьому протязі робіт за проектом, звітами та доповідями про статус проекту.
Потреба в альтернативі класичним (монументальним) методологій, які в основному засновані на документації, призвела до того, що в 2001 році був проведений семінар, куди були запрошені представники різних адаптивних (гнучких) методологій. Результатом роботи став маніфест гнучкої розробки ПЗ (Manifest for Agile Software Development) (див. Додаток 1).
Більш докладно зупинимося на адаптивних (гнучких) методологіях, оскільки вони найбільш активно розвиваються і використовуються в даний час.
Методологія SCRUM.
Ця методологія призначена для невеликих команд розробників. Проект починається зі створення "резерву властивостей системи" (backlog). Резерв властивостей - це набір функцій системи, які необхідно реалізувати. Самі функції можуть бути описані за допомогою індивідуальних сценаріїв або більш традиційних вимог. Контроль над резервом має тільки одна людина, зазвичай це замовник системи. Резерв постійно змінюється, функції доповнюються і сортуються за пріоритетами.
Після того, як резерв буде трохи наповнений, починається перша ітерація. Весь проект поділяється на ітерації (спринти) тривалістю в 30 днів. Тривалість ітерації можна варіювати, це залежить від конкретного проекту. Для однієї ітерації вибирають функції, які будуть в ній реалізовані. Найважливіше умова - незмінність певних функцій під час однієї ітерації. Це дозволяє розбити весь великий проект з вимог, що змінюються на деяку кількість фіксованих невеликих ітерацій зі стабільними вимогами.
Запланована дата закінчення ітерації повинна жорстко дотримуватися. Команда може не реалізувати деякі з вибраних для ітерації функцій, але дату закінчення ітерації переносити не можна.
Відмінною рисою SCRUM є проведення щоденних 15-30 хвилинних нарад, які так і називаються scrum (бійка). У ході цих нарад лідер команди задає кожному наступні питання:
Що вдалося зробити з вибраних для даної ітерації функцій за минулий день?
Чи були які-небудь проблеми з реалізацією?
Що планується зробити за сьогоднішній день?
Це дозволяє чітко відстежувати хід проекту, швидко виявляти проблеми й, відповідно, швидко реагувати на них.
В кінці спринту команда представляє працюючий продукт із запланованою функціональністю. Після цього влаштовується нараду, на якій обговорюються всі несподівані моменти, з якими зіткнулися розробники, і планується наступна ітерація. Крім того, на цій нараді можна змінювати пріоритети і взагалі все змінювати.
Екстремальне програмування (eXtreme Programming або XP)
Методологія XP є найбільш відомою з гнучких методологій. Основними принципами методології є: простота рішень, інтенсивна розробка малими групами (до 10 осіб), активне спілкування в групі і між групами, замовник включений в процес розробки, достатній ступінь сміливості і бажання йти на ризик. Розробка ПЗ при використанні даної методології виробляється невеликими итерациями (від тижня до місяця) при використанні парного програмування (два програмісти разом створюють код на одному загальному робочому місці). Важливою особливістю методології є прийняття першого найпростішого робочого рішення. Це пов'язано з високим ступенем ризику, обумовленого поверховістю аналізу і жорстким тимчасовим графіком, при цьому реалізуються мінімальний набір функцій системи, а подальша функціональність розширюється з кожною итерацией.
При використанні XP ретельне попереднє проектування ПО замінюється, з одного боку, постійною присутністю в команді замовника, готового відповісти на будь-яке питання і оцінити будь-прототип, а з іншого боку, регулярними переробками коду. Основою проектної документації вважається ретельно прокоментовані код. Дуже велика увага в методології приділяється тестуванню. Як правило, для кожного нового методу спочатку пишеться тест, а потім вже розробляється власне код методу до тих пір, поки тест не почне виконуватися успішно. Ці тести зберігаються у наборах, які автоматично виконуються після будь-якої зміни коду.
Сімейство методологій Crystal.
Crystal - це не просто методологія, це ціле сімейство методологій, розроблене Алістером Коберном.
Коберн розглядає процес створення ПЗ як кінцеву цілеспрямовану гру і стверджує, що у цієї гри є всього дві мети: головна і допоміжна. Головна мета полягає в тому, щоб успішно закінчити проект, тобто створити працюючий продукт. Другорядна мета - підготуватися до наступної гри. Для досягнення цієї мети може знадобитися документація, якісне написання коду, тобто все, що полегшує подальший розвиток та підтримку продукту.
Якщо в процесі розробки досягнуті обидві мети, то проект вважається успішним. Крім кінцевого продукту, завжди створюються допоміжні проміжні продукти: моделі, схеми, описи і т.п. Їх має бути рівно стільки, скільки необхідно для досягнення кінцевої мети. Проблема полягає в тому, що дуже складно заздалегідь передбачити, які проміжні продукти потрібні, а які - ні.
Коберн класифікує проекти за двома параметрами: критичність і величина команди. Під критичністю розуміється величина збитку, нанесеного в результаті використання продукту. Наприклад, помилка в ПЗ для космічного корабля або для апарату штучного дихання непорівнянна з помилкою в ПЗ для форуму на сайті. Життєво важливі проекти мають категорію L, а ті, помилка в яких позначає втрату зручностей, категорію С.
Ступінь важливості наростає по вертикальній осі. Величина команди наростає по горизонтальній осі. У результаті виходить сімейство методологій. Чим нижче критичність і чим менше команда, тим більше "легку" методологію потрібно використовувати. Найлегшою з усього сімейства є методологія Crystal Clear. Головні принципи даної методології:
Вся команда розробників (до 6 осіб) знаходиться в одному приміщенні. Це дозволяє скоротити часові витрати на комунікацію.
Часті поставки продукту дозволяють виробити "ритм" проекту. Ніщо так не надихає команду, як поставлений вчасно продукт.
Обмін інформацією з реальними користувачами дозволяє швидко отримувати зворотний зв'язок і ліквідувати недоліки на ранніх стадіях.
Засоби контролю версій коду забезпечують колективне володіння кодом.
Сімейство методологій Crystal побудовано на ітеративної розробці. Тривалість ітерації може змінюватися в межі від 1 до 4 місяців. Чим менше ітерація, тим краще.
Важливою особливістю Crystal є безперервна настройка методології. Це дозволяє поступово адаптувати її для конкретної команди і конкретного проекту. Мабуть, ні в жодній іншій методології настройці не приділяється такої уваги.
Після кожної ітерації команда збирається разом і обговорює необхідність проміжних продуктів, наявні недоліки і т.п. У результаті приймається рішення про те, що може допомогти виправити недоліки, а потім, за згодою розробників, починається коригування.
Відкритий вихідний код (Open Source).
Спочатку відкритий вихідний код - це, швидше, вид ПЗ, а не процес його розробки. Тим не менше, та манера працювати, яка склалася в суспільстві розробників ПЗ з відкритим вихідним кодом, може виявитися корисною і для закритих проектів. Зокрема, це стосується до спільної роботи фізично віддалених один від одного команд розробників. Це особливо важливо, так як більшість адаптивних процесів підкреслюють той факт, що всі розробники повинні знаходитися поруч.
У більшості проектів з відкритим вихідним кодом є один або кілька координаторів. Координатор є лідером проекту, єдиною людиною, яка може вносити зміни безпосередньо у вихідний код. Тим не менше, інші розробники теж можуть вносити в код зміни, з тією єдиною різницею, що їм доведеться спочатку відіслати їх координатору, який перегляне виправлений код і вже потім вносить зміни. Зазвичай такі зміни мають вигляд патч-файлів, що спрощує подібну процедуру. Таким чином, лідер проекту координує патчі і стежить тим, щоб вони відповідали загальному плану розробляється ПЗ.
Особливістю розробки проектів з відкритим вихідним кодом є те, що налагодження програми може вестися паралельно. Таким чином, в ній можна задіяти велика кількість людей. Знайшовши в програмі помилку, вони можу відіслати патч лідеру проекту. Таким чином, не координатори виконують дуже цінну функцію, тому що велика частина часу витрачається саме на пошук помилок. Крім того, ця робота підходить тим, у кого немає хороших навичок проектування.
Адаптивна методологія (Adaptive Software Development або ASD).
Адаптивна методологія розробки ПЗ - одна з нових методологій, які з'явилися як альтернатива традиційним орієнтованим на процес, методів управління розробкою ПЗ. Головну роль грають людський чинник, результати роботи та мінімізація самого процесу при максимально збільшенні взаємодії між людьми.
ASD базується на принципі безперервної адаптації, завдяки якій виникає інший життєвий цикл проекту. Постійні зміни в проекті стають нормою.
У ASD звичайний статичний життєвий цикл "Планування - Проектування - Конструювання" замінений на динамічний "Обдумування - Взаємодія - Навчання".
Цей цикл ставить своєю метою безперервне навчання. Він пов'язаний з постійними змінами, повторними оцінками спробами передбачити невідоме на поточний момент майбутнє проекту і вимагає тісної взаємодій між розробниками, тестувальники та замовниками.
Методологія ASD побудована на концептуальних засадах теорії складних адаптивних систем. Вона розрахована на використання в екстремальних проектах, в яких превалюють швидкий темп розробок, непередбачуваність і часті зміни. Є проекти, які не можуть вважатися екстремальними, проте для всіх інших ASD підходить набагато краще, ніж будь-який традиційний підхід до розробки ПЗ.
Функціонально-орієнтована розробка (Feature Driven Development або FDD).
Ключову роль відіграє поняття функції або властивості (feature) системи. Функція має реалізовуватися не більш ніж за два тижні. Тобто, якщо сценарій використання досить малий, його можна вважати функцією. Якщо ж великий, то його треба розбити на кілька, відносно незалежних, функцій.
FDD включає п'ять процесів, останні два з яких повторюються для кожної функції:
розробка загальної моделі;
складання списку необхідних функцій системи;
планування роботи над кожною функцією;
проектування функції;
конструювання функції.
Розробники в FDD діляться на "господарів класів" і "головних програмістів". Головні програмісти привертають господарів задіяних класів до роботи над черговим властивістю. Для порівняння, у ХР немає персонально відповідальних за класи чи методи. До роботи над будь-яким класом може залучатися будь-який з учасників розробки.
Робота над проектом передбачає часті збірки і ділиться на ітерації, кожна з яких передбачає реалізацію певного набору функцій.
Метод розробки динамічних систем (Dynamic System Development Method або DSDM).
DSDM - методологія, створена Дженніфер Стаплетоном, що дозволяє розробляти проект у короткий термін з використанням обмеженої кількості ресурсів, передбаченого бюджетом. DSDM прагнути скоротити сполучні ланки між замовником і розробником, аналітиком і дизайнером, між членімого команди і між різними рівнями управління, щоб забезпечити більш ефективні процес розробки програмного забезпечення. Фіксуючи час розробки (зазвичай 6 місяців) і встановлюючи обмеження на використовувані ресурси, набагато простіше створити процес розробки, що відповідає вимогам замовників.
DSDM заснована на безперервному залученні користувача в ітераційний процес розробки для якого не страшні зміни вимог, але в той же час досить пристосований до використання з формальної системою управління проектом.
DSDM допомагає уникнути двох проблем традиційних проектів: специфікації зазвичай відображають те, що програмісти або навіть замовники думають технічно здійсненно, а не те, що потрібне для бізнесу і замовникам доводиться чекати, поки вся система буде розроблена, протестована і задокументовано, перш ніж вони зможуть використовувати ті частини програми, які їм дійсно потрібні вже зараз.
DSDM непридатна якщо:
проект не зводиться до ітеративному додатком, де функціональність стає очевидна замовнику через інтерфейс користувача;
не визначена група користувачів;
проект залежить від складних внутрішніх обчислень.
Основні принципи DSDM:
Активне втручання користувача (в ідеалі, користувачі та розробники поділяють робочий простір, тому рішення можуть прийматися на місці).
Команда повинна мати можливість ухвалювати рішення без очікування підтвердження вищестоящими рівнями (команда складається як з розробників, так і із замовників).
Вимоги замовника - перш за все.
Команда концентрується на випуску проекту більше, ніж на виконання запропонованих дій (вони можуть вибрати технології, які найбільш сприяю розробці даних продуктів в означений період часу).
Розробка ітеративна, керована користувальницьким відгуком. Ітерації властиві всій розробці ПЗ (розробники постійно покращують систему за допомогою ітерацій, що дає їм можливість отримувати користь від залучення користувачів).
Всі зміни оборотні (повернення - основна риса DSDM).
Тестування відбувається протягом усього життєвого циклу розробки, а не перед самим випуском, коли що щось змінити без великих витрат уже неможливо (тестування проводиться як розробниками, так і користувачами). Терміни повинні бути стислими і визначальними швидкий випуск продукту. Оцінка програми повинна бути заснована на необхідної функціональності, а не на рядках коду. Оцінка ризику повинна фокусуватися на функціях, які повинні бути отримані, а не на процесі їх побудови.
Глава 3. Технологія розробки інформаційних систем
Основний зміст технології проектування складають технологічні інструкції, що складаються з опису послідовності технологічних операцій, умов, в залежності від яких виконується та чи інша операція, описів самих операцій.
Виділяють такі загальні вимоги, яким повинні задовольняти технології проектування, розробки і супроводу інформаційних систем:
підтримувати повний життєвий цикл інформаційної системи;
забезпечувати гарантоване досягнення цілей розробки системи з заданою якістю і у встановлений час;
забезпечувати можливість поділу великих проектів на ряд підсистем - ділити композицію проекту на складові частини, що розробляються групами виконавців обмеженою чисельності, з подальшою інтеграцією складових частин;
технологія повинна забезпечувати можливість ведення робіт з проектування окремих підсистем невеликими групами (3-7 осіб);
забезпечувати мінімальний час отримання працездатною системи;
передбачати можливість керування конфігурацією проекту, ведення версій проекту і його складових, можливість автоматичного випуску проектної документації та синхронізацію її версій з версіями проекту;
забезпечувати незалежність виконуваних проектних рішень від засобів реалізації системи - системи управління базами даних, операційної системи, мови й системи програмування.
Технології характеризуються у двох вимірах: вертикальному (представляє процеси) і горизонтальному (представляє стадії).
Процес - сукупність взаємопов'язаних дій, що перетворюють деякі вхідні дані у вихідні. Процеси складаються з набору дій, а кожна дія - з набору завдань. Вертикальний вимір відбиває статичні аспекти процесів і оперує такими поняттями, як робочі процеси, дії, завдання, результати діяльності та виконавці.
Стадія - частина дій зі створення програмного забезпечення, обмежена деякими тимчасовими рамками і закінчується випуском конкретного продукту, що визначається заданими для даної стадії вимогами. Стадії складаються з етапів, які зазвичай мають ітераційний характер. Іноді стадії об'єднують у більші часові рамки, звані фазами. Горизонтальне вимірювання являє собою час, відбиває динамічні аспекти процесів і оперує такими поняттями, як фази, стадії, етапи, ітерації і контрольні точки.
Специфіка комбінацій стадій і процесів, орієнтована на різні класи програмного забезпечення і на особливості колективу розробників, визначає технологічний підхід.
Існують кілька технологічних підходів.
Підходи зі слабкою формалізацією не використовують явних технологій і їх можна застосовувати тільки для дуже маленьких проектів, як правило, завершуються створенням демонстраційного прототипу. До підходам зі слабкою формалізацією відносяться так звані ранні технологічні підходи, наприклад підхід "кодування і виправлення".
Суворі (класичні, жорсткі, передбачувані) підходи застосовують для середніх, крупно-масштабних і гігантських проектів з відносно ясними вимогами до системи і більш-менш фіксованим обсягом робіт. Одне з основних вимог до таких проектів - як можна більша передбачуваність. У цю групу входять такі підходи: [ ]
Каскадні технологічні підходи.
Класичний каскадний підхід - перехід до наступного процесу здійснюється тільки після того, як завершена робота з поточним процесом. Повернення до вже пройдених процесам не передбачені;
Каскадно-поворотний підхід - дозволені повернення до попередніх стадій і перегляд або уточнення раніше прийнятих рішень;
Каскадно-ітераційний підхід - передбачає послідовні ітерації кожного процесу до тих пір, поки не буде досягнутий бажаний результат;
Каскадний підхід з перекриваються процесами припускає наявність спеціалізованих команд, що дозволяють скоротити передану документацію. Наступний процес починається до завершення поточного. Кілька процесів можуть виконуватися паралельно;
Каскадний підхід з підпроцесами дуже близький підходу з перекриваються процесами. Особливість в тому, що проект може бути розділений на підпроекти, які можуть розроблятися індивідуально;
Спіральна модель використовує поняття прототипу, тобто програми, що реалізує часткову функціональність створюваного програмного продукту. Особливість моделі - у розробці итерациями, причому кожен наступний ітераційний прототип буде володіти більшою функціональністю.
Каркасні підходи.
Раціональний уніфікований процес увібрав в себе краще з технологічних підходів каскадної групи. Включає в себе наступні фази: початок (визначення цілей проекту), дослідження (розробка плану і архітектури проекту), побудова (поступове створення системи), впровадження (поставка системи кінцевим користувачам). Особливості - Ітеративний, контроль якості, можливість виявити помилки на ранніх стадіях, перевага віддається моделям, а не паперовим документам, конфігурування, налаштування, масштабування.
Модель процесів Microsoft Solution Framework (MSF) є технологічний підхід, що базується на наборі моделей, правил і специфікацій, що застосовуються при створенні та розповсюдженні програмних продуктів, а також забезпечують більш ефективне використання технологій для рішень проблем бізнесу. Він дозволяє кількісно виражати ступінь завершеності роботи над проектом і адаптувати методи управління ним відповідно до потреб.
Формальні підходи передбачають особливі формальні вимоги до процесу створення програмного забезпечення. Наприклад, для генетичних підходів потрібні формальності, пов'язані з походженням програми і дисципліною її створення. До цієї трупу входять такі підходи:
Генетичні підходи.
Синтезирующее програмування передбачає синтез програми з її специфікації. Документ на мові специфікацій є базисом для подальшої реалізації;
Складальне (розширюване) програмування припускає, що програма збирається шляхом перевикористання вже відомих фрагментів;
Конкретизують програмування передбачає, що приватні спеціальні програми витягуються з універсальною.
Підходи на основі формальних перетворень.
Технологія стерильного цеху складається з наступних частин:
розробка функціональних і користувальницьких специфікацій;
планування розробки;
формальна верифікація;
статичне тестування.
Формальні генетичні підходи
Формальне синтезирующее програмування використовує математичну специфікацію - сукупність логічних формул;
Формальне складальне програмування використовує специфікацію як композицію вже відомих фрагментів;
Формальне конкретизують програмування використовує змішані обчислення і конкретизацію за анотаціями.
Гнучкі (адаптивні, легені) підходи застосовують для невеликих або середніх проектів у випадку неясних чи змінюються вимог до системи. Команда розробників повинна бути відповідальною та кваліфікованої, замовники повинні бути згодні брати участь в розробці. До цієї групи входять такі підходи.
Ранні технологічні підходи швидкої розробки.
Еволюційний Прототипування - перший прототип включає створення розвиненого користувальницького інтерфейсу.
Ітеративна розробка - перший прототип вже повинен включати завершене ядро системи.
Постадійне розробка - має вирішити недолік перших двох підходів - неможливість визначення термінів завершення проектів.
Адаптивні підходи.
Екстремальне програмування (eXtreme Programming або XP). Ретельне попереднє проектування ПО замінюється, з одного боку, постійною присутністю в команді замовника, готового відповісти на будь-яке питання і оцінити будь-прототип, а з іншого боку, регулярними переробками коду. Основою проектної документації вважається ретельно прокоментовані код. Дуже велика увага в методології приділяється тестуванню. Як правило, для кожного нового методу спочатку пишеться тест, а потім вже розробляється власне код методу до тих пір, поки тест не почне виконуватися успішно. Ці тести зберігаються у наборах, які автоматично виконуються після будь-якої зміни коду
Адаптивна розробка. В основі лежать три стадії - обдумування, співробітництво і навчання. Результати планування в даному підході завжди не передбачувані. На відміну від звичайного планування, відхилення в якому ведуть до помилок, тут відхилення ведуть до правильних рішень. Зобов'язання і плани програмістів і замовників переглядаються протягом всього процесу розробки.
Сімейство технологічних підходів Crystal. Для кожного окремого проекту існує свій технологічний підхід, в залежності від його складності, терміновості, кількості розробників і т.д.
Підходи дослідного програмування.
Комп'ютерний дарвінізм заснований на принципі висхідній розробки, коли система будується навколо ключових компонентів і програм, які створюються на ранніх стадіях розробки. Являє собою метод проб і помилок, заснований на інтенсивному тестуванні, причому на будь-якому етапі система повинна працювати.
Фрагментарне програмування полягає в тому, що спочатку створюється шаблон програм з працюючими шматочками (фрагментами). Далі виконується поступове наближення до кінцевої мети. Застосовується в тому випадку, коли не можуть бути точно сформульовані вимоги до більшої частини завдання.
Глава 4. Державні та міжнародні стандарти в області розробки програмного забезпечення
4.1 Міжнародний стандарт ISO / IEC 12207: 1995-08-01
Перша редакція ISO 12207 була підготовлена в 1995 р. об'єднаним технічним комітетом ISO / IEC.
За визначенням, ISO 12207 - базовий стандарт процесів життєвого циклу орієнтований на різні види ПО і типи проектів автоматизованих систем.
Доцільність спільного використання стандартів на інформаційної системи і на ПЗ обумовлюється одним з положень ISO 12207, згідно з яким процеси, які використовуються під час життєвого циклу ПЗ, повинні бути сумісні з процесами, що використовуються під час життєвого циклу автоматизованої системи.
Згідно ISO 12207, система - це об'єднання одного або кількох процесів, апаратних засобів, програмного забезпечення, обладнання і людей для забезпечення можливості задоволення визначених потреб
Загальна структура.
У стандарті ISO 12207 не передбачено будь-яких етапів (фаз або стадій) життєвого циклу інформаційної системи. Даний стандарт визначає лише ряд процесів: придбання, постачання, розробка і т.п.
Згідно ISO 12207, кожен процес поділяється на ряд дій, а кожна дія - на ряд завдань. Дуже важливою особливістю ISO 12207 є те, що кожен процес, дія або завдання ініціюються і виконуються іншим процесом в міру необхідності, причому немає заздалегідь визначених послідовностей (природно, при збереженні логіки зв'язків за вихідними відомостями завдань тощо).
Особливості стандарту ISO 12207.
Стандарт ISO 12207 має динамічний характер, обумовлений способом визначення послідовності виконання процесів і завдань, при якому один процес при необхідності викликає інший або його частину.
Стандарт ISO 12207 забезпечує максимальну ступінь адаптивності. Безліч процесів і завдань сконструйовано так, що можлива їх адаптація, у відповідності з конкретними проектами інформаційних систем. Ця адаптація зводиться до виключення процесів, видів діяльності та завдань, непридатних в конкретному проекті.
Стандарт принципово не містить описи конкретних методів дій, а тим більше - заготовок рішень або документації. Даний стандарт не наказує імена, формати або точний зміст одержуваної документації. Рішення такого типу приймаються сторонами, які використовують стандарт.
Забезпечення якості різними процесами виконується з різною передбаченої ступенем організаційної незалежності контролюючої діяльності аж до обов'язкових вимог до повної незалежності перевіряючого персоналу від будь-якої прямої відповідальності за об'єкти, що перевіряються. Контроль цього виду передбачений на самих ранніх кроки розробки, починаючи з аналізу системних вимог за допомогою їх перевірок на відповідність потребам придбання.
Ступінь обов'язковості розглянутого стандарту наступна: після рішення організації про застосування ISO 12207 в якості умови торговельних відносин є її відповідальність за зазначення мінімального набору необхідних процесів і завдань, які забезпечують узгодженість з цим стандартом.
Стандарт містить гранично мало описів, спрямованих на проектування бази даних. Це можна вважати виправданим, тому що різні системи і різні прикладні комплекси програмного продукту може не тільки використовувати вельми специфічні типи баз даних, а й взагалі не використовувати базу даних.
Цінність стандарту ISO 12207 в тому, що він містить набори завдань, характеристик якості, критеріїв оцінки тощо, що дають всебічне охоплення проектних ситуацій.
4.2 Стандарти комплексу ГОСТ 1934
ГОСТ 34 замислювався в кінці 80-х років як всеосяжний комплекс взаємопов'язаних міжгалузевих документів. Об'єктами стандартизації є автоматизовані системи різних видів і всі види їх компонентів, а не тільки програмне забезпечення і бази даних.
Комплекс розрахований на взаємодію замовника і розробника. Аналогічно ISO 12207, в ньому передбачено, що замовник може розробляти автоматизовану систему для себе сам (наприклад, створивши для цього спеціалізований підрозділ). Проте формулювання ГОСТ 34 не орієнтовані на настільки явне і у відомому сенсі симетричне відображення дій обох сторін, як це зроблено в ISO 12207. Оскільки ГОСТ 34 в основному приділяє увагу вмісту проектних документів, розподіл дій між сторонами зазвичай проводиться виходячи з цього змісту.
Загальна структура.
З усіх існуючих груп документів будемо грунтуватися тільки на групі 0 "Загальні положення" і групі 6 "Створення, функціонування та розвиток автоматизованої системи". Найбільш популярними можна вважати стандарти ГОСТ 34.601-90 (стадії створення автоматизованої системи), ГОСТ 34.602-89 (технічне завдання на створення автоматизованої системи) та методичні вказівки РД 50-34.698-90 (вимоги до змісту документів) Стандарти передбачають стадії та етапи виконання робіт зі створення автоматизованої системи, але не передбачають наскрізних процесів у явному вигляді.
Відповідно до ГОСТ 34, розробка автоматизованої системи розбивається на наступні етапи та стадії:
Етап формування вимог до автоматизованої системи. Складається з наступних стадій:
обстеження об'єкту і обгрунтування необхідності розробки автоматизованої системи;
формування вимог замовника до автоматизованої системи;
розробка звіту про виконану роботу і заявки на розробку технічного завдання.
Розробка концепції:
вивчення об'єкта;
проведення необхідних науково-дослідних робіт;
розробка варіантів концепції автоматизованої системи, що задовольняє вимогам замовника;
розробка звіту про виконану роботу.
Розробка та затвердження технічного завдання на розробку автоматизованої системи.
Розробка ескізного проекту автоматизованої системи:
розробка попередніх проектних рішень по всій системі в цілому і по її окремих складових;
розробка документації.
Розробка технічного проекту:
розробка проектних рішень по всій системі і за її частин;
розробка документації на автоматизовану систему і на підсистеми, що входять до її складу;
розробка та оформлення документації на постачання виробів для комплектування автоматизованої системи та / або технічних вимог на їх розробку;
розробка завдань на проектування в суміжних частинах проекту об'єкта автоматизації.
Розробка технічної документації:
розробка робочої документації на систему і її частини;
розробка та / або адаптація програмного забезпечення.
Введення розробленої системи в дію:
підготовка об'єкта автоматизації;
підготовка персоналу;
комплектація автоматизованої системи програмними та технічними засобами;
монтажні роботи;
пуско-налагоджувальні роботи;
попередні випробування;
дослідна експлуатація;
приймальні випробування.
Супровід:
виконання робіт відповідно до гарантійних зобов'язань;
післягарантійне обслуговування.
У ГОСТ 34 наводиться опис змісту документів, що розробляються на кожному з етапів.
Особливості.
Наступні основні особливості комплексу стандартів ГОСТ 34:
Основною метою розробки комплексу нормативних документів ГОСТ 1934 Про дозвіл протиріч, що виникають при інтеграції систем внаслідок неузгодженості нормативно-технічної документації. Комплекс стандартів ГОСТ 34 ближчий до схем конкретних методик, ніж до стандартів типу ISO 12207.
Ступінь адаптивності стандарту ГОСТ 34 визначається наступними можливостями:
можливістю відмовитися від етапу ескізного проектування і об'єднувати етапи розробки технічного проекту і робочої документації;
можливістю відмовлятися від деяких стадій розробки, а також об'єднувати більшість документів та їх розділів;
можливістю вводити додаткові документи, розділи документів і роботи;
можливістю динамічно створювати приватні технічні завдання, що дозволяє досить гнучко формувати життєвий цикл автоматизованої системи.
Стадії і етапи, що виконуються організаціями - учасниками робіт зі створення автоматизованої системи, встановлюються в договорах і технічному завданні, що близько до підходу ISO 12207.
Документи ГОСТ 34 визначають єдину термінологію і цілком розумно класифікують роботи зі створення автоматизованої системи та документи розробляються в результаті цих робіт. Завдяки ГОСТ 1934 спрощується інтеграція різних систем і підвищується якість систем, отриманих в результаті інтеграції.
Забезпечення якості згідно ГОСТ 34 визначається в технічному завдань на автоматизовану систему і виробляється на будь-яких подальших етапах і з будь-яким ступенем незалежності експертизи. У послідовності етапів розробки ці експертизи розташовуються дещо пізніше, ніж у ISO 12207;
Ступінь обов'язковості ГОСТ 34: повна обов'язковість відсутня, матеріали ГОСТ 1934 є методичною підтримкою. Причому ця підтримка значною мірою орієнтована на замовника: у стандарті є набір вимог до змісту технічного завдання та проведення випробувань розробленої системи.
Ключовим документом взаємодії сторін є технічне завдання (ТЗ) на створення автоматизованої системи. ТЗ є основним вихідним документом для створення автоматизованої системи та її приймання, воно визначає найважливіші точки взаємодії замовника і розробника.
Відповідно до ГОСТ 34, автоматизована система складається програмно-технічних, програмно-методичних комплексів та окремих компонент організаційного, технічного, програмного та інформаційного забезпечення.
4.3 Стандарти комплексу ГОСТ 19
ГОСТ 19 являє собою всеосяжний комплекс, який встановлює цільове призначення, сфера поширення, класифікацію і правила позначення стандартів, що входять в комплекс Єдиної системи програмної документації (ЕСПД).
Єдина система програмної документації - комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм і програмної документації.
У стандартах ЕСПД встановлюють вимоги, які регламентують розробку, супровід, виготовлення та експлуатацію програм, що забезпечує можливість:
уніфікації програмних виробів для взаємного обміну програмами та застосування раніше розроблених програм в нові розробки;
зниження трудомісткості та підвищення ефективності розробки, супроводу, виготовлення і експлуатації програмних виробів;
автоматизації виготовлення і зберігання програмної документації.
Супровід програми включає аналіз функціонування, розвиток і вдосконалення програми, а також внесення змін до неї з метою усунення помилок.
Правила та положення, встановлені у стандартах ЕСПД, поширюються на програми і програмну документацію для обчислювальних машин, комплексів і систем незалежно від їх призначення і області застосування.
До складу ЕСПД входять:
основоположні та організаційно-методичні стандарти;
стандарти, що визначають форми і зміст програмних документів, що застосовуються при обробці даних;
стандарти, щоб забезпечити автоматизацію розробки програмних документів.
Розробка організаційно-методичної документації, яка визначає і регламентує діяльність організацій з розробки, супроводу та експлуатації програм, повинна проводитися на основі стандартів ЕСПД.
Практична частина
Інформаційна система "Навчально-методичний ресурс" призначена на допомогу викладачам. З її допомогою вони можуть створювати працюють навчальні електронні ресурси. Ці ресурси являють собою web-сайти, інформація яких носить навчальний характер. Вони містять такі матеріали: лекції, лабораторні роботи, самостійні роботи, індивідуальні завдання.
В якості практичної частини нам було запропоновано реалізувати наступну частину інформаційної системи: створення основи навчального електронного ресурсу, яка містить в собі елементи - головна сторінка електронного ресурсу, лекції. В якості додаткового завдання було запропоновано реалізувати реєстрацію користувача.
Інформаційна система "Навчально-методичний ресурс" представляє собою web-сайт, тому в якості мови програмування ми вибрали мову PHP. Це обумовлено декількома причинами. По-перше, ця мова досить простий у вивченні, по-друге, це багатофункціональний мову, по-третє, в нього включена підтримка сучасних баз даних, по-четверте, РНР підтримується майже на всіх відомих платформах, майже у всіх операційних системах та на самих різних серверах, по-п'яте, в РНР вбудовані функції для роботи з текстовими даними будь-яких форматів, включаючи XML, і функції для роботи з файловою системою і т.д.
Для реєстрації користувачів був написаний файл сценарію reg. php (Додаток 2). Були написані допоміжні функції для перевірки правильності заповнення форми, перевірки правильності заповнення полів, що мають специфічний характер: e - mail (має спеціальний формат), ПІБ (не повинні містити цифр, розділових знаків, крім дефіса) телефон (має спеціальний формат).
/*------- Допоміжні функції ------- * /
function Check ($ var, $ val = "") {
if (! isset ($ var))
return $ val;
else
return $ var;
}
/ / Функція для перевірки ПІБ
/ / Function FIO_OK ($ str) {
/ / Return ereg ("^ [А-Яа-я \ '-] {l, 25} $", $ str);
/ /}
function LOGIN_OK ($ str) {
$ Conn = mysql_connect ("localhost", "root"); / / встановлюємо з'єднання
$ Database = "users";
$ Table_name = "pass";
mysql_select_db ($ database); / / вибираємо базу даних
/ / Перевірка унікальності псевдоніма
$ Sql = "SELECT login FROM $ table_name WHERE` login `=". "'". $ Str. "'";
$ Result = mysql_query ($ sql);
mysql_close ($ conn);
return mysql_num_rows ($ result);
}
/ / Функція для перевірки email
function email_OK ($ str) {
return preg_match ("/ ^ \ w + ([\. \ w] +) * \ w @ \ w ((\. \ w) * \ w +) * \. \ w {2,3 }$/",$ str);
}
/ / Функція для перевірки телефону
function telefon_OK ($ str) {
return preg_match ("/ \ d {3} - \ d {2} - \ d {2 }/",$ str);
}
/ / Функція для перевірки форми
function Form _ OK () {
/ / Масив помилок та відповідних повідомлень
global $ errors, $ err _ msg;
/ * If (! FIO_OK ($ _POST ["fname"])) {
$ Errors ["fname"] = 1;
$ _POST ["Fname"] = "";
}
if (! FIO_OK ($ _POST ["oname"])) {
$ Errors ["oname"] = 1;
$ _POST ["Oname"] = "";
}
if (! FIO_OK ($ _POST ["lname"])) {
$ Errors ["lname"] = 1;
$ _POST ["Lname"] = "";
}
* /
if (LOGIN_OK ($ _POST ["login"])) {
$ Errors ["login"] = 1;
$ _ POST ["login"] = "";
}
/ / Перевірка збіги пароля і підтвердження
if (strcmp ($ _POST ["pass "],$_ POST [" repass "])! = 0) {
$ Errors ["error"] = 1;
$ _POST ["Repass"] = "";
}
if (! $ _POST ["pass"]) {
$ Errors ["pass"] = 1;
$ _POST ["Repass"] = "";
}
if (! $ _POST ["repass"]) $ errors ["repass"] = 1;
if (sizeof ($ errors)> 0) {
/ / Якщо існують помилки, виводяться відповідні повідомлення, і форма відображається заново
echo "<html> <body> <div align='center' style='font-size: 18'> <b> ПОМИЛКА </ b> </ div>";
echo "<div align='center' style='font-size: 14, color: red'> Виявлено наступні помилки: <br>";
foreach ($ errors as $ key => $ value) {
echo "<b>". $ Err_msg [$ key]. "</ B> <br>";
}
echo "</ div>";
ShowForm ();
echo "</ body> </ html>";
}
else {
/ / Якщо помилки відсутні, виводиться відповідне повідомлення
echo "<h 2 align = 'center'> Шановний (а)". $ _POST ["lname"]. "". $ _POST ['Fname']. "! </ H2> <br> <h3 align='center'>
Реєстрація пройшла успішно </ h 3> ";
$ _ SESSION ['login'] = $ _ POST ['login'];
/ / Реєструємо змінну login
/ / $ _SESSION ['Pass'] = $ _POST ['pass'];
/ / Реєструємо змінну pass
/ / Тепер логін і пароль - глобальні
/ / Змінні для цієї сесії
echo "<center> <a href =main_form. php> OK </ a> </ center>";
/ / Вносимо дані в базу
$ Conn = mysql _ connect ("localhost", "root"); / / встановлюємо з'єднання
$ Database = "users";
$ Table_name = "pass";
mysql_select_db ($ database); / / вибираємо базу даних
/ / Перевірка унікальності псевдоніма
$ List_f = mysql_list_fields ($ database, $ table_name); / / отримуємо список полів у базі
$ N = mysql _ num _ fields ($ list _ f); / / число рядків у результаті попереднього запиту
/ / Складемо один запит відразу для всіх полів таблиці
$ Sql = "INSERT INTO $ table _ name SET"; / / починаємо створювати запит, перебираємо всі поля таблиці
for ($ i = 0; $ i <$ n; $ i + +) {
$ Name_f = mysql_field_name ($ list_f, $ i); / / обчислюємо ім'я поля
$ Value = $ _ POST [$ name _ f]; / / обчислюємо значення поля
$ J = $ i + 1;
$ Sql = $ sql. $ Name _ f. "= '$ Value'"; / / дописуємо в рядок $ sql пару ім'я = значення
if ($ j <> $ n) $ sql = $ sql. ","; / / якщо поле не останнє в списку, то ставимо кому
}
/ / Перед тим як записувати щось в базу,
/ / Можна подивитися, який запит вийшов
/ / Echo $ sql;
$ Result = mysql _ query ($ sql, $ conn); / / відправляємо запит виводимо повідомлення чи успішно виконаний запит
if (! $ result) echo "Can't add". $ Table_name;
else echo "Success! <br>";
mysql _ close ($ conn);
}}
У результаті його роботи на екрані відображається форма для введення даних про користувача (мал. 5).
Для створення або поновлення навчального курсу був написаний файл сценарію main_form. php (Додаток 3)
Для створення частини ІС "Навчально-методичний ресурс", в якій здійснюється додавання нових лекцій у створюваний ресурс був написаний файл сценарію lections. php (Додаток 4)
Рис.5. Реєстрація користувачів
У результаті виконання практичної частини були створено фрагмент інформаційної системи "Навчально-методичний ресурс".
Висновок
Проаналізувавши літературу до даної курсової роботи, нам вдалося вивчити основні поняття, такі як: "Інформаційна система", "Методологія розробки інформаційних систем", "Технологія розробки інформаційних систем".
Була проведена класифікація методологій розробки програмного забезпечення по вітчизняних і зарубіжних джерел, розглянуті та вивчені державні та міжнародні стандарти в області розробки програмного забезпечення;
Практичною частиною курсової роботи була розробка фрагмента інформаційний системи "Навчально-методичний ресурс". Такий фрагмент був створений.
Таким чином, завдання курсової роботи, сформульовані у вступі, вирішені, мета досягнута.
Список використаних джерел
Про інформацію, інформатизації і захисту інформації: Федеральний закон від 20 лютого 1995 р. № 24-ФЗ / / Збори законодавства РФ. - 1995. - № 8. - Ст.609
Брауде, Е. Технологія розробки програмного забезпечення / Е. Брауде. - СПб,: Пітер, 2004. - 655 с.
Інформаційні системи: навч посібник / під ред.В.Н. Волкової, Б.І. Кузіна. - 2-е вид., Перераб і доп. - СПб.: Вид-во СПбГПУ, 2004. - 224 с.
Короткий філософський словник / під ред.А.П. Алексєєва. - 2-е вид., Перераб. і доп. - М.: ТК Велбі, Вид-во Проспект, 2006. - 496 с.
Непейвода, М.М. Підстави програмування / М.М. Непейвода, І.М. Скопин. - М. - К.: Ін-т комп'ютерних досліджень, 2003. - 868 с.
Новий ілюстративний енциклопедичний словник / під. Ред.В.І. Бородуліна, А.П. Горкіна, А.А. Гусєва, Н.М. Ланда и др. - М.: Велика Російська енциклопедія, 2003. - 912 с.
Одинцов, І.О. Професійне програмування. Системний підхід / І.О. Одінцов. - 2-е вид., Перераб. і доп. - СПб.: БХВ-Петербург, 2004. - 624 с.
Орлов, С.А. Технології розробки програмного забезпечення: навч. посібник / С.А. Орлов. - 2-е вид. - СПб.: Пітер, 2003. - 480 с.
Петров, В.М. Інформаційні системи: навч. посібник / В.М. Петров. - СПб.: Пітер, 2002. - 588 с.
Економічна інформатика: Введення в економічний аналіз інформаційних систем: підручник. - М.: ИНФРА-М, 2005. - 958 с. - (Підручники економічного факультету МДУ ім. М. В. Ломоносова).
Юдін, Е.Г. Методологія науки. Системність. Діяльність / Е.Г. Юдін. - М.: Едіторіал УРСС, 1997. - 246 с.
Адаптивна методологія ASD: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30362e747874>
Адаптивні і адаптаційні процеси: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30332e747874>
Гнучкість і монументальність методологій: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30342e747874>
Єдина система програмної документації: [Електронний ресурс] <http://www.nist.ru/hr/doc/gost/gost19.htm>
Закис, А.В.ruP та інші методології розробки ПЗ: [Електронний ресурс] <http://www.cmcons.com/rup-vs-competitors.htm>
Колодін, М. Ю. Гнучкі технології програмування (огляд і оцінка придатності): [Електронний ресурс] <http://www.computer.edu.ru/myke/se/index.shtml>
Маніфест гнучкої розробки програмного забезпечення: [Електронний ресурс] <http://www.agilealliance.org.ru>
Методології ведення проекту: [Електронний ресурс] <http://www.digital-soft.ru/methodology.php> (11.05.2006)
Методології розробки програмного забезпечення: [Електронний ресурс] <http: // yura.com.ua/development/programming-methodology/index.html>
Поняття "Інформаційна система": [Електронний ресурс] <http://www.info-system.ru/is/about/is_concept_is.html>
Сімейство методологій Crystal Алістера Коуберна: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f3034362e747874>
Стандарти з інформаційних технологій: [Електронний ресурс] <http://www.linux.nist.ru/hr/doc/gost/gost34.htm>
Сунстед, Т. "Раціональне" проектування: [Електронний ресурс] <http://www.osp.ru/cw/2001/36/017_1_print.htm>
Фаулер, М. Нові методології програмування: [Електронний ресурс] <http://www.maxkir.com/sd/newmethRUS.html>
Хаф, Л. Методологія розробки програмного забезпечення: в 3-х ч. - Ч.2: Екстремальне програмування: [Електронний ресурс] <http://www.lib.csu.ru/dl/bases/prg/kompress/articles/ 2003_10_XP/index.htm>
Хаф, Л. Методологія розробки програмного забезпечення: в 3-х ч. - Ч.3: Rational Unified Process: [Електронний ресурс] <http://www.lib.csu.ru/dl/bases/prg/kompress/articles / 2004_01_rupIntro/index.htm>
Екстремальне програмування та швидка розробка: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f3034352e747874>
DSDM - метод розробки динамічних систем: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30372e747874>
Open Source як гнучка методологія: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30382e747874>
Rational Unified Process: [Електронний ресурс] <http://www.booktp.jino-net.ru/? action = view & article = 626f6f6b2f30332f30352e747874>