Порядок розробки програмного модуля. Атестація програмних засобів

МІНІСТЕРСТВО ОСВІТИ УКРАЇНИ

Бердичівський політехнічний коледж

Контрольна робота

з дисципліни “Технологія розробки програмного забезпечення”

(варіант №1)

Виконав: студент групи Пзс-504

Аранчій І. О

Перевірив: викладач

Тростянський Б.Г.

м. Бердичів 2007 р.

Зміст

1. Визначення технології розробки програмного забезпечення та основні поняття цього процесу: інформаційне середовище процесу обробки даних, формальний опис задачі, поняття про програмний засіб, поняття помилки і надійності програмних засобів

2. Порядок розробки програмного модуля.

3. Атестація програмних засобів

4. Практичне завдання

Список використаної літератури

Технологія - це загально-технічне поняття, яке об’єднує процеси, методи та засоби, що супроводжують виробництво будь - якої продукції. Якщо мова йде про технічну продукцію, то можна чітко визначити два етапи підготовки її виробництва - конструкторський і технологічний. На конструкторському етапі відбувається розробка та проектування самого виробу, а на технологічному - вирішуються питання, пов’язані з організацією виробництва даної продукції (причому, досить часто для конкретного підприємства). Коли поняття технології застосовується до розробки програмного забезпечення, то зміст, що у нього вкладається, значно змінюється. Це пов’язано з тим, що для програмного забезпечення неможливо відокремити процеси розробки (проектування), виробництва і експлуатації, тому що в даному випадку ці процеси проходять у значній мірі проходять паралельно і залежать один від одного. Так, наприклад, в процесі експлуатації програмного засобу, можуть бути виявлені помилки, усунення яких, потребує внесення змін у програмні модулі, тобто повернення до етапу розробки, що є цілком закономірним. З урахуванням зроблених зауважень можна ввести наступне визначення:

Технологія розробки програмного забезпечення (технологія програмування) - це сукупність процесів, пов’язаних із створенням надійного програмного засобу, починаючи з моменту виникнення ідеї створення цього засобу і закінчуючи процесом вилучення його з експлуатації. Якщо для різних галузей практичної діяльності людини технологічні процеси, які супроводжують виробництво, розвивалися на протязі століть (а іноді тисячоліть), то технології, пов’язані з розробкою комп’ютерного програмного забезпечення виникли всього декілька десятиріч тому, і мабуть немає в наш час такої сфери виробництва, для якої технологічні процеси та засоби розвивалися настільки ж динамічно. Як в будь - якому технологічному процесі, в технології розробки програмного забезпечення існують основні базові принципи та методи, але у зв’язку із швидким розвитком комп’ютерної техніки, інструментальних систем програмування, розширенням сфер застосування програмного забезпечення та зростанням вимог до його якості, ці базові принципи поступово модифікуються у відповідності до наявних вимог. Тому було б великою помилкою розглядати технологічні процеси пов’язані з розробкою програмного забезпечення як статичні, обмежуючись вивченням тільки їх загальних основ, особливо, якщо розглядати “Технологію розробки програмного забезпечення”, як навчальну дисципліну. У цьому випадку охопити весь спектр питань пов’язаних з розробкою різнотипного програмного забезпечення є просто неможливим, і тому мова в першу чергу йде про розгляд питань, пов’язаних з розробкою надійного прикладного програмного забезпечення, з застосуванням як базових технологічних принципів розробки, так і сучасних методик і засобів.
Технологія програмування складається з трьох взаємопов’язаних частин:

основних етапів, які визначають послідовність технологічних операцій проектування;

критеріїв і правил, які використовуються для оцінки результатів виконання технологічних операцій;

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

Кількість та склад етапів проектування залежить від декількох факторів, а саме від типу життєвого циклу програмного засобу, вибраного в якості базової моделі проекту, складності системи, що проектується, наявних ресурсів і т.д. Але можна відокремити етапи, які будуть присутні у будь - якому випадку:

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

розробка структури, алгоритмів рішень та програмних модулів;

тестування та відладка програмного засобу;

впровадження та супровід програмного засобу.

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

Для оцінки програмного модуля застосовуються наступні характеристики:

розмір модуля,

міцність модуля,

зчеплення з іншими модулями,

рутинність модуля (незалежність від передісторії звертань до нього).

