метою забезпечення якості програмних продуктів і процесів в компанії функціонує Рада з якості.
Рада за якістю складається з висококваліфікованих фахівців в галузі розробки програмного забезпечення. Очолює Раду за якістю головний технічний директор. p align="justify"> Члени Ради з якості призначаються головним технічним директором.
Основні функції Ради з якості:
аналіз виконання Політики в сфері якості;
аналіз функціонування системи управління якістю;
оцінка якості програмного продукту
оцінка якості процесів системи управління якістю;
оцінка результативності та ефективності коригувальних і запобіжних дій;
розгляд, аналіз та розробка рішень за результатами функціонування системи управління якістю;
аналіз діяльності внутрішніх аудиторів системи управління якістю;
поліпшення системи управління якістю.
2.4 Організація контролю якості на підприємстві
Важливу роль у всіх проектах Epam Systems грає тестування. Виявлення і усунення проблем після розгортання програмного забезпечення будуть коштувати в 100-1000 разів більше, ніж виявлення і усунення цих проблем до впровадження ПЗ. Тому дуже важливо вміти оцінювати якість системи програмного забезпечення за такими параметрами як функціональність системи, її надійність і продуктивність. p align="justify"> Створено незалежний підрозділ контролю якості, фахівці цього підрозділу беруть активну участь у всіх фазах розробки програми для того, щоб забезпечити відповідність вимогам, проконтролювати послідовність його розробки та впровадження.
Лабораторія тестування і підрозділ контролю якості EPAM відповідають за:
В· планування процесу тестування;
В· створення тестових прикладів і драйверів;
В· автоматичне і ручне функціональне тестування;
В· звітність про результати тестів;
В· аналіз архітектури системи тестування;
В· тестування навантаження;
В· аналіз слабких місць або компонентів системи.
Поняття функціональної специфікації
Функціональна специфікація - це результат етапу проектування, докладно описує вимоги до додатка.
Розробка функціональної специфікації дуже важлива, оскільки цей документ є єдиним описом проекту і використовується всіма членами команди і клієнтами. Саме цей документ готує менеджер проекту, саме цей документ обговорюється клієнтом і менеджером продукту, саме цей документ служить основою для керівника розробки, архітектора бази даних і розробників. p align="justify"> Процес створення функціональної специфікації
Визначення вимоги до програмного засобу (ПС) є вихідним документом для його розробки - завданням, що виражає в абстрактній формі потреби користувача. Вони в загальних рисах визначають задум програмного продукту, характеризують умови його використання. p align="justify"> Визначення вимог є досить складною і важливою частиною роботи по створенню функціональної специфікації, оскільки необхідно точно визначити, що хоче користувач отримати від програмного продукту і що, в кінцевому рахунку, слід створити.
Після того як вимоги та побажання замовника до майбутнього програмному продукту визначені, здійснюється їх аналіз.
Може існувати велика кількість способів почати і проводити аналіз вимог, але всі вони повинні приводити до одного і того ж результату - складання документа, що описує всі вимоги та побажання користувача.
Результатом аналізу має бути чітке розуміння того, що вимагає користувач, і що він хоче. Тонка різниця між цими двома поняттями важливо. Вимоги користувача обмежуються поданням користувача про пропоновану їм завданню. Ці вимоги користувач явно обговорює в процесі дискусії. Побажання ж користувача нерідко залишаються за кадром, не тому що користувач не обговорює їх спеціально, а тому, що він підсвідомо вважає деякі вимоги природними і не вимагають спеціального виділення. p align="justify"> Таким чином, після отримання замовлення на нову розробку (або на модифікацію існуючої) починається аналіз вимог і побажань замовника і закінчується складанням документа, в деталях описує дану розробку. Головною метою аналізу вимог замовника є знаходження того, що хоче користувач. Якщо дана фаза розробки проекту була ретельно проведена, здійснюється перехід на наст...
