Студопедия

КАТЕГОРИИ:



Мы поможем в написании ваших работ!

Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Мы поможем в написании ваших работ!

Види програмних документів. Записка пояснення


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

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

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

Зовнішній опис ПС грає роль точної постановки завдання, рішення якого повинне забезпечити ПС., що розробляється. Більше того, воно повинне містити усю інформацію, яку необхідно знати користувачеві для застосування ПС. Воно є початковим документом для трьох паралельно протікаючих процесів: розробки текстів (кiinoрoeрiaaie? і кодуванню) програм, що входять в ПС, розробки документації по застосуванню ПС і розробки істотної частини комплекту тестів для тестування ПС. Помилки і неточності в зовнішньому описі, кінець кінцем, трансформуються в помилки самої ПС і обходяться особливо дорого, по-перше, тому, що вони робляться на самому ранньому етапі розробки ПС, і, по-друге, тому, що вони поширюються на три паралельні процеси. Це вимагає особливо серйозних заходів по їх попередженню.



Початковим документом для розробки зовнішнього опису ПС є визначення вимог до ПС. Але оскільки через цей документ передається від замовника (користувача) до розробника основна інформація відносно необхідного ПС, те формування цього документу є досить тривалим і важким ітераційним процесом взаємодії між замовником і розробником, з якого і починається етап розробки вимог до ПС [4.2]. Труднощі, що виникають в цьому процесі, пов'язані з тим, що користувачі часто погано уявляють, що їм насправді треба : використання комп'ютера в "вузьких" місцях діяльності користувачів може насправді зажадати принципової зміни усієї технології цієї діяльності (про що користувачі, як правило, і не здогадуються). Крім того, проблеми, які необхідно відбити у визначенні вимог, можуть не мати певного формулювання, що призводить до поступової зміни розуміння розробниками цих проблем. У зв'язку з цим визначенню вимог часто передує процес системного аналізу, в якому з'ясовується, наскільки доцільно і реалізовується ПС, що "замовляється", як вплине таке ПС на діяльність користувачів і якими особливостями воно повинне володіти. Іноді для прояснення дійсних потреб користувачів доводиться розробляти спрощену версію необхідного ПС, звану прототипом ПС. Аналіз "пробного" застосування прототипу дозволяє іноді істотно уточнити вимоги до ПС.

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

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

Цю документацію можна розбити на дві групи:

Документи управління розробкою ПС.

Документи, що входять до складу ПС.

Документи управління розробкою ПС (process documentation), протоколюють процеси розробки і супроводу ПС, забезпечуючи зв'язки усередині колективу розробників і між колективом розробників і менеджерами (managers) - особами, що управляють розробкою. Ці документи можуть бути наступних типів [13.1]:

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

Звіти про використання ресурсів в процесі розробки. Створюються менеджерами.

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

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

Замітки і листування. Ці документи фіксують різні деталі взаємодії між менеджерами і розробниками.

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

Призначена для користувача документація ПС (П-документація).

Документація по супроводу ПС (С-документация).

 

<== предыдущая лекция | следующая лекция ==>
Якість програмного забезпечення | Посібник користувача

Дата добавления: 2014-01-04; Просмотров: 585; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



ПОИСК ПО САЙТУ:


Рекомендуемые страницы:

Читайте также:
studopedia.su - Студопедия (2013 - 2021) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление
Генерация страницы за: 0.002 сек.