Розмір
модуля вимірюється числом операторів, що містяться в ньому, чи рядків. Модуль не повинний бути занадто маленьким чи занадто великим. Маленькі модулі приводять до громіздкої модульної структури програми і можуть не окупати накладних витрат, зв'язаних з їхнім оформленням. Великі модулі незручні для вивчення і змін, вони можуть істотно збільшити сумарний час повторних трансляцій програми при налагодженні програми. Звичайно рекомендуються програмні модулі розміром від декількох десятків до декількох сотень операторів. Міцність
модуля - це міра його внутрішніх зв'язків. Чим вище міцність модуля, тим більше зв'язків він може зкрити від зовнішньої стосовно нього частини програми і, отже, тим більший внесок у спрощення програми він може внести. Самим слабким ступенем міцності володіє модуль, міцний по збігу
. Це такий модуль, між елементами якого немає осмислених зв'язків. Такий модуль може бути виділений, наприклад, при виявленні в різних місцях програми повторення однієї і тієї ж послідовності операторів, що і оформляється в окремий модуль. Необхідність зміни цієї послідовності в одному з контекстів може привести до зміни цього модуля, що може зробити його використання в інших контекстах помилковим. Функціонально міцний
модуль - це модуль, що виконує одну яку-небудь визначену функцію. При реалізації цієї функції такий модуль може використовувати й інші модулі. Такий клас програмних модулів рекомендується для використання. Інформаційно міцний
модуль - це модуль, що виконує кілька операцій (функцій) над однією і тією же структурою даних (інформаційним об'єктом), що вважається невідомою поза цим модулем. Для кожної з цих операцій у такому модулі мається свій вхід зі своєю формою звертання до нього. Такий клас варто розглядати як клас програмних модулів з вищим ступенем міцності. Інформаційно міцний модуль може реалізовувати, наприклад, абстрактний тип даних. Зчеплення
модуля - це міра його залежності за даними від інших модулів. Характеризується способом передачі даних. Чим слабкіше зчеплення модуля з іншими модулями, тим сильніше його незалежність від інших модулів. Найгіршим видом зчеплення модулів є зчеплення по змісту
. Таким є зчеплення двох модулів, коли один з них має прямі посилання на вміст іншого модуля (наприклад, на константу, що міститься в іншому модулі). Не рекомендується використовувати також зчеплення по загальній області
- це таке зчеплення модулів, коли кілька модулів використовують ту саму область пам'яті. Єдиним видом зчеплення модулів, що рекомендується для використання сучасною технологією програмування, є параметричне зчеплення
- це випадок, коли дані передаються модулю або при звертанні до нього як до значень його параметрів, або як результат його звертання до іншого модуля для обчислення деякої функції. Такий вид зчеплення модулів реалізується на мовах програмування при використанні звертань до процедур (функцій). Рутинність
модуля - це його незалежність від передісторії звертань до нього. Модуль називається рутинним
, якщо результат (ефект) звертання до нього залежить тільки від значень його параметрів (і не залежить від передісторії звертань до нього). Модуль називається залежним від передісторії
, якщо результат (ефект) звертання до нього залежить від внутрішнього стану цього модуля, який змінюється в результаті попередніх звертань до нього. Не рекомендується використовувати залежні від передісторії модулі, тому що вони провокують появу в програмах хитрих (невловимих) помилок. Однак така рекомендація є неконструктивною, тому що в багатьох випадках саме залежний від передісторії модуль є кращою реалізацією інформаційно міцного модуля. Тому більш прийнятна наступна рекомендація:

завжди варто використовувати рутинний модуль, якщо це не приводить до поганого зчеплення модулів;

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

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

При розробці програмного модуля доцільно дотримувати наступного порядку:

вивчення і перевірка специфікації модуля, вибір мови програмування;

вибір алгоритму і структури даних;

програмування (кодування) модуля;

перевірка і редагування модуля;

компіляція модуля.

Перший крок розробки програмного модуля в значній мірі являє собою суміжний контроль структури програми знизу: вивчаючи специфікацію модуля, розроблювач повинний переконатися, що вона йому зрозуміла і достатня для розробки цього модуля. У завершенні цього кроку вибирається мова програмування: хоча мова програмування може бути уже визначеною для усього ПЗ, все-таки в ряді випадків може бути обрана інша мова, більш придатна для реалізації даного модуля (наприклад, мова асемблера). На другому кроці розробки програмного модуля необхідно з'ясувати, чи не відомі вже які-небудь алгоритми для рішення поставленої і чи близької до неї задачі. І якщо знайдеться придатний алгоритм, то доцільно їм скористатися. Вибір придатних структур даних, що будуть використовуватися при виконанні модулем своїх функцій, у значній мірі визначає логіку і якісні показники розроблювального модуля, тому його варто розглядати як дуже відповідальне рішення. На третьому кроці здійснюється побудова тексту модуля обраною мовою програмування. Велика кількість усіляких деталей, що повинні бути враховані при реалізації функцій, зазначених у специфікації модуля, легко можуть привести до створення дуже заплутаного тексту, що містить масу помилок і неточностей. Шукати помилки в такому модулі і вносити в нього необхідні зміни може виявитися дуже трудомісткою задачею. Тому дуже важливо для побудови тексту модуля користатися технологічно обґрунтованою і практично перевіреними принципами програмування. Найбільш розповсюдженими є принципи покрокової деталізації. Наступний крок розробки модуля зв'язаний із приведенням тексту модуля до завершеного виду у відповідності зі специфікацією якості ПЗ. При програмуванні модуля розроблювач основну увагу приділяє правильності реалізації функцій модуля, залишаючи недопрацьованими коментарі і допускаючи деякі порушення вимог до стилю програми. При шліфуванні тексту модуля він повинний відредагувати наявні в тексті коментарі і, можливо, включити в нього додаткові коментарі з метою забезпечити необхідні примітиви якості. З цією же метою виконується редагування тексту програми для забезпечення стилістичних вимог. Перевірка модуля являє собою ручну перевірку внутрішньої логіки модуля до початку його налагодження на комп'ютері, реалізує загальний принцип, сформульований для обговорюваної технології програмування. І, нарешті, останній крок розробки модуля означає завершення перевірки модуля (за допомогою компілятора) і перехід до процесу налагодження модуля.

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

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